MTA-STSとTLS-RPTの設定方法:メール傍受を防止する

毎日、数十億通の電子メールが が毎日インターネット上を移動しており、そのかなりの部分が依然として強制的な暗号化なしに送受信されている。この規模の大きさだけでも、電子メールは傍受にとって最も魅力的な標的の一つとなっている。メッセージは送信中、送信者も受信者も気付かないまま読み取られたり改ざんされたりする可能性があるのだ。

弱点は電子メールの配信方法にある。SMTPは機会的暗号化に依存しており、攻撃者がSTARTTLSコマンドを削除または改ざんし、接続を平文通信に強制的に降格させることが可能だ。こうしたSMTP降格攻撃は中間者攻撃の侵入経路となり、攻撃者が通信を監視したり、機密情報を取得したり、自身が制御するサーバー経由でメッセージを転送したりすることを許す。

メール転送エージェント厳格なトランスポートセキュリティ(MTA-STS)は、送信メールサーバーと受信メールサーバー間の暗号化されたTLS接続を必須とし、安全な通信経路が確立できない場合に配信を拒否することで、このギャップを埋めます。暗号化が使用されることを期待するのではなく、MTA-STSはそれを強制するため、メールセキュリティ戦略の一環としてMTA-STSの導入を検討する組織にとって不可欠な存在です。

暗号化 tls

MTA-STS(Mail Transfer Agent-Strict Transport Security)について

MTA-STSは、その名称が示す通り、2台のSMTPメールサーバー間でメッセージを暗号化して転送することを可能にするプロトコルです。 MTA-STSは送信サーバーに対し、メールはTLS暗号化接続経由でのみ送信すべきであり、STARTTLSコマンドによる安全な接続が確立されない場合は一切配信すべきでないと指定します。メールの転送中のセキュリティを強化することで、MTA-STSはSMTPダウングレード攻撃やDNSスプーフィング攻撃などの中継者攻撃(MITM)の軽減に役立ちます。

MTA-STSによる暗号化の確保

電子メールはSMTPを使用してサーバー間で配信されます。このプロトコルは暗号化をサポートしますが、デフォルトでは必須ではありません。これにより、メッセージが保護なしで送信される可能性が生じます。MTA-STSは、暗号化配信をオプションではなく必須要件とすることで、このギャップを埋めます。

メール配信時の暗号化処理を理解するには、[email protected]宛てにメッセージを送信するメールサーバーを例に考えてみましょう。送信側のメール転送エージェント(MTA)はまず、powerdmarc.comのMXレコードを取得するためDNSクエリを実行し、メッセージ受信を担当するメールサーバーを特定します。 送信側のMTAは次に、それらのサーバーのいずれかに接続し、STARTTLSコマンドを使用してTLS暗号化をサポートしているかどうかを確認します。TLSが利用可能な場合、メールは暗号化された接続を介して送信されます。利用できない場合、送信サーバーは安全な接続のネゴシエーションに失敗し、強制がない限り、メッセージを平文で送信するフォールバックを行う可能性があります。

MTA-STSは、サーバー間通信において厳格なセキュリティ要件を適用することで、この配信動作を変更します:

MTA-STSは、送信メールサーバーに対し、TLS暗号化接続を介してのみメッセージを配信するよう指示します。暗号化が確立できない場合、メッセージは一切配信されません。これにより、傍受を可能にする平文への無言のフォールバックが排除されます。

受信メールサーバーは有効なTLS証明書を提示する必要があり、その証明書上のドメイン名はMTA-STSポリシーで定義されたドメインと一致しなければなりません。これにより、送信サーバーが正しい宛先と通信しており、なりすましホストではないことが保証されます。

MTA-STSポリシーは、セキュアなWebサーバーからHTTPS経由で取得されます。暗号化および認証されたチャネルを通じてポリシーを取得することで、攻撃者が転送中にポリシー指示を改ざんまたは偽装することを防止します。

暗号化を強制し、証明書とポリシー指示の両方を検証することで、MTA-STSはSTARTTLSコマンドの削除や改変に依存するSMTPダウングレード攻撃を阻止します。送信サーバーは、セキュアな接続が存在するべき状況において、もはや安全でないフォールバックを受け入れません。

MTA STSサービス主催
ホスト MTA STS

MTA-STSは、送信メールサーバーが指定されたサブドメインからポリシーファイルを取得するよう指示するDNSレコードを公開することで実装されます。ポリシーファイルはHTTPS経由でアクセスされ、TLS証明書を使用して検証され、受信者のメールサーバーの承認済みホスト名を含みます。このプロトコルは、送信SMTPサーバーに対し、暗号化された接続を要求し、TLS証明書に記載されたドメインがポリシーファイルで定義されたドメインと一致することを確認するよう指示します。 MTA-STSが強制されている場合、暗号化チャネルのネゴシエーションが成立しないときは、メッセージは一切配信されません。

