要約

  • RFC 8314はメールアクセスと送信にImplicit TLSを推奨する。465、993、995などでは、TCP接続の直後、アプリケーションコマンドより前にTLSハンドシェイクが始まる。
  • その選択が保護するのは通信路の開始過程である。期待したサービスの検証、利用者の認証、メールボックスや送信元の認可、受付や最終配送は別の証拠を要する。

運用画面には「暗号化済み」「認証成功」と並び、その下に「送信元を許可できない」と出ていた。三つの表示は同時に正しい。最初は通信路、次は資格情報、最後はそのアカウントが特定のアドレスとして送れるかという政策判断を表しているからだ。

メールクライアントの小さな鍵アイコンは、この長い順序を見えなくする。設定されたサービス名から宛先を発見し、アドレスとポートへ接続し、TLSの方式と暗号条件を交渉し、証明書のサービス名を照合する。その後にアプリケーションの認証を行い、サーバーがアカウントと権限を結び付け、個別のコマンドを許可または拒否する。前段の成功は後段の入力になるが、後段の結論ではない。

Keith MooreとChris Newmanは2018年にRFC 8314を発表した。文書はMail User Agentとメールアクセス／送信サーバーの間で平文を通常運用に使い続けることを廃止すべきものとし、POP、IMAP、SMTP Submissionでは、平文接続をSTARTTLSなどで昇格させる方式よりImplicit TLSを優先するよう勧告した。

Implicitとは、利用者に見えないという意味ではなく、TLSを開始するタイミングを指す。既定ポート465のsubmissionsサービスでは、TCP接続が成立すると直ちにTLSハンドシェイクが始まる。IMAPでは993、POPでは995が同じ型だ。TLSの確立後、残りの接続でメールプロトコルを話す。STARTTLSは、いったん平文のアプリケーションセッションを開き、能力を確認し、昇格コマンドを発行してからTLSへ移る。

Implicit TLSは昇格前のコマンド区間をなくす。しかし、465という数値自体は暗号学的証拠ではない。設定にそのポートがあっても、実際にどのIPアドレスへ到達し、何が待ち受け、どの証明書を提示し、クライアントが何を検証したかは分からない。ポートは接続の入力であり、ハンドシェイク記録の代用品ではない。

RFC 8314は移行期も扱っている。587上のSTARTTLSが広く配備されていることを認め、一定期間は587/STARTTLSと465/Implicit TLSの両方を実装するよう勧める。したがって、すべてのSTARTTLSを危険と断定するのは文書の射程を越える。重要なのは、昇格機能が消えたり失敗したりした時に、クライアントが保護を必須として中止するかどうかだ。

RFC 2595はIMAP、POP3、ACAPのSTARTTLSを定義し、中間者が能力一覧から昇格を取り除く、または昇格を失敗させる可能性を説明した。ただし能力の欠落だけで攻撃を断定することもできない。サーバー設定や版の違いかもしれない。生の能力応答、クライアントの必須設定、失敗後の動作を一緒に残して初めて、降格が判定できる。

TLSが始まっても、照合する名前が必要だ。RFC 8314は対象クライアントに証明書検証の実装を求める。別の著者による後年のRFC 9525は、現在の一般的なサービス識別の枠組みを示す。クライアントは信頼できる設定や入力から参照識別子を組み立て、証明書経路を検証し、サーバーが提示した識別子との一致を探す。DNS解決の途中で現れた名前が、自動的に参照識別子へ昇格するわけではない。

一致の成功が認証するのは、その手続きの範囲にあるアプリケーションサービスだ。クライアントを操作する人ではない。サーバーが常に正しく動くことや、検証対象外の名前まで支配することも保証しない。そして利用者にメールボックスへの権限を与えない。サーバー側の主体と利用者側の主体は分けて記録する必要がある。

クライアント証明書を使っても境界は残る。RFC 8314はそれを任意に利用できるとしながら、証明書が提示された後にもアプリケーションレベルの認証を要求できるとしている。相互TLSが成功しても、証明書をどのアカウントへ対応付け、どの権限を与えたかがなければ、操作の認可は証明できない。

SASLは二種類の主体を明示する。RFC 4422のauthentication identityは資格情報に結び付く主体、authorization identityはクライアントがその名で行動したいと求める主体だ。サーバーは資格情報を検証し、前者が後者として行動できるかを判断する。認証と委任のどちらかが通らなければ、このやり取りは成立しない。別の認可主体を省略して「自分として行動する」と求めても、サーバーの権限判断は省略されない。

送信サービスにはさらに固有の政策がある。RFC 6409はMessage Submissionを中継から分け、587を送信用ポートとして予約する。Message Submission Agentは認可された利用者だけを受け入れ、認証結果と整合しない、または権限のないMAIL FROMを拒否できる。TLSでMSAへ到達したという記録は、送信元、宛先、サイズや内容を事前承認しない。

MSAの受付成功も最終配送ではない。その時点で次工程への責任を引き受けたことを示すにすぎず、中継、受信側の応答、フィルター、メールボックスへの格納、人間の閲覧は後に続く。「TLS成功」「サービス一致」「利用者認証」「操作認可」「送信受付」「配送完了」を一つの緑色へ畳み込んではならない。

再現できる証拠は順番を保存する。設定されたサービス名と発見入力、得られたアドレスと実際のポート、TLS開始方式、トランスクリプト、版と証明書、信頼経路、参照識別子と一致結果を残す。続いてSASL方式、認証主体、要求した認可主体、サーバーの政策、コマンドと正確な応答を記録する。送信後の転送・配送記録はその先に接続する。

NewmanとMooreの仕事は、ポートに万能の信頼を与えたのではない。保護を接続の最初へ移し、後続の判断を後続の証拠として残した。Implicit TLSは通信路を作る。利用者の権限はサービスが別途決める。

情報源