SMTPにおける暗号化について

Question

只今、postfixを用いて受信メールサーバを構築しようとしている者です。
メールの暗号化について、教えてください。

ネットで調べてみたところ、SMTPには、暗号・認証なしの25ポートを用いて行うもの、STARTTLSによる暗号化・認証ありの587ポートを用いて行うもの、SSL通信による暗号化・認証ありの465ポートを用いて行うものの３つがある事がわかりました。

しかしこれらは、あくまで、メーラ(MUA)⇄MTA間で使用される者であり、MTAどうしのやりとりには基本使用されていない（SMTPを使用して平文で送られている）と理解しました。

ここで質問ですが、
①MTA同士のやりとりは基本的に暗号化されていないとは、正しい認識でしょうか。

②今、仕事で受信専用のメールサーバを立てる必要があります。①が正しいとすると、LISTENするポートは、25（SMTP平文を想定）のみとするのがセキュリティ的に正しいでしょうか。

何か勘違いしている箇所があれば、ご指摘ください。また②について、"これこれの条件によって変わる"などあれば教えてください。

Answer 1

STARTTLS は接続先のSMTPサーバが対応していれば暗号化通信、対応していなければ平文通信を行うような仕様です。

そのため、送信側・受信側双方のSMTPサーバでSTARTTLSに対応していれば、暗号化通信によるメール転送が可能です。

参考） https://blog.nhiroki.net/2014/01/18/postfix-tls-setting

よく知られている例でいえば、Gmail などでSTARTTLSによる受信に対応し始めており、送信元のSMTPサーバがSTARTTLSに対応しておらず平文で送られてきた場合はそのメールに警告を表示するといったことを始めています。
参考） https://japan.cnet.com/article/35073528/

したがって、

①MTA同士のやりとりは基本的に暗号化されていないとは、正しい認識でしょうか。

いいえ、必ずしもそうではありません。

②今、仕事で受信専用のメールサーバを立てる必要があります。①が正しいとすると、LISTENするポートは、25（SMTP平文を想定）のみとするのがセキュリティ的に正しいでしょうか。

①が誤りですが、 25番ポートをSTARTTLS対応で待ち受けることにより、送信元の対応状況に応じて平文・暗号化通信いずれかが選択されます。

ただし、そもそもSTARTTLSははじめに平文通信を利用してSTARTTLS対応の確認を行いますので、その時点での安全性は担保されていません。

2017.06.01. 23:20 頃の追記

①MTA同士の暗号化においては、SMTP over SSLは使用されず、使用されるのであれば、SMTP STARTTLSが使用されるという認識で合っていますでしょうか。

これは「送信サーバ側の設定（ポリシー）による」というのが回答になります。

ただ現実的に送信側のサーバは特定のサーバあてのみ送信するわけでなく様々なサーバあてに送信することになるはずなので、相手先が SMTP over SSL である前提の送信方法よりも、相手に合わせる方法であるSTARTSSLの方が都合がいいことは多いでしょう。

②頂いた１つ目のリンク先を参照すると、SSLの証明書については、Submission用にはオレオレ証明書もありだが、受信MTAとしてはきちんと購入しましょうとあります。これは何か理由があるのでしょうか？

ここを理解するためにはSSL証明書がどのように有効性が確認されるのかを理解している必要がありますが、ご存知でしょうか。

SSL証明書の有効性確認の仕組みについて

少し端折りますが。
一般的にSSL（TLS）証明書は、信頼されている認証局（CA）により署名された証明書であることが確認されます。
信頼されている認証局は、あらかじめ各サーバで設定されています。
例えば Symantec（旧VeriSign）で購入したSSL証明書が設定されているWebサイトをブラウザで閲覧した際、鍵マークが表示されるのは

　　- 「その証明書が有効である」とブラウザが判断したから

であり、判断理由は

- ブラウザが信頼している認証局による署名がある証明書だから

です。
同様にオレオレ証明書（自己署名証明書）が設定されているWebサイトを表示した際は、特に設定をいじっていない限り安全ではないサイトとされますが、これは

　- ブラウザが信頼している認証局による署名がない証明書だから

です。
これを「安全」と判断させるためには、その証明書を署名した証明書を「信頼する認証局」として登録することが必要になります。

その上で、ご質問について

追記の 1. の回答とも関係しますが、受信側のサーバも様々なサーバからメール送信が行われることになります。

この時、送信側のサーバがクライアント、受信側のサーバがサーバとして、サーバ認証をSSL証明書を利用して行います。
受信側のサーバがオレオレ証明書を利用している場合、送信側のサーバは信頼できる証明書ではないと判断し送信を中止します。
これを回避するためには送信される可能性があるすべてのSMTPサーバにそのオレオレ証明書を信頼してもらう必要がありますが、これは非現実的です。

Submissionポート用はオレオレ証明書でも構わない、というのは、Submissionポートが利用されるのはメーラから送信用SMTPに利用するためであり、限られた接続元でのみ信頼できればいいものとなります。
メーラには「証明書の有効性チェックを無視する」設定があることも多いですので、その送信用SMTPサーバを利用する人の間で使い方のコンセンサスがとれていれば大きな問題にならないことも多いでしょう。

