Opportunistic TLSはプレーンテキスト通信プロトコルの拡張機能を指し、暗号化通信に別のポートを使用する代わりに、プレーンテキスト接続を暗号化(TLSまたはSSL)接続にアップグレードする方法を提供します...出典: Wikipedia
Opportunistic TLSは、たとえばIMAPおよびPOP3で「STARTTLS」コマンドを使用して使用できます。1 または「AUTH TLS」コマンドを使用してFTPで2。
このようなコマンドは次の質問を投げかけます:
簡単に言うと、日和見TLSの目的は何ですか?
順番に:
- 下位互換性のためだけに(既知の/使用されているポートとの)便宜的TLSを使用していますか?
はい。既存のサービスがある場合、相手側が方法を知っている場合は、TLSを使用する必要なく、TLSを使用できるようにすると、方法を知らないエンドポイントと引き続き通信できるようになります。
- 日和見的なTLS実装は、ネイティブ/通常実装されたTLS/SSLの使用とはどう違いますか?
実際のコードの観点からは、そうである必要はありません。たとえば、アプリケーションがHTTPSトラフィックにOpenSSLを使用するのと同じように、多くのメールサーバーは便宜的なTLS実装にOpenSSLを使用します。
- 適切に構成されたTLSと同じ「セキュリティのレベル」を日和見TLSを使用して実現できますか?
いいえ。下位互換性のために設計されており、暗号化されていないトラフィックと同じポートを使用するため、便宜主義的なTLSを使用する要求は、アクティブな中間者によって取り除かれ、暗号化されていない接続と伝送が発生します。 HTTPSには、SSLストリップなどの表面的に同様の問題がありますが、HTTPSなどのプロトコルを使用する場合は、TLSによって正しく保護されていない接続が失敗するように構成できます。接続のもう一方の端が実際に合法的に使用したくない、またはTLSの使用方法を理解していない可能性があると常に想定し、プレーンテキスト送信に適切にダウングレードする日和見TLSで同じことを行うことはできません。
さて、主なアイデアは「ホイールを再発明しない」ことです。標準プロトコルには、ポート番号が特別に標準化されています。より高いセキュリティレベルが必要ですか? - どういたしまして! STARTTLSを有効にして、必要なだけ安全にします。これは、STARTTLSがもたらすセキュリティ強化に制限されていないためです。 完全に後方互換性を維持するのにそれほど快適ではありませんか? -ダイアログの最初にSTARTTLSを強制するか、既知の後方互換性のある方法で接続をドロップすることができます。これは通常、ポート25のSMTPで行われます。
もちろん、SMTP for SMTPのように、既知のプロトコルのすぐに使用できる安全なプロトコル実装が損なわれることはありません。しかし、時代遅れのクライアントであってもネットワークの相互運用性を維持します
適切に構成されたTLSと同じ「セキュリティのレベル」を日和見TLSを使用して実現できますか?
正しく使用すれば可能です。たとえば、FTPを使用する場合、クライアントはTLSが使用されているかどうか、およびどの証明書で使用されているかを通知できます。これは、HTTPSサイトを参照するときと同様に、接続のセキュリティをチェックするクライアントに負担をかけます。
SMTPなどの電子メールプロトコルでは、これは実際には機能しません。多くの場合、ユーザーは存在せず、電子メールはこのような分散システムであるため、どの証明書を使用する必要があるかが不明確です。ほとんどのSMTPクライアント 証明書を検証しない 、中間者攻撃を可能にします。