MITM攻撃の仕組み

基本的にMITM攻撃は、攻撃者がSTARTTLSコマンドを置き換えたり削除したりして、TLS暗号化なしで安全な接続を安全でない接続にロールバックさせることで起こります。これはダウングレード攻撃と呼ばれています。ダウングレード攻撃に成功すると、攻撃者はメールの内容に支障なくアクセスし、閲覧することができます。

また、MITM攻撃者は、DNSクエリ応答のMXレコードを、自分がアクセスしてコントロールしているメールサーバーに置き換えることができます。その場合のメール転送エージェントは、攻撃者のサーバーに電子メールを配信し、攻撃者が電子メールの内容にアクセスして改ざんできるようにします。その後、その電子メールは、検出されることなく、意図した受信者のサーバーに転送することができます。これは、DNSスプーフィング攻撃として知られています。

SMTPダウングレード攻撃

警告サイン

MITM攻撃はしばしば静かに動作しますが、特定のパターンがメール配信中に異常を知らせる場合があります。一般的な警告サインの一つは、特定のドメインとの通信時に予期せぬ配信失敗や遅延が発生することです。特に、それらのドメインが以前問題なくメッセージを受け入れていた場合に顕著です。TLSネゴシエーションの失敗が急増したり、暗号化されていない接続へのフォールバックが発生したり、STARTTLSエラーが繰り返し発生したりすることも、送信中の妨害を示唆する可能性があります。

別の指標として、メールのルーティング動作に一貫性がないことが挙げられます。メールが見慣れないサーバーを経由しているように見える場合や、ログに受信者の公開MXレコードと一致しないホストへの接続が記録される場合があります。より深刻なケースでは、メッセージが改変されたり、切り詰められたり、明確な説明なしに中間システムを経由して転送されたりすることがあります。

検出は可視性に大きく依存します。SMTP接続ログの監視により、繰り返される暗号化失敗や証明書不一致を特定できます。TLS-RPTは、サーバーが安全なTLS接続を確立できなかった場合にレポートを提供し、ダウングレードの試行、無効な証明書、ポリシー適用失敗などの問題をフラグ付けすることで、さらなる保護層を追加します。 

これらのシグナルはすべて、通常のメールフローでは隠れたままになる中間者攻撃(MITM)活動を可視化するのに役立ちます。

MTA-STSポリシーファイル

MTA-STSポリシーファイルは基本的に単純なテキストファイルであり、以下のような形式です:

バージョンである。STSv1
モード: エンフォース
mx: mx1.powerdmarc.com
Mx: Mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age:604800

注: バージョンフィールドはテキストファイルの先頭に置く必要がありますが、その他のフィールドは任意の順序で組み込むことができます。

ポリシーファイルはキーと値のペアを使用し、各値は上記のようにテキストファイル内で別々の行にエンコードされます。このファイルのサイズは最大64KBまで拡張可能です。ポリシーファイルの名前は mta-sts.txt ポリシーファイルは、ドメイン内のメールサーバーを追加または変更するたびに更新する必要があります。

注意:MTA-STSをenforceモードに設定すると、一部のメールが配信されないことがあります。そのため、ポリシーモードをtestingに設定し、max_ageを低く設定して、すべてが正しく動作していることを確認してからenforceポリシーに移行することをお勧めします。テストモードのポリシーにもTLS-RPTを設定し、メールが平文で送信された場合に通知を受けることをお勧めします。 

MTA-STS-ポリシー

MTA-STSポリシーファイルの公開方法

MTA-STSポリシーファイルを公開するためには、ファイルをホストするWebサーバーが必要です。

  • HTTPS/SSLに対応

    ポリシーファイルは、送信メールサーバーが安全に取得できるように、HTTPS対応のWebサーバー経由で提供されなければなりません。

  • 信頼できる認証局が発行した証明書を使用する

    サーバー証明書は、送信側のメール転送エージェント(MTA)がポリシーの送信元を認証できるように、サードパーティのルート認証局によって署名および検証されている必要があります。

  • ファイルを専用の mta-sts サブドメインでホストする

    公開Webサーバーは、ドメインにサブドメイン「mta-sts」を追加して設定する必要があります。このサブドメインは、MTA-STSポリシーの公開専用に使用されます。

  • ポリシーファイルを必要なディレクトリに配置してください

    ポリシーファイルは mta-sts.txt という名前で、mta-sts サブドメインの .well-known ディレクトリ内に公開する必要があります。

  • ポリシーファイルが正しいURLで一般にアクセス可能であることを確認してください

    送信元MTAは、認証やリダイレクトなしに、
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt 形式の場所からファイルを取得できる必要がある。

