回答:
SMTPのSTARTTLS RFC（RFC 3207）に基づく答えは次のとおりです。
自分で話すのではなく、RFCが自分自身で話すことを許可し、関連する4つのビットを太字で強調表示します。
中間者攻撃は、サーバーから「250 STARTTLS」応答を削除することで開始できます。これにより、クライアントはTLSセッションを開始しようとしません。別の中間者攻撃は、サーバーがSTARTTLS機能をアナウンスできるようにすることですが、クライアントの要求を変更してTLSとサーバーの応答を開始することです。このような攻撃を防ぐために、メッセージを正常に転送する前に、選択したホストの適切な暗号スイートのTLSネゴシエーションの成功を要求するように、クライアントとサーバーの両方を構成できる必要があります。可能であればTLSを使用する追加オプションも提供する必要があります。実装MAY 特定のピアとの通信にTLSが使用されたことを記録し、後のセッションで使用されない場合は警告を生成する機能を提供します。
TLSネゴシエーションが失敗した場合、またはクライアントが454応答を受信した場合、クライアントは次に何をするかを決定する必要があります。 主に3つの選択肢があります。SMTPセッションの残りの部分を実行してください [...]
ご覧のように、RFC自体は、クライアントに安全な接続を確立し、安全な接続が失敗した場合にユーザーに通知することを要求するものは何もないと（非常に明確ではありませんが、十分に明確に）述べています。これは、明示的にクライアントに静かに確立するためのオプション提供しますプレーンテキスト接続を。
2つのオプションの間にセキュリティの違いはありません。
SSL / TLSは、最初にSSL / TLS接続を開き、次にSMTPトランザクションを開始します。これは、非SSL / TLS SMTPサーバーが既に実行されていないポートで発生する必要があります。プロトコルの性質上、プレーンテキストと暗号化された接続の両方を処理する単一のポートを構成することは不可能です。
STARTTLSはSMTPトランザクションを開始し、EHLOへの応答でTLSのサポートを相手側から探します。サポートされているコマンドリストにSTARTTLSが見つかった場合、クライアントはSTARTTLSを送信し、暗号化のネゴシエーションを開始します。これはすべて、後方互換性のために25の標準SMTPポートで発生する可能性があります（通常は発生します）
通常、SSL / TLSはエンドクライアントとサーバー間でのみ使用されます。STARTTLSは、サーバー間トランスポートを保護するためにMTA間でより一般的に使用されます。
これら2つの実装を考えると、ユーザーまたは管理者が接続が暗号化されていると想定しているが、暗号化を要求するように実際に構成していない場合、STARTTLSは安全でないと解釈できます。ただし、使用される暗号化はSSL / TLSとまったく同じであるため、このタイプの構成エラーを超えて中間者攻撃に対して多少なりとも脆弱ではありません。
特に電子メールに関しては、2018年1月にRFC 8314がリリースされました。これは、IMAP、POP3、およびSMTP 送信のSTARTTLSメカニズムよりも「暗黙的なTLS」を使用することを明示的に推奨しています。
簡単に言えば、このメモでは次のことを推奨しています。
- TLSバージョン1.2以降は、MUAとメール送信サーバー間、およびMUAとメールアクセスサーバー間のすべてのトラフィックに使用されます。
- MUAおよびメールサービスプロバイダー（MSP）は、（a）メールアクセスおよびメール送信のためのクリアテキストプロトコルの使用を推奨せず、（b）できるだけ早くこれらの目的のためにクリアテキストプロトコルの使用を非推奨にします。
- メール送信サーバーおよびメールアクセスサーバーへの 接続は、「クリアテキスト」ポートに接続し、STARTTLSコマンドまたは同様のコマンドを使用してTLSをネゴシエートするよりも、「暗黙のTLS」（以下で定義）を使用して行われます。
（強調を追加）
答えは、「安全」という意味にある程度依存します。
まず、要約ではSSL / TLSとSTARTTLSの違いを完全に把握していません。
クライアントがTLSを要求するように構成されている場合、2つのアプローチはほぼ安全です。しかし、STARTTLSを使用して安全にする方法については微妙な点がいくつかあり、STARTTLSの実装ではこれらの詳細を正しく把握するのが少し難しくなります。
一方、TLSが使用可能な場合にのみTLSを使用し、TLSが使用できない場合にクリアテキストを使用するようにクライアントが構成されている場合、クライアントが最初に行うのは、プロトコルで使用されるSSLポートへの接続を試みることです。失敗した場合は、クリアテキストポートに接続してSTARTTLSを使用し、いずれの場合もTLSが利用できない場合は最終的にクリアテキストにフォールバックします。攻撃者がSSLポート接続を失敗させるのはかなり簡単です（必要なのは、適切なタイミングのTCP RSTパケットまたはSSLポートのブロックだけです）。攻撃者がSTARTTLSネゴシエーションを無効にし、トラフィックをクリアテキストのままにするのは少し難しいですが、少しだけです。そして、攻撃者はあなたのメールを読むだけでなく、将来の使用のためにユーザー名/パスワードを取得することもできます。
簡単な答えは、TLSをサポートしていることが既にわかっているサーバーに接続している場合（電子メールを送信または読み取る場合にそうであるように）、SSL / TLSを使用することです。接続が攻撃されている場合、接続の試行は失敗しますが、パスワードとメールは危険にさらされません。
一方、TLSをサポートしているかどうかわからないサービスに接続している場合、STARTTLSの方がわずかに優れている可能性があります。
STARTTLSが発明されたとき、「受動的な」リスニングのみの攻撃は非常に一般的でしたが、攻撃者がセキュリティを低下させるためにトラフィックを注入する「アクティブな」攻撃はあまり一般的ではありませんでした。それから20年ほどで、積極的な攻撃が実行可能になり、より一般的になりました。
たとえば、空港などの公共の場所でラップトップを使用して、そこに提供されているwifi経由でメールを読み込もうとすると、そのwifiネットワークがトラフィックで何をしているのかわかりません。WiFiネットワークでは、特定の種類のトラフィックを、クライアントアプリケーションと通信しようとしているサーバーとの間に介在する「プロキシ」にルーティングすることが非常に一般的です。クライアントをクリアテキストにフォールバックさせるために、これらのプロキシがSTARTTLSと「1つのポートを試行してから別のポートを試行する」の両方を無効にすることは簡単です。はい、これは起こります、そしてそれはあなたのトラフィックがネットワークによって見張られることができる方法のほんの一例です。そして、そのような攻撃は3文字の州支援機関に限定されず、
はい、あなたには基本的な権利があります。はい、STARTTLSは間違いなく安全性が低くなります。通知なしにプレーンテキストにフェールバックできるだけでなく、中間者攻撃の対象になるためです。接続は平文で開始されるため、MitMはSTARTTLSコマンドを削除して、暗号化が発生しないようにすることができます。ただし、メールサーバーは、暗号化されたトンネルがセットアップされた後にのみ転送が行われるように指定できると考えています。したがって、これを回避できます。
では、なぜそんなものが存在するのでしょうか？互換性の理由から。いずれかの側が暗号化をサポートしていない場合でも、接続を適切に完了させることができます。
いいえ、アプリケーションが適切に処理する場合、安全性は低下しません。
TLSを処理する方法は4つあり、多くのプログラムで選択できます。
starttls、失敗すると暗号化されていない接続を使用します）starttls機能しない場合は使用して失敗します）専用ポートでのTLSの利点は、未知のプログラムを使用した場合、または最初の起動ウィザードでエラー処理の詳細設定を公開しないプログラムを使用する場合にフォールバックがないことを確認できることです。
ただし、一般的にセキュリティはセキュリティエラーの処理に依存します。TLSポート上のTLSも失敗した場合、プログラムはプレーンテキストポートに切り替えることを決定できます。それが何をするのかを知り、安全な設定を選択する必要があります。また、プログラムは安全なデフォルトを使用する必要があります。