帶有 STARTTLS 的 http (80) 上的 TLS/SSL

Question

我正在研究 TLS/SSL 不透過 HTTP 使用的原因。 SSL 連接埠上可以使用其他協議，如 SMTP、POP3、FTP 等（SMTPS, POP3S、文件傳輸協定S）對於第一種方式，第二種方式是在目前連接埠中使用 STARTTLS 選項，副檔名（SMTP 範例）在電子郵件協議上有一種流行的方式使用第二種方式（STARTTLS），但是為什麼http不使用STARTTLS呢？我發現HTTP/1.1 內的 RFC TLS，但現在沒有使用（或者也許我還沒有看到）

Answer 1

其目的之一是升級機制在RFC 2817是提供一個虛擬主機HTTP 與 TLS 的機制，情況早在 2000 年：

升級機制也解決了“虛擬主機”問題。 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。

Answer 2

原因之一可能是額外的 STARTTLS 會增加更多開銷，因為需要額外的往返（請求 + 回應）。從連線開始到回應的時間對於 HTTP 來說相當關鍵，並且進行了大量最佳化來減少這個時間，例如更短的 TLS 握手或 QUIC 等不同的協定。添加諸如 STARTTLS 之類的內容會增加時間，因此不是一個好主意。