SMTP TLS Reportingとは何ですか？

SMTP-TLSレポートとは何か？

TLS Reportingは、ドメイン所有者がピンポイントでメール配信の問題を発見できるようにする逆フィードバックメカニズムです。これは MTA-STSプロトコルと連動し、TLSハンドシェイクの失敗により配信に失敗したバウンスメールの追跡データを提供します。

TLSレポートとは何か？

TLS Reporting (TLS-RPT) は、メールがTLSで暗号化されていないときに発生するメール配信の問題を報告するための規格です。MTA-STSプロトコルをサポートしており、お客様のドメインに送信されるメールがTLSで暗号化されていることを保証するために使用されます。

  • TLS暗号化により、お客様に送信されるメールはすべて安全に配信されます。しかし、攻撃者はSMTPダウングレードを試みるかもしれません。これは、電子メールが暗号化されずに送信され、内容を読んだり改ざんしたりできるようにする攻撃の一種です。MTA-STSは、すべての電子メールを暗号化してから送信する必要があるようにすることで、これに対抗します。攻撃者がSMTPダウングレードを実行しようとすると、メールはまったく送信されません。
  • TLS-RPTは、暗号化されずに送信に失敗したすべてのメールについて、ドメイン所有者であるあなたがレポートを受け取ることを可能にします。そして、問題の原因を特定し、配信の問題を解決することができます。

TLSレポートの仕組み

TLS報告の仕組み

TLSレポート（TLS-RPT）は、MTA-STSプロトコルをサポートするために使用され、電子メールが暗号化されてから配信されるようにします。通常、メールサーバーまたはMail Transfer Agent（MTA）は、受信サーバーがSTARTTLSコマンドをサポートしているかどうかを確認するために、受信サーバーと交渉します。STARTTLSコマンドがサポートされていれば、メールはTLSで暗号化され、受信側のMTAに配信されます。

攻撃者はこの時点で、送信側と受信側のMTA間のネゴシエーションをブロックするSMTPダウングレード攻撃を試みる可能性があります。送信サーバーは、受信者がSTARTTLSコマンドをサポートしていないと考え、TLS暗号化を行わずにメールを送信するため、攻撃者はメールの内容を閲覧したり改ざんしたりすることができます。

ドメインにMTA-STSを実装すると、送信サーバーは送信前にメッセージを暗号化することが必須になります。攻撃者がSMTPダウングレード攻撃を試みた場合、メールは単に送信されません。これにより、すべての電子メールでTLS暗号化が確実に行われます。

TLSレポート(TLS-RPT)は、ドメインを通じて送信されたメールが配信に問題が発生した場合に、ドメイン所有者に通知するプロトコルです。SMTPのダウングレードやその他の問題によりメールの送信に失敗した場合、失敗したメールの詳細を含むJSONファイル形式のレポートを受け取ります。このレポートにはメールの内容は含まれません。

なぜSMTP TLSレポートが必要なのか？

ドメイン所有者にとって、MTA-STS対応ドメインから送信されたメールのTLS暗号化の失敗によるメール配信の問題について常に情報を得ることは不可欠です。TLSレポートは、この情報を提供することでそれを可能にします。 

フィードバック・レポートを受け取る

メッセージの送信に失敗した場合、TLSレポートがそのことを通知します。

メールチャネルの全体像を把握する

TLSレポートにより、メールフローに関する詳細な情報を得ることができます。

配送の問題を解消するために

TLSレポートにより、問題の原因を特定し、遅延なく修正することができます。TLSレポート

TLSレポートを有効にする手順 

TLS-RPTのTXTレコードを作成し、DNSで公開することで、ドメインのTLSレポートを有効にできます。このレコードは、サブドメイン _smtp._tls.yourdomain.comで公開する必要があります。

TLS-RPTレコードの例

v=TLSRPTv1; rua=mailto:[email protected]；

提供されたTLS報告記録の構成要素を分解してみよう：

v=TLSRPTv1：

このタグは、使用されているTLS-RPTプロトコルのバージョンを指定する。この場合 「TLSRPTv1" はTLS-RPTプロトコルの最初のバージョンを示す。

rua=mailto:[email protected]：

ruaは「Reporting URI for Aggregated Reports」の略である。ruaは "Reporting URI for Aggregated Reports "の略である。

値"mailto:[email protected]"はメールアドレスを指定するURIです。 ([email protected])を指定するURIである。

実際には"yourdomain.com" を、これらのレポートを受け取りたい実際のドメイン名に置き換えます。

各コンポーネントの重要性：

v=TLSRPTv1：

これは、使用されているTLS-RPTプロトコルのバージョンを示す。これは、レポートの送信者と受信者間の互換性を確保するのに役立つ。

rua=mailto:[email protected]：

これは、TLS配信問題の集計レポートの宛先を指定します。報告用メールアドレスを指定することで、ドメイン所有者は失敗したTLS接続や問題のあるTLS接続に関する情報を受け取ることができます。このレポートは、電子メール通信に関連する潜在的なセキュリティや設定の問題を診断するのに役立ちます。

TLS報告書フォーマットと報告書例

JSON TLSレポートは、TLS-RPT（Transport Layer Security Reporting Policy）仕様で定義されている特定のフォーマットに従います。このフォーマットは、TLS暗号化に関連するメール配信の問題に関する情報を伝えるために使用されます。以下は、JSON TLSレポートの例です：

このJSON TLSレポートの主なフィールドの内訳は以下の通りです：

TLS報告フォーマットと報告例

