STARTTLS

STARTTLS（スタート・ティーエルエス）は、平文の通信プロトコルを暗号化通信に拡張する方法のひとつ。Opportunistic TLS（…

STARTTLS
曖昧さ回避 「StartSSL」とは異なります。
TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

STARTTLS（スタート・ティーエルエス）は、平文の通信プロトコルを暗号化通信に拡張する方法のひとつ。Opportunistic TLS（日和見TLS）あるいはExplicit TLS（明示的TLS）とも呼ばれる。

特徴

暗黙のTLS（またはSSL。以下単にTLS）では、暗号化通信のために専用のポートを割り当てなければならない。STARTTLSを利用すれば、専用のポート番号を割り当てずに、途中から平文の通信を暗号化通信に切り替えることができる。

TLSはアプリケーション中立である。例えば、TLS 1.2の仕様書である RFC 5246 では以下のように述べられている。

TLSの利点の一つは、アプリケーションプロトコルから独立していることである。上位層のプロトコルから見てTLSは透過的である。しかしTLSは、標準では、セキュリティをどのように実装するかまでは規定していない。ハンドシェイクをどう始めるか、交換された電子証明書をどう解釈するかは、TLSより上位のレイヤの設計と実装に委ねられている[1]。

プロトコルのSTARTTLS対応

プロトコル 用途 RFC 通常ポート (STARTTLS) SSL SSLポート
SMTP 電子メール送信 RFC 3207 25/587 SMTPS 465
POP3 電子メール受信 RFC 2595 110 POP3S 995
IMAP 電子メール受信 RFC 2595 143 IMAPS 993
NNTP ネットニュース RFC 4642 119/433 NNTPS 563
LDAP ディレクトリ・サービス RFC 4511 389 LDAPS 636
FTP ファイル転送 RFC 4217 21 FTPS 990
XMPP インスタントメッセンジャー RFC 4217 5222 5223

このうち、POP3、IMAP、SMTPについては、RFC 8314 でSTARTTLSよりもImplicit TLS（暗黙のTLS、個別のポートを使用）の使用が推奨となっている。

SMTPにおけるSTARTTLS

TLSを使う方法は、TLSと同レイヤで動作するその他のプロトコルと同様であり、複数のTLSライブラリ実装でサポートされている。 TLSのSMTP拡張 (RFC 3207) で、クライアント（以下ではCとする）とサーバ（以下ではSとする）がセキュアなセッションを開始するまでのやりとりは、例えば次のようになる[2]。 

  S: <TCPポート25番で接続要求を待つ>
  C: <接続をオープンする>
  S: 220 mail.example.org ESMTP service ready
  C: EHLO client.example.org
  S: 250-mail.example.org offers a warm hug of welcome
  S: 250 STARTTLS
  C: STARTTLS
  S: 220 Go ahead
  C: <TLSネゴシエーションを開始>
  C & S: <TLSのネゴシエーション>
  C & S: <ネゴシエーションの結果を確認>
  C: EHLO client.example.org[注釈 1]
  …

最後のEHLOコマンドはセキュアチャネルを通じて送られる。SMTP認証を利用する場合[注釈 2]は、セキュアチャネルが開かれた後であれば、サーバからの応答をAUTH PLAINで送信しても問題ない。

2011年10月現在、STARTTLSをメール送信のために提供しているフリーメールサービスにはGmail[3]とiCloud[4]がある。

限界

両エンドが1対1でセッションを構築するTLSをメールの通信に利用しても、間欠的な通信や他のサーバによる中継を前提とした電子メール[5]では、ホップ間のセキュリティは確保することができるものの、

  • メール側でTLS経由を指示するような情報はなく、すべての中継でTLSが使われる保証をする方法がない[6]
  • 公開されるメールサーバの場合、TLS接続によって受信することを強制することはできず[7]、平文で行われるSTARTTLSの部分を改竄してしまえば、あとの通信も平文で行われてしまう[6]。2014年には、インターネットサービスプロバイダによるSTARTTLSの妨害も報告されている[8]。
  • DNS偽装が行われた場合、全ホップのTLS接続を保ったまま中間者攻撃を成立させられる[9]。

など、電子メールの完全性や機密性の担保、送信者認証などはいずれも実現することができない[10]。電子メールに対してこれらの保護を適用するには、S/MIMEなど、上位層で行うことが必要となる[11]。

脚注

注釈

  1. ^ この時点から暗号化通信が開始される（理解しやすいようにこの行を補った）。詳細はPaul Smithによる次のメーリングリストへの投稿を参照されたい（英文）。Paul Smith (2009年1月26日). “STARTTLS & EHLO”. ietf-smtp mailing list. Internet Mail Consortium. 2015年10月14日閲覧。
  2. ^ SMTPでは、認証は必須ではないことに注意。

出典

  1. ^ Tim Dierks; Eric Rescorla (2008年8月). “The Transport Layer Security (TLS) Protocol”. RFC Editor. 2012年5月13日閲覧。
  2. ^ Paul Hoffman (2002年2月). “SMTP Service Extension for Secure SMTP over Transport Layer Security”. RFC Editor. 2012年5月13日閲覧。
  3. ^ Per Thorsheim (2011年10月). “More STARTTLS support!”. 2012年5月13日閲覧。
  4. ^ Postbox (2011年11月). “Using Postbox with iCloud Accounts : Postbox Support”. 2011年11月13日閲覧。
  5. ^ 『マスタリングTCP/IP SSL/TLS編』、pp.408-409。
  6. ^ a b 『マスタリングTCP/IP SSL/TLS編』、p.406。
  7. ^ 『マスタリングTCP/IP SSL/TLS編』、p.400。
  8. ^ Jacob Hoffman-Andrews (2014年11月11日). “ISPs Removing Their Customers' Email Encryption”. 電子フロンティア財団. 2014年11月21日閲覧。
  9. ^ 『マスタリングTCP/IP SSL/TLS編』、p.407。
  10. ^ 『マスタリングTCP/IP SSL/TLS編』、p.409。
  11. ^ 『マスタリングTCP/IP SSL/TLS編』、p.451。

参考文献

Eric Rescorla、齋藤孝道、古森貞、鬼頭利之（訳）、2003、『マスタリングTCP/IP SSL/TLS編』、オーム社 ISBN 978-4274065422

関連項目

外部リンク

  • SMTP TLS Tests and Tools（TLS接続が可能かテストできるウェブサイト。"Receiver Test"をクリックしてメールアドレスを入力すると、メールアドレスをホストしているメールサーバで、本項で述べたSTARTTLSコマンド発行の様子を確認できる。英文）
スタブアイコン

この項目は、インターネットやウェブに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.