PROFILPELAJAR.COM

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

特徴

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

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

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

プロトコルのSTARTTLS対応を規定するRFC

IMAP, POP3, ACAP	RFC 2595
SMTP	RFC 3207
FTP	RFC 4217
XMPP	RFC 6120 (5節)
LDAP	RFC 4511 (4.14節)
NNTP	RFC 4642

このうち、POP3、IMAP、SMTPについては、RFC 8314 でSTARTTLSよりも暗黙の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]。

脚注

注釈

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