セキュアなメール配送（MTA間通信)を考える＋DNSSEC

セキュリティ 暗号

2015年現在、メール配送の終着点（メールボックスサーバー）とエンドユーザーの間は、ほとんどのメールサービスでPOPS・IMAPSあるいはHTTPS上のウェブメールが利用でき、TLSによるセキュアな通信が可能になっています。

一方で、メール配送、すなわちMTA間のSMTPは未だにセキュアな通信がほとんど実現されていません。 私の確認した限り、実際に著名なサービスでは暗号論的な意味でセキュアなメール配送に対応しているものは見当たりませんでした。

SMTPクライアント側（送信者側のなりすましの排除）

かつて、メールの送り主のメールアドレスは自由に詐称可能でした。 自分のメールアドレスを勝手にスパムに使われて、実情を理解しないスパム被害者からのクレームを受け、対応に苦慮した人も多いと思います。

現在はDKIMを用いた送信者認証が利用でき、受信したサーバーは一部のヘッダの偽装を排除することができるようになりました。

DKIMでは、Fromなど詐称されたくないヘッダについて送信者が署名し、その公開鍵はDNS上で公開されます。

$  dig bulk201106._domainkey.mail.yahoo.co.jp TXT
  ...
bulk201106._domainkey.mail.yahoo.co.jp. 900 IN TXT "v=DKIM1\; g=*\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGY5yeT3LUrd1662jmLZE1StxUbNVewEtDBGprWSKoyTdVFxp/OUVmZPom2v7/DCNt6sbisit7SwwpwT9U/gTGFlYHEyh2RShWe05ppMoc3gRBkAlC8SLaZ/SDtVgkUa4eIYkzWt1JXEANOXvXmZ0hxFxhLq0yLio1S7S/kg8KrwIDAQAB"
  ...

このようにDKIMはDNSに完全に依存しているため、DNSインジェクションなどには脆弱です。 安全に運用するためには、DNSSECで署名したり、それが不可能であれば攻撃耐性を高めるためにTTLを増やすといった緩和策が必要です。

なお、SPFも送信者をある意味で認証する技術ですが、これはアクセス制限や攻撃検知の一種であり、暗号化ではありません。 SPFでは、送信者のドメイン毎に送信して良いIPアドレス範囲をDNSのTXTレコードで指定します。（IPアドレスベースアクセス制御）

まとめると、送信者側の認証には

  • DKIMによる送信者アドレスの署名
  • DNSSEC署名されたTXTレコードの検証

への対応が必要です。

原状、DKIM署名とDKIM検証、DNSSEC検証に対応したサービスはいくつかあるようですが、 DNSSEC署名されたDKIMレコードを見つけることができませんでした。

SMTPサーバー側（受信者側の認証）

メール本文を盗聴などから保護するためには、SMTPサーバーとセキュアに通信する必要がありますが、こちらはやや困難です。

TLSによる暗号化通信

SMTPサーバーとの接続ではSTARTTLSコマンドを送るとTLSによる暗号化を利用できます。（あるいは implicitな SMTP over SSLを使う）

通常、SMTPサーバーはそのホスト名に対応する証明書チェーンを提示します。クライアントはその証明書を、手元の信頼された認証局のルート証明書の公開鍵で連鎖的に信頼されているか確認し、証明書の識別名（あるいはSANs）がサーバーのホスト名と一致することをもって信頼されたサーバーであることを確認します。

このSMTPS (SMTP over SSL あるいは with STARTTLS)は、著名なサービスの多くで有効になっているため、SMTPサーバーどうしの通信は暗号化されている事が多くなっています。

MXレコードの署名確認

だれだか分からない匿名の相手と暗号化通信しても安全にはなりません。相手が本当にメールを受け取るべき相手なのか認証する必要があります。

MTAではメールアドレスのドメイン部分のMXレコードをDNSで問い合わせることで、正しい信頼された送信先サーバーを特定します。

$ dig gmail.com MX
...
gmail.com.      2628    IN      MX      5 gmail-smtp-in.l.google.com.

このように、メール配送先決定がDNSに依存しているため、この結果が正しいことを保証するためには、MXレコードがDNSSECによって署名されている必要があります。さもないと、DNSインジェクションによって攻撃者が所有しているドメインへ接続させられているかもしれません。

残念ながら、著名なサービスでMXレコードがDNSSEC署名されているものは見当たりませんでした。

フォールバックの無効化

SMTPにはフォールバック問題があります。 これはもしSTARTTLSコマンドや検証に失敗すると、SMTPクライアントはサーバーがTLSに対応していないと判断して、TLSを使わず平文のまま通信してしまうというものです。

ウェブの世界では、アドレスにhttps://という新しいスキームが導入されたため、このような問題はありません。https://と指定したのにHTTP通信している場合、それは実装の脆弱性です。 さらにHSTSの導入により、InternetExpolorerを除くモダンブラウザでは、ユーザーの入力ミスやウェブサイトの誤動作で誤ってhttp://へ接続してしまうことを、『最初のアクセス』を除いて、防ぐことができるようになりました。 Google Chromeでは、『最初のアクセス』を保護するためにHSTS preloading（ブラウザ出荷時にHSTSが有効と知られているドメインのリストを同梱しておく）を行っています。さらに将来的には後述するDANEの導入により、全てのアクセスが保護されるものと期待できます。

TLS・SSL自体やその実装にも、いくどかフォールバック・ダウングレード脆弱性が発覚していますが、FALLBACK_SCSVオプションやSSLv3.0の無効化など、脆弱性対応がなされています。

メールアドレスにはTLS（SSL）導入に際して、https://に相当する新しいスキームが取り入れられることはありませんでした。 そのため、接続先サーバーがSMTPに対応しているのか調べる方法は、ほとんどありません。せいぜい、著名なサービスに対してフォールバックしない、というホワイトリストを作成しておくくらいです。

将来的には、DANEによる証明書存在証明をSMTPフォールバック問題の解決に利用することが期待されます。これはRFCドラフトになっています。

DANEでは、TLSAレコードという新しいレコードにより、ホスト名・プロトコル・ポート番号に対して、信頼済み証明書あるいはそのハッシュを明示することができます。 TLSAレコードが存在することをDNSSECで検証することが出来れば、そのSMTPSサーバーではTLS接続が可能であることみなせるため、フォールバック脆弱性は解決されます。

まとめると、

  • サーバーのホスト名に対して有効な証明書
  • DNSSEC署名されたMXレコードによる信頼されたメールホスト名
  • DNSSEC署名されたTLSAレコードによるフォールバックの禁止

これらに対応する必要があります。

MTA実装ではすでにDANE対応が進められていますが、DNSSEC署名されたTLSAレコードを公開しているサービスはみかけません。

まとめ

原状、暗号を用いたセキュアなメール配送を行っているメールサーバーは、DNSSEC署名の対応状況から見て非常に少ないと考えられます。

DNSやメールサーバー間の通信経路は、多くのレイヤのネットワークオペレータの努力により、十分には安全であると考えられていますが、完全ではありません。（もちろん暗号を利用すれば完全というわけではありませんが）

メールを預けるメールボックスサービスがいくら信頼できるとしても、MTA間の通信が安全であるかといえば、私には不十分と感じられます。

重要なメールを送信する際は、S/MIME・PGP公開鍵暗号による、エンドツーエンドの暗号化の導入を検討してみてください。学習コストは高いですが、導入自体は（少なくともDNSSECの煩雑さよりは）容易です。

(6/26 typo・微妙な表現を修正)