「STARTTLS」「TLS通信」「MTA-STS」　OP25Bから始まった情報漏洩に対抗するためのメール通信経路の暗号化

通信経路上の暗号化について

加瀬正樹氏（以下、加瀬）：次はこの紹介した手段の中で、特に通信の暗号化、Eについて、櫻庭さんから詳しい技術的な解説や最新の情報をプレゼンしてもらいたいと思います。櫻庭さん、よいでしょうか？

櫻庭秀次氏（以下、櫻庭）：では、私から通信経路上の暗号化について、技術の概要になると思いますが、データ保護のメール技術に特化して話したいと思います。

話す内容は、SMTP上の暗号化といえばSTARTTLSという、みなさん知っているTLS用の暗号化通信です。それに関連したところと、あとDANE。また、これらをサポートするための技術として、MTA-STSとTLSRPTについて紹介します。

SMTPが使われる局面

SMTPが使われる局面はみなさん知っているとは思いますが、改めて説明すると、1つは、MUA（メーラー）からMSA、Submission Agentです。投稿サーバーに対して通信、メール投稿を行うときに、ここでもSMTPが使われます。

OP25B（Outbound Port 25 Blocking）の頃を知っている方はわかると思いますが、10数年前にMTA間での通信で25番ポートを使うため、個人利用、動的IPアドレスからは送信できなくするために、その25番ポートを閉じて、「Submission Port」と言われる、587番を使うプロモーションが行われました。587番を使って、SMTPで通信やメール投稿を行います。それ以降は、MTA間でも25番を使って、同じようにプロトコル的にはSMTPを使って送ります。

SMTP上で暗号化する仕組み“STARTTLS”

このSMTP上で暗号化するのが、“STARTTLS”と呼ばれている仕組みです。基本的にはTLSのセッションを行います。右側のMTA間に少しやりとりを書いていますが、最初にEHLOです。拡張Helloの合図を送り手がしたとき、受信側の受け手が“STARTTLS”というグリーティングを返せば「受け手も対応しているんだな」ということで、送信側のMTA、ここでは真ん中の「example.com」ですが、それ以降STARTTLSを発行して、TLS通信が行われるというのが基本的な流れです。

基本的に古くからメールの中では、SMTP上の暗号化TLSについては、SMTPセッション中に行うのが基本的な仕組みでした。

一時期、465番ポート、over TLS、昔はSSLと言っていましたが、これがほかのプロトコルと重なっていて。ここではURDと書いていますが、これに割り当てられていたおかげで、もともとは「587番使いましょう」というかたちでした。現状、再度に新たにRFCが出て、over TLSとしてsubmissionに限り、「submissions」として465番ポートが一応割り当てられているのが現状のようです。

ただ、いろいろな歴史的経緯としての標準化の過程で、行きつ戻りつがあった関係なので、原則的には一応メール投稿の場合は587番、「submission」の中でTLSを行うのが推奨にはなっています。一応これが現状のSMTP上のTLSの整理です。

TLS、STARTTLSの普及状況

TLS、STARTTLSがどれだけ使われているのかの状況は、グーグルがレポートを定期的に更新しています。2021年2月24日までの3ヶ月分の最新のデータを見ると、送信のメールで92パーセント、受信のメールで94パーセントと公開されています。ほぼすべてのSMTPのやりとりの大部分、92パーセント以上はTLS通信が行われているようです。

「国内ではどうだ？　あまり普及していないのではないか？」という話が昔からあるので、2020年10月の段階での弊社のサービスをちょっと調べました。弊社のサービスから出るメールは69.6パーセント、70パーセント近くですね。受け取るメールは62.5パーセントがSTARTTLSによって行われている記録が得られました。

思っているより、暗号化が国内でも進んでいるように思います。グーグルのレポートと比べて若干低めに出ているのは、「受け手あるいは送り手として、まだTLS、STARTTLSに対応されていない巨大なメールサーバーがいるからではないか？」と推測をしています。

STARTTLSがサポートされていれば情報は盗まれない？

もう1つ、ではSTARTTLSがサポートされていれば、メールの途中で情報が盗まれることはないのかというと、そうではないのが、ここいくつかのいろいろなカンファレンスでも言われてきたことと思います。その大きな問題としては、先ほど手順をちょっと説明したとおり、STARTTLSが“opportunistic encryption protocol”“投機的なプロトコル”と呼ばれることがありますが、基本的には「やれたらやる」かたちです。

