1

クライアントがサーバーがSSLを有効にすることを期待しているかどうかを知る方法はありますか?

私は小規模な SMTP サーバーを構築しており、465 に SSL を実装していますが、一部のクライアントは SSL を想定していないため、明らかに接続に失敗します。

これを何らかの方法で伝えることは可能ですか？

4

1 に答える 1

1

クライアントが接続の開始時に SSL/TLS を使用することを期待しているかどうかをサーバーが検出する明確な方法はありません。実際、サーバーが最初にデータを送信することが期待されている場合 (SMTP の場合のように、サーバーはクライアントがデータを送信する前にバナーを送信します)、それを行う方法はまったくありません。

これが、SSL/TLS が一般的に次の 2 つの方法のいずれかで使用される理由です。

  • SSL/TLS バージョンのプロトコル用に新しいポート番号が指定されています。たとえば、HTTP (ポート 80 の代わりにポート 443)、IMAP (ポート 143 の代わりにポート 993)、SMTP (ポート 25 または 587 の代わりにポート 465)。サーバーは、新しいポートで接続を受け入れる場合、すぐに SSL/TLS を使用することを認識します。
  • STARTTLS : サーバーとクライアントは、プロトコルの非 SSL/TLS バージョンについて話すことから始めますが、サーバーはサービス機能のアナウンスで STARTTLS を示します。クライアントはオファーを受け入れ、それを要求します。サーバーとクライアントの両方が、SSL/TLS を使用してプロトコルを再起動するようになりました。

STARTTLS は、サーバーとクライアント間の非 SSL/TLS 通信が最初に発生する (複数のネットワーク ラウンド トリップを使用する) ため、少し効率が悪く、すべてのプロトコルで使用できるわけではありません (HTTP はサポートしていません)。電子メール設定の自動構成などを簡単に行えるため、利用可能な場合は一般的に好まれます (可能なポートの束を調べて最適なものを選択する必要はありません)。

ポート 465 は最初の解決策の例です。新しいポートを選択し、そのポートで SSL/TLS を実行します。つまり、サーバーとクライアントの両方が、そのポートでの通信にすぐに SSL/TLS を使用することになっています。

クライアントがポート 465 で平文の SMTP と通信しようとしている場合、それらのクライアントは BROKENです。それらを回避するためにできることは本当に何もありません。クライアントには修正が必要な深刻なバグがあります...

さらに、SMTP の場合、ポート 465 で SMTP over SSL/TLS ではなく、実際に STARTTLS を使用する必要があります。

于 2013-02-02T21:29:03.027 に答える