そういった背景でそのような説明がされているものと思います。
※今となっては Let's Encrypt もありますので、公開されているサーバでオレオレ証明書を利用する必要はほとんどないかと思いますが。。

Comments

[hirhir]

回答ありがとうございます。非常に参考になりました。２点追加で質問させてください。
①MTA同士の暗号化においては、SMTP over SSLは使用されず、使用されるのであれば、SMTP STARTTLSが使用されるという認識で合っていますでしょうか。
②頂いた１つ目のリンク先を参照すると、SSLの証明書については、Submission用にはオレオレ証明書もありだが、受信MTAとしてはきちんと購入しましょうとあります。これは何か理由があるのでしょうか？

[kaz.Suenaga]

ちょっと長くなりますので回答に追記しますね。

[hirhir]

丁寧な回答を頂きありがとうございます。
済みませんが、追加で質問させていただいても良いでしょうか。私が管理しているサーバではWEBサーバが先に構築されていて、そちらは、証明書をすでに購入しています。そして、調べて見たところ、MTAの証明書とWEB証明書は同じものを使用して良いという記事を見つけました。そこで質問ですが、WEBサーバ（IBM http server）でCSRを作成した時、common nameにFQDNを指定したのですが、これは、同じサーバに存在するMTAにも適用できるのでしょうか。httpアクセスする時は、FQDNでアクセスしますが、メールの場合、@以降は、ドメイン名（ホスト名がない）なので適用できるか微妙かと思いまして。。。

[kaz.Suenaga]

本来は別の質問として立てていただいたほうがいいような別の質問になっている気もしますが、とりあえず。

技術的にはその証明書を検証する側の実装による、というのが回答ですが、現実的には使えることが多いと思います。
厳密には証明書の使用用途の定義などもありますので証明書による部分もあるかと思います。
http://security.data-site.info/585.html

SSL証明書を発行している認証局によっては同一のFQDNでも利用する目的が異なる場合は複数ライセンス必要など、利用に問題がないかはその証明書の発行元の規定を確認する必要があります。

> httpアクセスする時は、FQDNでアクセスしますが、メールの場合、@以降は、ドメイン名（ホスト名がない）なので適用できるか微妙かと思いまして。。。

これはメール送信の仕組みを理解されていないことを意味する質問ですが、SMTPサーバ間の通信時、送信側サーバから受信側サーバへ接続する際はFQDNに対して通信を行います。
具体的に
・ メールアドレスの @ 以降のドメイン名のMXレコードを引く
・ そのMXレコードで指定されているホスト名のAレコードを引く
と名前解決することによって通信は行われ、その際に利用されるFQDNはMXレコードで指し示された名前となります。

一度 telnetコマンドを利用して、SMTP通信がどう行われているか手作業で辿ってみると理解は進むと思いますよ。
https://wp.kaz.bz/tech/2012/07/20/1212.html

Answer 2

①MTA同士のやりとりは基本的に暗号化されていないとは、正しい認識でしょうか。

いえ、SMTPは「シンプルメール転送プロトコル」という通り、メールサーバ同士のやり取りにも使われます。その過程でSTARTTLSを使うことも、SSL＋SMTPで待ち受けることも可能です。

ただし、「暗号化された経路だけ通る」ことをSMTPレベルで保証することはできませんし、途中で中継するサーバがある以上、中間者攻撃も防げません。

② LISTENするポートは、25（SMTP平文を想定）のみとするのがセキュリティ的に正しいでしょうか。

25番と587番の違いは「STARTTLSを使うか」ではなく、「ユーザーがメールを発信する」のに使うのが587番、メールサーバ同士の転送に使うのが25番、という使い分けです。25番でSTARTTLSありで待ち受けても構いません（もちろん、STARTTLSなしで送ってくる相手がいるかもしれません）。

Comments

[hogetaro]

最近のISPではスパム送信対策としてOP25Bが実施されていることが多いので、ISPの回線では25番でMUAがメール送信が可能だが、ISP以外の回線では25番でメール送信ができません。(通信方向が逆のIP25Bというのもあります。)
そのため、25番はメールサーバ用にし、submission 587番をMUA用という使い方になっています。

一般的に submission は外部回線からISPのメール送信をISPのメールサーバから正規の送信にする用途に用いられますが、その際、ユーザ認証と暗号化は必須するのが常識で、平文禁止のSTARTTLSになっていることが多いです。

また、SMTP over SSL 465番についても位置づけは submission と同じですが、最初から SSL/TSL で決め打ちになっている点、SMTPの平文やSTARTTLSとプロトコル的に互換がありません。クライアントの対応状況によって暗号化を開始できる STARTTLS に比べて、クライアントの事前設定が必要な点において、古いプロトコルです。

一般的なメールサーバの待ち受けポートについてまとめます。
25番・・・SMTP 平文＋STARTTLS ※MTA用、ISP回線の古いMUA用
587番・・・SMTP 平文禁止 + STARTTLS ＋ SMTP-AUTH ※MUA用
465番・・・SMTP over SSL/TLS + SMTP-AUTH ※古いMUA用