組織:TLS-RPT レコードを所有するドメイン組織。

電子メール:集計レポートを送信するメールアドレス。

開始日:報告期間の開始日。

終了日:報告期間の終了日。

政策:報告期間中に適用されたポリシーを記述するポリシーオブジェクトの配列。

政策:適用されたポリシーに関する情報が含まれています。

ポリシータイプ:ポリシーの種類を指定する（例えば、TLSポリシーの場合は "policy"）。

ポリシーの文字列:ポリシーに関連するポリシーの文字列を指定する（例：厳格なTLSポリシーの場合は "reject"）。

概要:試行されたセッションの概要情報を含む。

総セッション数:成功したTLSセッションの総カウント。

総失敗セッション数:TLSセッションの失敗の総カウント。

失敗の詳細:特定の失敗についての詳細を提供するオブジェクトの配列。

理由:失敗の理由を示す文字列（例："certificate_expired"）。

カウント:特定の理由で失敗したセッションの数。

TLS暗号化の失敗の理由と種類 

証明書の問題

  1. 証明書_期限切れ:リモート・サーバーから提示された証明書は有効期限を過ぎており、暗号化には信頼できない。
  2. まだ有効でない証明書:リモート・サーバーから提示された証明書はまだ有効ではありません。サーバーの時刻が正しくないか、証明書の使用時期が早まっている可能性があります。
  3. 証明書失効:リモート・サーバーが提示した証明書は、セキュリティ上の懸念から認証局によって取り消された。
  4. 信頼できない証明書:リモート・サーバーが提示した証明書チェーンは、送信者のメール・サーバーまたはクライアントによって信頼されておらず、潜在的なセキュリティ・リスクを示している。
  5. 無効署名:リモートサーバーから提示された証明書は信頼できる認証局によって適切に署名されておらず、その信頼性に懸念が生じます。
  6. 未対応証明書:リモート・サーバーが提示した証明書は、送信者のメール・サーバーがサポートしていない暗号化アルゴリズムまたは鍵長を使用しており、安全な接続を妨げている。

ホスト名とIDの不一致

  1. ホスト名ミスマッチ:サーバーの証明書で指定されたホスト名が、送信者のメール・サーバーが接続しようとしているサーバーのホスト名と一致しません。これは、中間者攻撃または設定の問題の可能性を示しています。

暗号スイートと暗号化設定

  1. インセキュア暗号スイート:送信者と受信者のメールサーバー間でネゴシエートされた暗号スイートが弱いか安全でないと考えられ、通信の機密性と完全性が損なわれる可能性がある。
  2. プロトコル_バージョン不一致:送信側と受信側のメール・サーバー間でサポートされているTLSプロトコルのバージョンに不一致があり、互換性のある暗号化接続を確立できない。
  3. 非共有暗号スイート:送信側と受信側のメール・サーバーが暗号化に使用できる共通の暗号スイートがないため、接続に失敗します。

ハンドシェークとプロトコルの問題

  1. 握手失敗:送信者のメール・サーバーと受信者のメール・サーバー間の最初のTLSハンドシェイク処理中に問題が発生し、セキュア・チャネルが確立されなかった。
  2. 予期せぬメッセージ:送信者のメールサーバーがTLSハンドシェイクの過程で予期しない、あるいはサポートされていないメッセージを受信した。

MTA-STSの政策課題

  1. MTA_STS_POLICY_NOT_FOUND:この失敗は、送信者のメールサーバーが受信者のドメインのMTA-STSポリシーを見つけられないときに発生します。
  2. MTA_STS_POLICY_INVALID:この失敗は、受信者のドメインのDNSで見つかったMTA-STSポリシーが無効であるか、エラーを含んでいるか、MTA-STS仕様に準拠していない場合に発生する。
  3. MTA_STS_POLICY_FETCH_ERROR:この失敗は、送信者のメールサーバーが受信者のドメインのDNSレコードからMTA-STSポリシーを取得しようとしてエラーが発生したときに発生します。
  4. MTA_STS_CONNECTION_FILURE:この失敗は、送信者のメールサーバーがMTA-STSを使用して安全な接続を確立しようとしたが、信頼できない証明書、サポートされていない暗号スイート、またはその他のTLSの問題などの理由で失敗したときに発生する。
  5. MTA_STS_INVALID_ホスト名:この失敗は、MTA-STSポリシーで指定された受信者のメールサーバーのホスト名が、実際のサーバーのホスト名と一致しない場合に発生する。
  6. mta_sts_policy_upgrade:この失敗は、送信者のメール・サーバーがMTA-STSを使用して接続をセキュアなものにアップグレードしようとしたが、受信者のサーバーがアップグレードに対応していない場合に発生する。

PowerDMARCによるSMTP TLSレポートの簡素化

PowerDMARCを使用した簡易SMTP-TLSレポーティング

PowerDMARCのSMTP TLSレポート体験は、ホストされたサービスであなたの生活を容易にしながら、セキュリティを向上させることにある。

翻訳されたTLSレポート

TLSレポート用の複雑なJSONレポートは、数秒でざっと目を通したり、詳しく読んだりできるシンプルな情報に変換されます。

オートディテクト問題

PowerDMARCプラットフォームは、直面している問題を自動的に特定し、時間を無駄にすることなく解決することができます。

TLSレポート

最新記事 by Ahona Rudra(全て見る)
/によって
ベンダーによる電子メールの不正使用が怖い理由（そしてそれを阻止するためにできることベックブログspf制限ブログなぜSPFだけではなりすましを防げないのか？