先ほどの例でも、受信側が「STARTTLSに対応していますよ」と返してこなければ始まらない。また、送り手もSTARTTLSに対応されていなければ、そもそもTLSの通信が開始されない。TLSのバージョンなど、使えるものが一致しなければ成り立たないところもあります。お互いの様子見的な仕組みによって、完全に確実に暗号化されてメールが配送される保証がなくなっています。

中間者、Man in the Middleみたいなものがいて、途中でいったん終端して片方を平文にしたり。いったん終端させればメールは中身が見れるため、窃取できることが大きな問題として言われています。これが“Downgrade Attack”や“Interception Attack”と呼ばれる手法です。

昨今の情報漏洩の問題

2020年のJPAAWGのGeneral Meetingでも話がありましたが、昨今のもう1つ大きな問題として、DNSの設定のアカウントを盗まれて、メールのMXの宛先自体を捻じ曲げられて読まれるようなケースが、どうもポツポツと発生しているようだ、という状況も聞いています。

誰がメールの配送上の情報を盗むのかは、私もちょっと懐疑的な部分はありました。例えば、BGPのハイジャックなど、いろいろ手法はあるかと思いますが、そんなにないのではないかと思いつつ、DNSを直接書き換えてコントロールされてしまうと、盗られるのは往々にしてあるのかな。そんな遠い世界の話ではないのかな。

あともう1つ、こういうTLSが叫ばれているのは、やはり欧米を中心とした盗聴の問題です。これはISPやクラッカーみたいな人が何か仕掛けを使って盗む手段よりは、より大きな存在が見ているのではないかと。そのとき、暗号化していないと簡単に読まれてしまうことを非常に懸念している。そのために、STARTTLSです。TLSをもっと普及させなきゃいけないのだろう、という動きだと理解しています。

確実にTLS通信が行える仕組み“MTA-STS”

確実にTLS通信が行えるようする仕組みが、RFCとして出てきたのがMTA-STSです。

基本的に「_mta-sts」というサブドメインを作って、そのドメインが“STSに対応していますよ”という印をつければ、well-knownのパスからMTA-STSの情報を取って、TLSのステータスの状況を報告する仕掛けになっています。

ここでmodeがenforceになっていればTLS通信以外を受け取りません。受け手は受け取らないし、送り手はこれに沿わないといけません。

また、DMARCと同じようにレポートの仕組みもあります。これは「_tls」の上に「_smtp」というサブドメインを作り、レポートの送り先へ送ります。DMARCと違うのは、送り手が受け手に対してTLSの状況をレポートする仕掛けです。受け取らない可能性もあるので、メール以外に、httpsでもデータ受け渡しの仕組みもTLSRPTでは作られています。データはDMARCとは違ってJSON形式です。

これが最近の、実際にTLSRPTのデータとして受け取ったJPAAWGのドメインです。残念ながらvalidation-failureでfailureしているのが1件、うまくいっているのが0件という結果になっていますが。こういったかたちでTLSRPTでは送り手と受け手の状況と、TLSのセッションの状況とがわかるようになっています。

RFCで標準化されているDANE

ちょっとM3AAWG（The Messaging, Malware and Mobile Anti-Abuse Working Group）としては、最近ではより暗号化。もっと広く使うという意図もあり、DANEという技術が、RFCで標準化されてきています。

もともと「公開鍵暗号技術を使って暗号化する」が、インターネットにおける暗号化の流れですが、相手と送り手の間で問題になるのは公開鍵です。難問と言われていますが、送り手に対してあらかじめどう渡しておくか。

S/MIMEも、証明書、いわゆる公開鍵の情報を、送り手に対してどうやって事前に渡しておくか。PGPもそうですが、非常に難しいです。PKIの問題とか言われていますが、公開鍵をメールを送る前に渡さなきゃいけない手間が、非常に難しい。これをDNSを使って公開しておこうというのが、DANEのもともとの思想です。

これは25番、SMTPだけに限らず、httpsでも同様の仕組みができます。これによって自己証明というか、DNSに紐づいているので、そこは信頼して、さらにDNSSECで担保した上で、公開鍵を取得できるような仕組みがDANEです。

これに関連して、TLSにおけるDANEが一応Proposed Standard、standard（標準）としても提案されていますが、かなり昔からPGPの仕組みであるOpenPGP、PGP/MIMEと言う人もいますが、PGPの仕組みやS/MIMEの仕組みも、同じようにDNS上に鍵の情報を乗っけて、それを使うことで事前に受け渡しの手順を省いて暗号化、MIMEを使って暗号化のパートを作って送るような仕掛けも、一応提案はされています。

ちょっと長くなりましたが、私のセッション、案内は以上です。

（次回につづく）