SSL/TLS暗号化とメールサーバー
メールサーバーの接続を暗号化するSSL/TLSについて知っておくべきこと
このブログ記事のテーマを持ちかけられたとき、私は快く承諾したのです。
「メール サーバーにおける TLS の重要性について記事を書いてもらえないか」と Patrick に聞かれました。
ふぅ、それはそれはクレイジーな
会話でしたね！
私は「もちろん」と答えました。
それから、ちょっと考え始めたんです。 トランジットに暗号化を使用していないメールサーバーが本当にあるのだろうか？ 過去に取り上げたようなエンドツーエンドの暗号化 (S/MIME、PGP など) のことではありません。 サーバーからサーバー、あるいはその間にあるすべてのデータを保護するための暗号化について言っているのです。
確かに、今の時代、受信/送信メールを平文にして、傍受され利用される可能性のある経路を通過させる人はいないでしょう。 多くの人が電子メール・サービスを利用しており、そのサービスからトランジット暗号化を除外することはあり得ません。 データ漏洩は、訴訟やビジネスの損失、恥ずかしさで何百万ドルもの損失をもたらします。 私の推測では、それは
低いのではないでしょうか。 つまり、この記事について私に尋ねるきっかけは何だったのでしょうか。”
Patrick は、「I
actually don’t do」と答えました。 電子メールの重要性
とセキュリティに必要なすべての側面を考えると、良いトピックだと思いました」
OK. それは理にかなっていますね。 おそらく、これをまったく使用していないメール サーバーもありますが、間違いなく、より多くの割合で、古いプロトコルや期限切れの証明書を使用しており、リフレッシュが必要なだけかもしれません。
この記事では、電子メールとトランジットの暗号化について、
利用可能な最適の安全レベルで動作していることを確認するために、
概観します。
メール サーバーの暗号化
この時点で、おそらく TLS の仕組みは大体理解していると思いますが、初めての方のためにまとめておきましょう。
人 A は人 B に
安全な通信を送信したいとします。 Aさんは証明書を使って情報を暗号化し、暗号化された情報をBさんに送ります。Bさんが証明書を使って暗号化された情報を復号化するまで、情報は読めません。
人間Bが暗号化された情報で
人間Aに返信したい場合、人間Bは
証明書を使用してデータを暗号化し、人間Aは
証明書を使用してメッセージを復号化します。
これが一般的な
暗号化/復号化の仕組みです。 ここで、この例で挙げた人たちを
サーバーやその他のそのような接続に置き換えてみてください。
ここで、人間 B が暗号化された情報で人間 A に応答したい場合、人間 B は先ほど生成された対称鍵を使用し、お互いにデータを暗号化して送信、受信して復号化することができます。
これが、SSL/TLSによる暗号化・復号化の一般的な仕組みです。 今度はこの例で挙げられた人々をサーバや他のそのような接続に置き換えてみてください。 同じ考え方です。 これはTLSが電子メールでどのように機能するかということで、電子メールが異なるプロトコルを使用しているという事実のために、HTTPS接続を促進する方法とは少し異なっています。
- ハンドシェイクが行われる
- 認証が行われる（この文脈では両者が認証する）
- セッション鍵は電子メールのフローを伝送するために使用される
上下（メール）フロー
この
「なぜかを理解」記事の次のステップは、「どうやって理解」するかという部分です。
要するに、メールクライアントは送信サーバーにメールを送ります。 送信サーバーは、宛先の電子メール ドメインに基づいて DNS を検索し、その DNS の MX レコードが電子メールを送信するサーバーを決定し、場合によっては、そのサーバーが、宛先受信箱のメール配信エージェント (MDA) に到達するまで転送する必要があるかどうかを決定します。
DNS MX レコードを信頼するだけでは十分ではなく、これはまったく別の信頼の問題ですが、SMTP
（送信メール、MTA など）サーバーと受信メール（POP3、IMAP、
Exchange を通じて）は、お互いを識別でき、
互いに通信する正しいキーを持っている必要があります。 また、経路によっては、メール サーバーの通信が 1 ホップだけでなく
複数存在することもあります。 メール交換機、プロキシ
サーバー、その他がルートに沿って配置されるかもしれません。 各ホップは
暗号化されたリンクを要求する（はず）です。 多くの場合、そうなっています。 時には、そうでないこともあります。 ユーザーは、機密情報が途中で暗号化されることを
好むでしょう。 エンドツーエンドの暗号化
は、全体を通してある種の暗号化があることを保証するのに役立ちますが、
セキュリティの層は常に、えー、より良いものであるべきです。
Respect Thy Securi-Tie
Securi-Tie は実際の単語ではありません。 韻を踏んでいるからその言葉を作っただけです。 セキュリティーという言葉をもじった
ものです。
前節の続きとして、クライアント側で設定するセキュリティ・オプションについて説明します。
メール クライアント (Outlook、Thunderbird など) を設定する場合、デフォルトでは暗号化されていない
構成になっています。 しかし、この記事のポイントでもあるように、通常は
暗号化オプションを選択したいものです。 ある意味で、これは完全にクライアント次第というわけではなく、サーバー側が何をサポートできるかに
依存するのです。 インバウンド
とアウトバウンドのサーバーが暗号化をサポートできると仮定すると、なぜそうしないのでしょうか？ レストランで
ステーキを注文したとき、同じ値段でサーロインと神戸牛のリブロース
が選べるとしたら、なぜより質の良いカットを注文しないのでしょう？
ですから、もし電子メールで
TLS/SSLを使いたいなら（これはトランジット部分であり、他のブログ記事で説明されているエンドツーエンド、
S/MIME部分ではない）、それをオンにしてください。 SMTP（メンバー、送信メール）にはポート465
または587を、
受信トラフィックには993（IMAP）または995（POP3）を使用します。
電子メールサーバーの間でまだ使用されている、興味深い暗号化プロトコルがあります。 ほとんどのものがそうであるように、
それは良いことも悪いこともあります。 最終的には、
その意図は良いのですが、現実の世界での応用は
理想的とは言い難い、と私は言いたいです。 皆さん、そのプロトコルがSTARTTLSなのです。
STARTTLSはセキュリティ
プロトコルで、基本的にはSSL/TLSです。 ごく簡単に言うと、STARTTLS は既存の平文、つまり安全でない接続を取り、TLS (または SSL) を使って安全な接続に変換しようと試みます。 つまり、
STARTTLS と SSL/TLS のセキュリティレベルは、実際には変わりません。 すべてが正しく設定されていれば、
どちらもTLS (またはSSL) を使って情報を暗号化することになります。
主な違いは、
接続の状態および/または通信の開始に基づくものです。 STARTTLS
は暗号化された通信を保証するものではありません。 基本的には、「
接続が暗号化されておらず、あなたができるのであれば、これを安全な
接続にする」という意味です。 接続ノード（おそらくサーバー）が
接続を暗号化接続にできない場合、そこからどのように処理するかはクライアント側で
決定することになるかもしれません。
STARTTLSという
修飾語を「便利」としましたが、SSL/TLSを選択するよりも
安全性が低いと考えることもできます。 標準的なSSL/TLSの選択は基本的に、”Use
encryption or bust”（暗号化を使うか否か）です。 STARTTLSは、「あの、もし可能ならそうしてください。 もし
できないなら、他の指示に基づいて進めるかもしれません” と言っているのです。
Here’s Some Conclusive Statements
Often times, the obvious needs to be stated and maybe
overstated. そこで、ここでは、エヘン。 暗号化を使用する。 特に、
非常に重要で、
あらゆる組織構造の大部分に統合されており、情報の成否を左右するようなものには、です。 それにかけるべき労力は、
それほど多くはありません。 エンドツーエンドとイントランジット
の暗号化の両方を使用します。 2234>
もし誰かが、メール
サーバーを暗号化することと暗号化しないことをセットアップする余分な労力を割に合わないと感じるなら、その人は
割に合わないということです。 これは明らかに言い過ぎです。 S/MIME のようなエンドツーエンドの暗号化は、
より複雑なアプローチを必要としますが、
セキュリティの層と層を追加する場合には、それもまた価値あることなのです。 しかし、
安全なリンクを設定し、維持するために時間をかけないという言い訳はできません。
フィッシングに遭わないように
電子メールは最もよく悪用される攻撃経路であり、毎年数百万ドルの損失を組織に与えています。 そして、中小企業にとっては、その被害は致命的であり、サイバー攻撃の被害に遭うと、60%が6ヵ月以内に倒産してしまいます。
*** これは、Hashed Out by The SSL StoreからSecurity Bloggers Networkによって配信されたブログで、Ross Thomasによって執筆されました。 オリジナルの投稿はこちらでお読みください。 https://www.thesslstore.com/blog/encryption-and-email-servers/