暗黙のSSLを使用する一般的なサービスが、SMTPSのように時代遅れと見なされないのはなぜですか？
SMTPS（暗黙のSSL）は、SMTP + STARTTLS（明示的なSSL）が RFC2487 で定義されているため、非推奨/廃止されました。その背後にある理由については完全には明確ではありませんが、当時はそれは良い考えであると明確に考えられていました。
IMAPとPOP3の場合、IMAP + STARTSSLのポート143とIMAPSのポート993、POP3 + STARTTLSのポート110とPOP3Sのポート995を使用すると、同じことがわかります。
これらのプロトコルはSMTP暗号化オプションと同じように異なるため、これらの暗黙のSSLオプションが同じ方法で廃止されないのはなぜですか？
とは言っても、明示的なSTARTTLSをより良いオプションと見なすべき理由はわかりません。確かに、できるだけ早く暗号化を開始する方が良いでしょう。STARTTLSはそれを行わないので、暗黙的に暗号化されたサービスが望ましいのでしょうか。 これを正確に示唆しているインターネットドラフト があるため、この考え方は私だけではないようです。
私が見ることができる明示的な暗号化の唯一の利点は、同じポートでクリアテキストサービスを実行できることです。ただし、回避できる場合、それを推奨したり、サポートを継続したりする必要はないようです。
このすべての背後にある理論的根拠は何ですか？
tl; dr：
- 暗黙的なTLSも明示的なTLSも技術的にそれほど悪いものではないためです。
- インターネットの仕組みを変えるには時間がかかるからです。
これは本質的に1つではなく2つの異なる質問であり、個別に取り上げます。
1.暗黙のSSLを使用する一般的なサービスが廃止されたと見なされないのはなぜですか？
すでにお気づきかもしれませんが、近年では、GoogleやFacebookなどの大企業がHTTP通信のセキュリティ保護に多大な努力を払い、その成功に大きく貢献しています。しかし、その主な要因の1つはISPであるようです Web広告を独自のものに置き換える 。これは、Googleや他のビジネスモデルに深刻な悪影響を及ぼします。
ちなみに、これによる暗黙の影響は非常に大きく、結果としてインターネットの構造そのものが大きく変化します。 APNICのGeoff Hustonが 彼の優れたブログ投稿 と関連するプレゼンテーション（ slides 、 video ）に要約しているので、参照することをお勧めしますここではさらに説明せずに、.
もちろん、他のドライバーもありますが、それらの多くはまだ誰かのビジネスモデル（例： PCI SSCアクティビティ など）を保護することに強く拘束されています。
ここで最も重要なのは、HTTP領域でのこれらの成果によりかなり高いレベルが発生することですが、電子メールを含む他の多くの通信方法では、その種の商用ドライバーが不足しているようです幸運にもHTTPはあり、これはおそらく、現在HTTPにあるものと比較して、セキュリティが時代遅れになっている主な理由の1つです。その結果、2018年も、クリアテキストでのみ通信できる ser および transfer エージェントの多くの古いメールアクセスサーバーをサポートする必要があります。
うまくいけば、これは変わるでしょうが、私は現在、そのための明確な見積もりを提供することはできません。
通信をセキュリティで保護することは、セキュリティをまったく保護しないよりも優れているため、暗黙的および明示的なTLSアプローチはクリアテキストよりも優れています。一部のMUAとMTAの展開では、暗黙的または明示的なTLSのみがサポートされており、いずれかの概念が廃止されたため、これらの展開はMitM攻撃に対する対策がありません。インターネットで積極的に使用されているプロトコルとメソッドを非推奨にする-本質的に何よりも優れている-何もしないことは悪い習慣です。
ご覧のとおり、SMTPSを廃止するだけでは何の効果もありません。それはまだ実際に存在しています。これは、広く使用されているインターネットプロトコルを自由にシャットダウンすることができない例です。確かに、面白そうに聞こえますが、1998年頃に起こったときは、今日ほどはっきりしていなかったかもしれません。
さらに、一方の概念がもう一方の概念より古くなっていることを宣言することは、インターネットコミュニティによってサポートされている必要があります。ほとんどの人は、結局のところ2つのオプションのうち1つだけを優先することを認めるべきですが、簡単に到達することはできません。明示的なTLSが優れているかどうかについてのコンセンサス（詳細は以下を参照）。 インターネットドラフト あなたが指摘しているのは、共通の問題を引き起こすことなく、このすべての混乱に正気をもたらす基本的なイニシアチブです 標準のジレンマ ：
いったん確定すると、明示的なTLSの廃止のプロセスが将来のある時点で開始されますが、時間がかかります。
2.明示的なSTARTTLSを選択する方がよいのはなぜですか？
免責事項：これは、インターネットプロトコル設計に対する現在のアプローチの概要にすぎません。私はここでは脇役になりません。それらのアプローチに対する反対の適切な場所はIETF ワーキンググループメーリングリスト および meetings です。
暗黙のTLSは、現代の脅威モデルを念頭に置いてゼロから設計され、平文通信をサポートする必要がないプロトコルに最適です。ただし、暗黙のTLSは、古いクリアテキストプロトコルの保護に関して、議論の余地のあるアプローチです。 HTTPSでは正常に機能しているようですが、安全なHTTP通信のために別のポート（443）を割り当てるなど、多少の労力が必要でした。
このアプローチの欠点は、残りの各平文プロトコルに対して、グローバルTCPポートスペースが大幅に制限されている一方で、別のTCP/UDPポートを割り当てる必要があることです。ある時点で、IETFが機能することです。グループは一般に、この方法でポートを無駄にすることは悪い習慣であり、ポート465（元はSMTPS）でさえ考えていました 後で別の目的のために再割り当てされました （これは実際に約20年前に発生しました。ゆっくりとインターネットは変化を取り入れます）。
繰り返しになりますが、 draft-ietf-uta-email-deep で確認できるように、この考慮事項は近い将来廃止される可能性があります。また、この草案はもともと2013年にさかのぼり、現在は最終的な状態に近づいているだけであることにも注意してください。
opportunistic（または明示）TLSの一般的な考え方は、特定のリモートであることをクライアントに事前に（以前に確認済みで信頼されている別の通信チャネルを使用して）何らかの方法で通知することですサーバーはSTARTTLSをサポートしているため、クライアントはそのサーバーへのデータ転送にのみSTARTTLSを使用する必要があるため、 [〜＃〜] striptls [〜＃〜] 攻撃を防止できます。もともとDNSSEC この別個のチャネルを提供することになっていた 、しかし、その世界的な展開 どういうわけか停滞している 、そしてその結果、ワーキンググループは他の方法（例 [〜＃〜] tofu [〜＃〜] ）それを行うには。
暗黙のアプローチ自体も、ダウングレードに耐性があるわけではないことに注意してください。中間者 暗黙のTLSを取り除くことができます と同様です。 [〜＃〜] hsts [〜＃〜] のようなアプローチは、TOFU自体に依存します。一般的な議論は、ユーザーがクライアント設定でポート番号を明示的に指定することでソフトウェアクライアントに安全な通信を強制できることですが、ソフトウェアクライアントはユーザーに古いポートでSTARTTLSを明示的に強制する機能を提供することもできるため、ユーザーの観点から2つのアプローチの違いはわずかです。
ポート465は廃止されていません
ウィキペディアによると： https://en.wikipedia.org/wiki/SMTPS ：
RFC 8314「廃止予定のクリアテキスト：電子メールの送信とアクセスにTLSを使用する」は、暗黙的に暗号化されたメール送信用のポート465の登録を復元します。
具体的に： https://tools.ietf.org/html/rfc8314#section-3. （2018年1月から）