ホスト MTA STS

MTA-STSのDNSレコード

MTA-STS用のTXT DNSレコードは、お客様のドメインがMTA-STSプロトコルをサポートしていることを指定し、ポリシーが変更された場合にMTAにキャッシュされた値を更新するための信号として、お客様のドメインのDNS上に公開されます。MTA-STSのDNSレコードは、サブドメインの _mta-sts のように配置します。 _mta-sts.powerdmarc.com.TXTレコードは、v=STSv1で始まる必要があります。 "id"値には32文字までの英数字を含めることができ、以下のようになります。

 v=STSv1; id=30271001S00T000;

注:ポリシーを変更するたびに、TXTレコードIDの値を新しい値に更新する必要があります。 

MTA-STSのDNSレコードは以下のように使用されます。 

  • ドメインのMTA-STSのサポートを指定する
  • ポリシーが変更された場合、HTTPSでポリシーを再取得するようにMTAに信号を送る。

なお、MTA-STS TXT DNSレコードを使用すると、ポリシーが変更されていない限り、ポリシーを再取得することなく、MTAがポリシーファイルを長期間保存することができますが、ドメインでメールを受信するたびにDNSクエリを実行することになります。

ドメインにMTA-STSを設定する

お客様のドメインでMTA-STSを有効にするためには、以下のことが必要です。

  • にcnameタイプのDNSレコードを追加する。 mta-sts.example.comMTA-STSポリシーファイルをホストしているHTTPS対応のウェブサーバに向けて、cnameタイプのDNSレコードを追加します。

  • にtxtまたはcnameタイプのDNSレコードを追加します。 _mta-sts.example.com に追加して、ドメインのMTA-STSサポートを指定します。

  • ドメインに有効な証明書を持つHTTPS対応のWebサーバーを設定します。

  • ドメインのSMTP TLS Reportingを有効にすると、TLS暗号化の失敗によるメール配信の問題を検出できます。

spfレコードルックアップアイコン powerdmarc

手動によるMTA-STS導入の課題

MTA-STSを手動で展開するには、単一のDNSレコードを公開する以上の作業が必要です。ウェブインフラストラクチャ、証明書、ポリシーの調整と継続的なメンテナンスが必要であり、注意深く管理しないと複数の課題が生じる可能性があります。

  • HTTPS対応ウェブサーバーの要件

    MTA-STSポリシーは、有効なTLS証明書を備えた一般公開のHTTPSサーバー上でホストされなければなりません。これには、インフラストラクチャのプロビジョニング、TLSの適切な設定、証明書の期限内の更新、および高可用性の確保が必要です。

    解決策:ウェブインフラが限られている組織は、サーバーと証明書を自動的に管理するホスト型MTA-STSサービスを利用することで複雑さを軽減できます。

  • 継続的なポリシーファイルのメンテナンス

    メールサーバーの設定を変更する場合は、MTA-STSポリシーファイルの更新が必要です。ファイルが古い場合、ポリシー適用後に正当なメールの配信が失敗する可能性があります。

    解決策:一元化されたポリシー管理または自動化ツールにより、更新が即座かつ正確に適用されることが保証されます。

  • DNSレコードの更新とバージョン管理

    ポリシーが変更されるたびに、MTA-STS TXTレコードは新しいID値で更新されなければなりません。更新の欠落や誤りはポリシーの更新を遅延させ、不整合な適用を引き起こす可能性があります。

    解決策:自動化により人的ミスのリスクが低減され、DNSレコードがポリシー変更に常に整合した状態が維持されます。

  • 配送失敗に関する可視性の制限

    TLS-RPTが有効でない場合、暗号化関連の配信問題は検出されない可能性があります。TLS-RPTが有効であっても、専門知識がなければ生のJSONレポートの解釈は困難です。

    解決策:TLSレポートを解析・可視化するレポートプラットフォームは、障害の検出と迅速な対応を容易にします。

  • 運用上のオーバーヘッドと調整努力の増加

    手動デプロイにはDNS、メール、セキュリティチーム間の調整が必要であり、設定ミスや遅延のリスクが高まります。

    解決策:チームは、MTA-STSを長期的に維持するための時間と専門知識を有しているか、あるいは運用上の優先事項に管理型アプローチの方が適しているかを評価すべきである。

MTA-STS設定のテストと検証方法

