PR

インフラエンジニアがガチでメール関連技術に挑んでみた:破 (MTA-STS / TLS-RPT)

carrier pigeon セキュリティ
この記事は約6分で読めます。

※ この記事は 2024/03/19 に投稿され、 2024/03/20 に内容が更新されています

SPF / DKIM / DMARC 以外のお話

前回は Gmail の送信者ガイドライン だけで終わってしまったので、本来書きたかった記事となります。

メールはビジネスや個人間のコミュニケーションにおいて現在でも不可欠なツールですが、そのセキュリティ上の脆弱性は頻繁に悪用されてします。
メール送信で利用されている SMTP は規格が古く、 その脆弱な部分を DNS サーバでカバーして安全性を担保している状況です。

最近は SPF / DKIM / DMARC だけが注目されていますが、その他にも新しい規格と技術が出ています。

本記事では、 TLS-RPT / MTA-STS という比較的新しい規格に焦点を当てます。

MTA-STS (Mail Transfer Agent Strict Transport Security) とは

規格

MTA-STS は、RFC 8461 で定義されているメール送信時のセキュリティを強化するためのプロトコルです。
これは、メール送信時に HTTPS でお馴染の TLSTransport Layer Securityを強制する仕組みを提供します。

MTA-STS を利用することで、メールサーバが TLS をサポートしていない場合、メール送信を拒否することができます。

これにより、攻撃者がメールを傍受したり改ざんしたりするリスクを軽減することができます。

メールの送受信時によく利用されている暗号化は「日和見 TLS 」と呼ばれるものであり、送信先のメールサーバが TLS つまり暗号化に非対応だった場合は、あきらめて平文でメールを送信します。

暗号化を強制できるのが MTS-STS となります。

設定方法

  1. 送信メールアドレスのドメインパートを利用する DNS サーバに、専用の TXT レコードを登録する
  2. 公開 Web サーバから専用のファイルを読込めるようにし、ポリシーを設定する

DMARC などと違って、ポシリーを公開するには DNS サーバWeb サーバが必要なところは若干敷居が高いですね。

MTA-STS レコードの書式は以下となります。

_mta-sts.[ドメイン名]  IN  TXT  v=STSv1; id=[値]
パラメータ内容
vバージョン番号。現在は STSv1 で固定
id11 桁の数値

DNS については、 DMARC などと同じく mta-sts ではじまること。
v= も DMARC などと同じくバージョンで、 v1 しかないので v=STSv1 で固定値になります。
id については、 DNS の割にはシリアル値というわけではなく、値が変更されれば増分でなくても変更を認識してくれるようです。

exsample.com がドメインパートだった場合の例は、以下となります。

_mta-sts.exsample.com  IN  TXT  v=STSv1; id=20240316001

Web サーバ側の設定は以下となります。

https://mta-sts.[ドメイン名]/.well-known/mta-sts.txt

Web については、 HTTPS が必須です。
まあ、暗号化してメール送信しておくれと要求してるんだから、ポリシーも暗号化されている場所にあるべきってことですかね。
サブドメインやファイルパスも固定で変更ができないので注意が必要です。

mta-sta.txt に記載する例は以下のとおりです。

version: STSv1
mode: enforce
max_age: 86400
mx: *.google.com
mx: *.googlemail.com
mx: *.apsmx.*.googlemail.com

特に難しいことはないのですが、メール関連の設定よろしく、改行コードが CR+LF なテキストファイルを用意する必要がある点は注意してください。

あとは特に難しいことはなくて、バージョンは前述のとおり、 mx はまんまなのでポリシーくらいでしょうか。

  • enforce
    • STARTTLS が利用できない場合、メールを送信しないようにしてもらうポシリー
  • testing
    • STARTTLS が利用できなくても、日和見 TLS でメールは通常通り送信し、レポートを送信するようにしてもらうポリシー
  • none
    • MTA-STS を利用していないようにオプトアウト (利用しないように) してもらうポリシー

TLS-RPT (Transport Layer Security Reporting) とは

規格

TLS-RPT は、RFC 8460 で定義され TLS の使用状況を報告するための規格です。

これは、メールサーバがどの程度 TLS をサポートしているかを報告し、送信者がセキュリティポリシーを遵守しているかどうかを監視するために役立ちます。

これにより、攻撃者が中間者攻撃などの手法を用いてメールの内容を盗聴するリスクを軽減することができます。

複数の MTA 間を中継されることは少なくなりましたが、途中経路でどれくらい TLS を利用したか / 利用 (しようとして) できなかったかをレポートしてくれる。

DMARC の R は Report で、メールサーバのログを見るのではなく、レポートになっているとわかりやすいですね。現状を把握するというのも大事なこと

MTA-STS を組合せて利用するものかなと思ってます。

設定方法

こちらは DNS レコードのみで設定できます。書式は以下のとおりです。

_smtp._tls.[ドメイン]  IN v=TLSRPTv1; rua=mailto:[メールアドレス]
パラメータ内容
vバージョン番号。現在は TLSRPTv1 で固定
ruaレポート送信先のメールアドレスを指定

exsample.com がドメインパート、レポート送信先が [email protected] だった場合の例です。

_smtp._tls.exsample.com  IN  v=TLSRPTv1;  rua=mailto:[email protected]

_smtp._tls が固定値なこと以外は特に難しいことはないですね。
v=TLSRPTv1 も他にバージョンがないので固定値。

DMARC と同じように rua= でレポートの送信先を指定しているだけです。
HTTPS で送るという方法もあるようですが、よくわかっていません。

Web サーバに対して POST で投げて専用サービスで分析?というようなことを想定しているのでしょうか?
試したことはないし、そういうサービスも見たことがないので詳細不明です。

また、つづき

長くなってしまったので、続きは [ : 急 ] で!
次回は BIMIBrand Indicators for Message Identification について書こうと思います。

コメント