この投稿はSFC-RG Advent Calendar 2016の10日目です。
はじめに
研究ネタに困り日本にインターネットを引いたIP原理主義者がゴロゴロいる研究室でCCNの研究をしようか某B3の学生は血迷っていた。そこで神のように舞い降りた新婚ホヤホヤの指導教官から「SMTP-STSっていうのあるよ！」の一声でメールサーバ間通信の研究をすることを決意した。ちなみにこのSMTP-STS、日本語文献がほとんどないのである！
Googleの日本語検索結果のうち上位3/4が私と指導教官である。
前書きがとても長くなったが、本稿はSMTP-STSを研究するにあたり一夜漬けで覚えた学習したメールプロトコル関連のセキュリティ技術についてのクイックリファレンス、もとい覚え書になる。
STARTTLS拡張とSMTP over TLS
SMTP over TLS
メールソフト、メールサーバ間の通信をSSL/TLSを利用して暗号化するセキュリティ機構。465番ポートを使用し、通信の全行程が暗号化される。クライアントと送信先サーバがover TLSに対応していても、先の中継サーバが対応していないと暗号化通信できないため普及が進んでいなかった。
しかしGoogle様がGmailを常時SSL化をサポートしたのでGmail内通信だと常に暗号化されている。Google様はしゅごい。
STARTTLS拡張
通信はじめに相手サーバがTLS/SSLに対応しているかネゴシエーションしてから通信経路を暗号化するセキュリティ機構。ポートは587。途中から平文通信を暗号化通信に切り替えるのがSMTP over TLSとの違い。
問題
だがどちらにしろ現状だと自分からネクストホップのサーバまでのTLS経路しか確認できず、図のような感じになっている。(だからSMTP-STSが必要なんです)
Google様は常時SSL化してるから例外です。
SMTP-STS
それを解決するのがSMTPS-STS(SMTP Strict Trasport Security)！
なうでIETF UTA Working Groupで審議されているとってもナウい技術なのだ！
先述の技術は全て日和見暗号なので能動的攻撃には弱い。特に中間者攻撃には脆弱である。自分とメールサーバ間が暗号化されていたとしてもこんな感じに攻撃されてしまう。
それを防ぐセキュリティ機構がSMTS-STSである。主な機能は２つに集約される。
- メールを送る際にTLS上でメールが送信できることを確認/宣言する
- セキュアにメールが送信できない場合はリポートを返す
この２つの機能でSTARTTLS等で壁になっていたMTA間の通信の秘匿性をカバーする。
そもそもDNSポイズニングがあるだろうとかいう指摘もあるが、それはSMTP-STSのカバーする範囲ではなく、DANEでサーバの応答性は担保する。
これで安心してメールが遅れるね、たえちゃん！
メール自体の暗号化
hogehoge(今週にはかく。。。。)
参考
上野宣. (2005)『今夜わかるメールプロトコル』 翔泳社.
とってもいい本なのに絶版になっている。翔泳社さん、再販してくれ〜
digicert. TLS/SSLで電子メールの安全性を高める
Symantech. POP over SSL/SMTP over SSL
IBM. STARTTLS 拡張を使用して SMTP セッションを保護する
Wikipedia. STARTTLS (論文じゃないからwikipediaでも許してちょ〜)