MTA-STSポリシーを強制モードに移行する前に、テストは極めて重要なステップです。強制モードが有効化されると、送信サーバーは安全なTLS接続を確立できない場合、メール配信を拒否するよう指示されます。適切な検証なしでは、設定エラーが意図しないメッセージ損失を引き起こす可能性があるため、信頼性の高いメール配信を維持するには慎重なテストが不可欠です。

  • DNS伝播チェック

    MTA-STS TXTレコードおよび関連するDNSエントリを公開後、パブリックDNSリゾルバー全体で正しく解決されることを確認してください。伝播が不完全または遅延すると、送信サーバーが古いポリシーやキャッシュされたポリシーに依存する可能性があり、配信時に動作が不安定になる恐れがあります。

  • ポリシーファイルのアクセス可能性

    MTA-STSポリシーファイルが、mta-stsサブドメイン上の想定される場所でHTTPS経由でアクセス可能であることを確認してください。このファイルは、リダイレクト、認証要件、または証明書エラーなしに到達可能である必要があります。アクセスが中断されると、送信サーバーがポリシーを取得できなくなる可能性があります。

  • TLSサポートの検証

    ポリシーに記載されているすべてのMXホストがTLSをサポートし、ポリシー要件に合致する有効な証明書を提示していることを確認してください。TLSネゴシエーションが成功すれば、強制が有効化された後も暗号化された接続が一貫して確立されることが保証されます。

PowerDMARCのホスト型MTA-STSサービス

PowerDMARCは、これらすべてをバックグラウンドで処理することで、あなたの生活をより快適にします。一度設定してしまえば、あとは何も考える必要はありません。

  • 数回のクリックで、お客様のcnameレコードを公開することができます。

  • Webサーバーのメンテナンスや証明書のホスティングを担当する

  • ホスティングされたMTA-STSサービスを利用すれば、お客様は単にいくつかのDNSレコードを発行するだけで、展開が可能になります。

  • DNSを手動で変更しなくても、PowerDMARCのダッシュボードからMTA-STSのポリシーを即座に、かつ簡単に変更することができます。

  • PowerDMARCのホスト型MTA-STSサービスはRFCに準拠し、最新のTLS規格をサポートしています。

  • 証明書やMTA-STSポリシーファイルの生成からポリシーの実施まで、プロトコルの採用に伴う非常に複雑な作業を回避するためのサポートを行います。

SMTP TLS Reporting (TLS-RPT)

2台の通信するSMTPサーバー間の接続をTLS経由でより安全かつ暗号化するために、MTA-STSが導入されました。これにより暗号化が強制され、安全な接続が確立できない場合にメールが平文で配信されるのを防止します。 しかし、1つの問題が未解決のまま残っています。それは、TLS障害によってリモートサーバーでメール配信の問題が発生した場合、ドメイン所有者にどのように通知するかということです。ここでTLS-RPTが活躍します。TLS-RPTは、期限切れのTLS証明書、メールサーバーの設定ミス、TLSネゴシエーションの失敗など、サーバー通信の問題の監視とトラブルシューティングを支援する診断レポートを提供することで、MTA-STSを補完します。

TLSレポートは、JSONファイル形式のレポートメカニズムを介して、メール配信における問題の検出と対応を支援します。このJSONファイルは複雑で、技術者でない人には解読できないことがあります。

PowerDMARCは、JSONファイルを簡潔で包括的かつ読みやすい文書形式に簡素化し、チャートや表を用いて利便性を高めます。ドメインの診断レポートは、PowerDMARCダッシュボード上で結果別と送信元別の2形式で表示されます

 

パワーマークTLS RP

TLS-RPTの機能

TLS-RPTは、メールサーバー間のTLS暗号化に関連するメール配信失敗を報告するために設計されています。その主な目的は、ドメイン所有者がメッセージを安全に配信できない状況を可視化し、通常のSMTP通信では隠れたままになる問題を特定する手助けをすることです。

これらのレポートを通じて、TLS-RPTは送信サーバーと受信サーバー間のTLSネゴシエーションの失敗、期限切れまたは無効なTLS証明書、メール交換の両側における設定エラーなどの問題の特定を支援します。この洞察により、管理者は暗号化が破綻する箇所を特定し、是正措置を講じることが可能になります。

TLS-RPTレポートは、準拠したメール転送エージェントによって生成・送信され(通常は毎日)、セキュアなメール配信の健全性に関する継続的な可視性を提供します。

ジーソンチャート

有効にする方法

TLS-RPTは、ドメインの指定された_smtp._tls位置にDNS TXTレコードを公開することで有効化されます。このレコードはTLSレポートのサポートを示すとともに、診断レポートの送信先を指定します。

