用語辞典・メール

STARTTLS

STARTTLSとは

STARTTLSは、平文で始めた通信を途中からTLS暗号化へ切り替えるためのSMTPやIMAPなどの命令です。正式名称はStart Transport Layer Security(スタート・トランスポート・レイヤー・セキュリティ)に由来し、一般に「スタートティーエルエス」と読みます。

最初に通常のプロトコルで接続し、サーバーがSTARTTLS対応を広告したことを確認して命令を送ります。成功応答後にTLSハンドシェイクを行い、同じTCP接続の残りを暗号化します。

STARTTLSという名前は暗号方式ではなく、接続の状態を平文からTLSへ切り替える合図です。TLSを開始しただけでなく、証明書検証と暗号化必須条件まで確認します。

平文で能力を確認し、切替点でTLSハンドシェイクを行い、同じ接続を保護された通信路として続けるTLS確立前に得た能力情報を捨て、保護後にもう一度問い合わせる
端末とサーバーの一本の接続が途中の切替点で鍵交換を行い、その後は透明な保護トンネルの中を進むSTARTTLSのピクトグラム図解
図1切替前の命令や応答は暗号化されません。資格情報やメール内容は、TLS確立を確認した後に送ります。

接続の状態が変わる五つの境界を読む

同じソケットの上で、プロトコルの解釈と安全条件が切り替わる順序を確認する途中の一段を飛ばして認証情報や本文を送らない
Plain平文で接続する

サーバー挨拶を受け、まだ秘密情報を送らず能力確認を始める

Advertise対応広告を確認する

SMTPならEHLO、IMAPならCAPABILITYなどからSTARTTLSの提供を知る

Command切替を要求する

成功応答が返った直後から、通常命令ではなくTLS記録を交換する

HandshakeTLSを確立する

暗号条件を合意し、証明書の信頼・名前・期限を検証する

Reset能力確認をやり直す

保護前の情報を捨て、TLS後の状態でEHLOなどを再実行する

Protected認証・本文を送る

必要な安全条件を満たしたことを確認してプロトコルを続ける

図2TLS後は利用できる認証機構などが変わり得ます。保護前の能力一覧をそのまま使いません。

暗黙的TLSは、最初の1バイトからTLSで始まる

STARTTLSはプロトコル平文からアップグレードするexplicit TLS(エクスプリシット・ティーエルエス/明示的TLS)です。対して暗黙的TLSは、TCP接続直後からTLSハンドシェイクを始め、その内側でSMTPやIMAPを話します。

メール利用者の投稿・アクセスでは、RFC 8314が暗黙的TLSを推奨しています。一方、SMTPサーバー間配送ではポート25上のSTARTTLSが広く使われます。設定画面の「SSL/TLS」と「STARTTLS」は、接続開始時の手順が違うため取り違えられません。

機会的暗号化と必須暗号化では、失敗時の動作が違う

サーバー間SMTPのSTARTTLSは、相手が対応すれば暗号化し、対応しなければ平文で続けるopportunistic encryption(オポチュニスティック・エンクリプション/機会的暗号化)として使われることがあります。到達性を優先できますが、暗号化を保証しません。

利用者が投稿サーバーへ資格情報を送る場合は、TLSが確立できなければ中止する設定が必要です。配送でもMTA-STS、DANE、REQUIRETLSなど別のポリシーで必須条件を強化できます。STARTTLS広告の存在だけで保証とみなしません。

広告を消す攻撃に備え、期待するTLSを記憶する

切替前の能力確認は平文なので、通信途中の攻撃者がSTARTTLS広告や命令を削除するSTARTTLS stripping(スタートティーエルエス・ストリッピング)を試せます。クライアントが「なければ平文で続ける」と、攻撃を検出できません。

利用者設定ではTLS必須にし、以前使えた暗号化が突然消えたら接続を止めます。サーバー間配送ではポリシー公開やDNSSECと組み合わせ、相手がTLSを要求していることを検証します。

暗号化表示だけでなく、証明書の検証を行う

TLSは接続先の証明書を提示します。クライアントは信頼された発行元か、接続先ホスト名と一致するか、有効期間内か、失効やアルゴリズム条件を満たすかを確認します。

警告を無視して続けると、暗号化された相手が攻撃者という状態になり得ます。メールアドレスのドメインではなく、設定で指定したサーバーホスト名と証明書を照合する点にも注意します。

STARTTLS成功後は、プロトコル状態をリセットする

SMTPではTLSハンドシェイク完了後、クライアントはEHLOを再送します。サーバーはTLS前に得たクライアント情報を捨て、クライアントもTLS前の拡張一覧を使いません。これは攻撃者が平文区間で改変した状態を持ち込まないためです。

認証済み状態の途中でSTARTTLSを実行するものではありません。接続、能力確認、TLS、再確認、SMTP AUTH、メール投稿の順に行います。

ログでは秘密ではなく、状態遷移と検証結果を残す

STARTTLS命令の成否、TLS版、暗号スイート、証明書名・発行元・期限、検証エラー、TLS後のEHLO結果を記録します。セッション鍵、パスワード、OAuthトークン、メール本文は診断ログへ残しません。

暗黙的TLSかSTARTTLSか、暗号化が必須か任意か、証明書を厳格検証するかを設定ごとに確認し、警告時に平文へ自動降格しないことが重要です。

切替手順と運用の確認資料:RFC 3207「SMTP STARTTLS」RFC 8314「Cleartext Considered Obsolete」RFC 9051「IMAP4rev2」

関連用語