%20%E4%B8%8A%E3%81%AE%20TLS%2FSSL.png)
TLS/SSLがHTTP経由で使用されない理由を調査しています。SMTP、POP3、FTPなどの他のプロトコルはSSLポートで使用できます(SMTPス、POP3ス、FTPス) を使用する方法と、2 番目の方法は、現在のポートで拡張子 (SMTPの例) 電子メールプロトコルでは2番目の方法(STARTTLS)を使用するのが一般的ですが、なぜhttpはSTARTTLSを使用しないのでしょうか?HTTP/1.1 内の RFC TLS、しかし、最近は使われていない(あるいはまだ見たことがないのかもしれない)
答え1
目的の一つはアップグレードの仕組みでRFC 2817提供したのは仮想ホスティング2000 年当時の TLS を使用した HTTP のメカニズムは次のとおりです。
アップグレード メカニズムは、「仮想ホスティング」の問題も解決します。HTTP/1.1 サーバーは、単一のホストに複数の IP アドレスを割り当てるのではなく、Host: ヘッダーを使用して、目的の Web サービスを明確にします。HTTP/1.1 の使用が普及するにつれて、より多くの ISP が名前ベースの仮想ホスティングを提供するようになり、IP アドレス空間の枯渇を遅らせています。
のサーバー名の表示(SNI;RFC 3546、3.1) は 2003 年にこの問題に対するより良い解決策を提示しました。これは現在も使用されているもので、そのためこのヘッダーはもう必要ありません。Upgrade
ヘッダーは今も生きていますが、HTTP/1.1 から HTTP/2.0 への切り替えなど、異なる目的で使用されています (RFC 7230、6.7)。
HTTPプロトコルにはヘッダーLocation
(RFC 7231、7.1.2) を関連する応答コードとともに使用することで、 を使用していたプロトコルとは異なり、クライアントを別のスキーム、ホスト、ポートにリダイレクトすることが容易になりますSTARTTLS
。
また、使用することはSTARTTLS
良いことではなく望ましいことではなく、より多くのプロトコルで採用されるべきものであることにも注意してください。実際、RFC 8314電子メールの送信とアクセスのためのクリアテキストプロトコルは廃止され、MTA-MTA SMTPが唯一の電子メールプロトコルとしてSTARTTLS
使用されるようになりました。セクション3:
– – このメカニズムは導入されていますが、別のポートで接続開始時に TLS が直ちにネゴシエートされる代替メカニズム (このドキュメントでは「暗黙的 TLS」と呼びます) の方が、より効果的に導入されています。TLS のより広範な使用を促進し、TLS の使用方法に関する一貫性を高めるために、この仕様では、POP、IMAP、SMTP 送信、および MUA と MSP 間で使用されるその他すべてのプロトコルに暗黙的 TLS を使用することを推奨しています。
答え2
理由の 1 つは、追加のラウンドトリップ (要求 + 応答) が必要になるため、追加の STARTTLS によってオーバーヘッドが増加する可能性があることです。ただし、接続開始から応答までの時間は HTTP では非常に重要であり、この時間を短縮するために、TLS ハンドシェイクの短縮や QUIC などの異なるプロトコルなど、多くの最適化が行われています。STARTTLS などを追加すると、かえって時間が長くなるため、良いアイデアではありません。