TXTレコードは、準拠した送信メールサーバーがTLS-RPTデータを送信するために使用する、1つ以上の報告アドレス(通常は電子メールまたはHTTPSエンドポイント)を定義します。レコードが設定されると、メールサーバーの動作を変更することなく、報告が自動的に開始されます。

TLS-RPTは、DNSに直接TXTレコードを追加するか、UIベースの設定を提供するプラットフォームを通じて手動で構成できます。管理されたインターフェースを使用すると、レコードの作成と検証を代行するため展開が簡素化され、構文エラーや設定ミスのリスクを低減できます。

MTA-STSによる電子メール転送のセキュリティ確保

電子メールは依然として重要な通信チャネルであるが、強制的な暗号化がなければ、メッセージ内容を暴露したり配信を妨害したりする可能性のあるダウングレード攻撃や中間者攻撃(MITM)に対して脆弱である。送信メールサーバーと受信メールサーバー間の機密性を維持し信頼を保つためには、転送中の電子メールを保護することが不可欠である。

MTA-STSは、TLS暗号化を必須とし、安全な接続が確立できない場合の配信を拒否することで、電子メールの転送を強化します。暗号化されていない通信へのフォールバックを排除することで、メッセージが認証済みかつ保護されたチャネルを通じてのみ配信されることを保証し、サーバー間通信における一貫性と信頼性を向上させます。

MTA-STSの導入を成功させるには、入念な準備が不可欠です。ポリシーは正確に設定し、サポートインフラは検証し、徹底的なテスト後に段階的に適用を開始すべきです。これらの手順を省略すると、特にポリシーを適用モードに移行するタイミングが早すぎた場合、意図しない配信失敗を引き起こす可能性があります。

強制適用を有効化する前に、組織は現在のメールセキュリティ態勢を検証し、全メールサーバーにおけるTLS対応状況を確認し、DNSおよびポリシーファイルが正しく公開されていることを確認すべきである。サーバー構成の変更や証明書の失効に伴い、継続的な監視と定期的な検証は長期的に重要であり、MTA-STSポリシーがメール配信を効果的に保護し続けることを保証するのに役立つ。

よくあるご質問

PowerDMARCのコントロールパネルでは、ドメインのDNSに3つのCNAMEレコードを発行するだけで、ドメインにMTA-STSとTLS-RPTを自動的に設定することができます。MTAS-STSのポリシーファイルや証明書のホスティングからWebサーバーのメンテナンスまで、お客様がDNSに変更を加えることなく、バックグラウンドですべての処理を行います。PowerDMARCを使用したMTA-STSの導入は、わずか数クリックで完了します。

PowerDMARCアカウントからすべてのドメインにMTA-STSを導入し、管理することができます。STARTTLSをサポートしていない受信メールサーバーを使用しているドメインがある場合、それらのドメインに対してTLS-RPTを有効にしていれば、TLSレポートに反映されます。

MTA-STSのポリシーモードをテストモードに設定することをお勧めします。 テストに設定することをお勧めします。これにより、「強制」のような積極的なポリシーに移行する前に、活動を監視し、メールエコシステムの可視性を得ることができます。これにより、TLS暗号化された接続でメールが送信されなくても、平文で送信されることになります。 ただし、その際にはTLS-RPTを有効にして、通知を受けるようにしてください。

TLS-RPTは、安全な接続が確立されず、電子メールの配信に失敗した場合に通知を受けることができる広範なレポートメカニズムです。これにより、メール配信やセキュリティ保護されていない接続で配信されたメールの問題を検出し、迅速に問題を軽減・解決することができます。

MTA-STSは、TLS暗号化された接続で電子メールを転送しますが、安全な接続がネゴシエートされていない場合は、電子メールの配信に失敗する可能性があることに注意してください。しかし、これは、電子メールが暗号化されていない経路で配信されないようにするために必要なことです。このような問題を回避するには、MTA-STSポリシーをテストモードで設定し、MTA-STS強制モードに移行する前に、まずドメインのTLS-RPTを有効にすることをお勧めします。 

MTA-STSモードの変更は、PowerMTA-STSダッシュボードから希望のポリシーモードを選択し、DNSに変更を加えることなく変更を保存することで簡単に行うことができます。

ドメインのMTA-STSを無効化するには、ポリシーモードをnoneに設定してMTAに対してプロトコルをサポートしていないことを明示するか、MTA-STSのDNS TXTレコードを削除します。 

MTA-STSポリシーファイルのMXレコードには、ドメインが利用するすべての受信メールサーバーのエントリを含める必要があります。