他の人に情報が漏れることなく伝えたいというニーズは古く、紀元前 3000 年のバビロニア時代では読める人が限られていた象形文字自体が実質的な暗号として使われていたと言われています。古典的な暗号の代表例としては古代ローマ時代のシーザー暗号が有名でしょうか。
そして、情報を暗号化したいというニーズは、現代のインターネットの様々な場面で活用されており、メールでももれなく利用されています。
そこで、今回はその「メールの暗号化」をテーマについてお話しします。
メールで暗号化が利用されている箇所といえば、
・メール自体の経路暗号化
・認証情報の暗号化
・誤送信防止観点での PPAP方式
などがありますが、今回は「メール自体の経路暗号化」に絞ってお伝えします。
メール認証情報の暗号化に関わる Eメールアカウント侵害(EAC)や PPAP方式などの問題はまた次回以降でお伝えします。
●クライアントとサーバーとの間は、SMTPS(SMTP over SSL)、または STARTTLS
メールの経路では、「クライアントとサーバー間」、「サーバーとサーバー間」に分けられますが、クライアントとサーバー間の通信の暗号化といえば、SMTPS（エス エム ティー ピー エス：SMTP over SSL）と STARTTLS（スタート ティー エル エス）があります。
SMTPS(SMTP over SSL)では最初から暗号化通信するのに対して、STARTTLS では最初は暗号化されていない SMTP で通信をし、両者が SSL/TLS に対応可能かどうかを確認した上で、SSL/TLS で再接続を行います。現在では、STARTTLS の方が定着しています。
●サーバーとサーバーとの間の通信でも STARTTLS が一般的。でも課題も？
メールのサーバーとサーバーとの間の暗号化でも一般的なのは STARTTLS です。STARTTLS は、通信を暗号化する技術である SSL/TLS を、メールの送信用SMTPサーバーと受信用POPサーバー、IMAPサーバーとの間の通信に応用したもので、メールの盗聴などを防止するための大切な要素です。
メールでの TLS のグローバルでの普及率は、グーグル社が定期的にレポートを更新していますが、2022 年 2 月 24 日までの 3ヶ月分の最新のデータでは、送信のメールが 89 ％、受信のメールで 91 ％が TLS で暗号化されていると公開されています。
国内では、あるメールプロバイダーの情報によれば、TLS の普及率は 70 ％くらいとのことで、グローバルの状況と比べるとやはり若干普及が遅れています。
STARTTLS は、セキュアなメール送受信の基本ですから、自社のメールサーバー、あるいは利用しているメールプロバイダーのサービスが、STARTTLS に対応しているかどうか確認してください。
しかし、STARTTLS がサポートされていれば、メールの途中で情報が盗まれることはないのかというと、そうではありません。送信側も受信側も STARTTLS に対応していなければ、通信が暗号化されないという弱点があります。これは、“opportunistic encryption protocol”と言われているのですが、「できればやるけれども、できない場合にはやらない」というニュアンスで、送信側が STARTTLS を使用して暗号化して送っても、受信側が「STARTTLS に対応しています」と返してこなければ、送信サーバーは STARTTLS を使用せずに平文でメールを送信してしまいます。また、送信側と受信側の TLS のバージョンが異なると通信の暗号化が成立しません。
この仕組みを悪用して、攻撃者が中間に入り、受信側が STARTTLS に対応していないと思わせる攻撃(STARTTLS Downgrade Attack)や、TLS のハンドシェイクを改ざんすることで、既に推奨されていない TLS1.1 以下にダウングレードさせる攻撃（TLS Protocol Downgrade Attack）などにより、暗号化されていない平文メールを通信させられて盗まれてしまうのです。
以上のように、いくつかの弱点を持つ STARTTLS だけでは、完全に確実に暗号化されてメールが配送されるという保証はありません。
●MTA-STS のススメ
しかし MTA-STS でも守れないことがある
そこで登場するのが MTA-STS（エム ティー エー エス ティ― エス：MTA Strict Transport Security）です。MTA-STS は、簡単にいうと、メールの配送経路上のメールサーバー間の暗号化の仕組みを強化するためのもので、受信者側が TLS に対応しているかどうかを事前に確認でき、Web上での証明書が有効でなければ、メールを送らないモードを設定できます。
MTA-STS を使えば、STARTTLS の使用をポリシーとして指定できるため、サーバーに平文で送信されるリスクを低減できます。
また、MTA-STS では、TLS1.2 以上を必須としているので、暗号化のない状態や、脆弱な古い暗号方式で通信されることはありません。つまり、MTA-STS により、前述の STARTTLS Downgrade Attack や TLS Protocol Downgrade Attack を防ぐことができます。
STARTTLS では、Root CA（ルート認証局）からのトラストチェーンが切れていたり、有効期限が切れていたり、ホスト名が異なっていても、そのまま通信することがあります。
これに対して、MTA-STS では、ポリシーを広告する HTTPSサーバー、受信メールサーバー共に、証明書が有効期限内で、証明書のトラストチェーンが Root CA までつながっており、証明書の SAN がホスト名と一致しているかどうかを検証しますので、偽の証明書を使ったサーバーに対してメールが送信されることはありません。
しかし、不正な認証局から偽の証明書が発行される場合があります。MTA-STS は証明書のトラストチェーンを信頼していますので、Root CA までたどれるような偽の証明書の場合、偽物かどうかの区別はできずに、悪意のある中間者はメールを詐取できてしまいます。
この問題を解決するのが DNSSEC（DNS Security Extensions）と DANE です。
●DANE
設定は少しタイヘンだけれど…
DANE（デイン：DNS-based Authentication of Name Entities）は、MTA-STS と同様に、メールの配送経路上のメールサーバー間の暗号化の仕組みを強化します。
DANE は、TLSAレコードにより、TLSサポートしていることを送信サーバーに知らせ、STARTTLS での通信を必須にし、TLS1.0 以上（できれば 1.2以上）を必ず使うように要求することで、Downgrade Attack を防ぐことができます。
MTA-STS との違いは、送信先が正しいということの検証を、証明書のトラストチェーンで行うのではなく、DNSSEC のトラストチェーンと公開鍵や証明書を DNS の値と比較することで正当性を検証するところです。DNSSEC が検証できない場合、また、公開鍵が正しくない場合は、メールは配送されません。つまり、DANE が有効にするためには、DNSSEC が有効になっている必要があります。
MTA-STS では、DNS のキャッシュポイズニングなどで DNSレコード自体を詐称された場合には STARTTLS を無効化される場合があります。これに対して、DANE では DNSSEC を必須とすることでこの問題を回避しています。
また、前述のとおり、MTA-STS は証明書のトラストチェーンを信頼しているので、Root CA までたどれるような偽の証明書の場合、偽物かどうかの区別ができず、悪意のある中間者はメールを詐取可能です。
しかし、この問題についても、DANE では DNSSEC のトラストチェーンを検証することで、また、公開鍵が本物かどうかを検証することで回避しています。
●まとめ
メールの暗号化として、STARTTLS は広く使われるようになっており、メールはすでに暗号化できているから大丈夫だ！と思っていた方も、それだけでは万全ではないことがおわかりいただけたかと思います。
MTA-STS、DANE などの新しい技術により、STARTTLS の弱点を補いましょう。設定は少し難しいかもしれませんが、TwoFive がお手伝いしますので、何でもご相談ください。
正しい対策をし続けること、インターネットをより使いやすくしましょう。
著者プロフィール
株式会社TwoFive 渋谷 律（しぶたに りつ）
2018 年より、海外メールセキュリティベンダー製品のプリセールスとしてスパムフィルタの国内展開・導入サポートに従事。2021 年からは、株式会社TwoFive にてマーケティングを担当。イベントの企画・運営、なりすましメール対策の啓発活動に従事している。
株式会社TwoFive
国内大手 ISP / ASP、携帯事業者、数百万～数千万ユーザー規模の大手企業のメッセージングシステムの構築・サポートに長年携わってきた日本最高水準のメールのスペシャリスト集団。メールシステムの構築、メールセキュリティ、スレットインテリジェンスを事業の柱とし、メールシステムに関するどんな課題にもきめ細かに対応し必ず顧客が求める結果を出す。
