HTTPS URL是否已加密？

使用TLS / SSL（HTTPS）加密時是否加密了全部URL？ 我想知道，由於我但願在使用TLS / SSL（HTTPS）時隱藏全部URL數據。

若是TLS / SSL爲您提供全面的URL加密，那麼我沒必要擔憂從URL隱藏機密信息。

---

#1樓

我贊成之前的答案：

要明確：

使用TLS，URL的第一部分（ https://www.example.com/ ）在構建鏈接時仍然可見。 第二部分（/ herearemygetparameters / 1/2/3/4）受TLS保護。

可是，爲何不該該在GET請求中放置參數有不少緣由。

首先，正如其餘人已經提到的那樣： - 經過瀏覽器地址欄泄漏 - 歷史泄漏

除此以外，您經過http referer泄露URL：用戶在TLS上看到站點A，而後單擊指向站點B的連接。若是兩個站點都在TLS上，則對站點B的請求將包含站點A中的完整URL。請求的referer參數。 站點B的管理員能夠從服務器B的日誌文件中檢索它。）

---

#2樓

正在監控流量的第三方也能夠經過檢查您的流量來肯定所訪問的頁面，並將其與訪問該站點時其餘用戶擁有的流量進行比較。 例如，若是一個站點上只有2個頁面，一個比另外一個大得多，那麼比較數據傳輸的大小就會告訴你訪問了哪一個頁面。 有些方法能夠從第三方隱藏，但它們不是正常的服務器或瀏覽器行爲。 例如，參見SciRate的這篇論文， https： //scirate.com/arxiv/1403.0297。

通常來講，其餘答案是正確的，但實際上這篇論文代表訪問的頁面（即URL）能夠很是有效地肯定。

---

#3樓

在重複的問題上連接到個人答案。 不只URL在瀏覽器歷史記錄中可用，服務器端日誌，並且它也做爲HTTP Referer標頭髮送，若是您使用第三方內容，則將URL公開給您控制以外的源。

---

#4樓

因爲沒有人提供線捕獲，這裏是一個。
服務器名稱 （URL的域部分）以純文本形式顯示在ClientHello數據包中。

如下顯示了一個瀏覽器請求：
https://i.stack.imgur.com/path/?some=parameters&go=here

有關 TLS版本字段的更多信息， 請參閱此答案 （其中有3個 - 不是版本，每一個字段都包含版本號！）

來自https://www.ietf.org/rfc/rfc3546.txt ：

3.1。 服務器名稱指示

[TLS]沒有爲客戶端提供一種機制來告訴服務器它正在聯繫的服務器的名稱。 客戶端可能但願提供此信息以促進與在單個底層網絡地址處託管多個「虛擬」服務器的服務器的安全鏈接。

爲了提供服務器名稱，客戶端能夠在（擴展）客戶端hello中包含「server_name」類型的擴展名。

簡而言之：

• 若是使用SNI擴展，則能夠在ClientHello數據包內明確傳輸FQDN（URL的域部分）

• URL的其他部分（ /path/?some=parameters&go=here ）在ClientHello沒有業務，由於請求URL是HTTP事物（OSI第7層），所以它永遠不會出如今TLS握手中（第4層或5）。 這會後來在一個GET /path/?some=parameters&go=here HTTP/1.1 HTTP請求以後 ，TLS 安全通道創建。

執行摘要

域名能夠明確傳輸（若是在TLS握手中使用SNI擴展），但URL（路徑和參數）始終是加密的。

2019年3月更新

謝謝carlin.scott帶來這個。

SNI擴展中的有效負載如今能夠經過RFC草案提案進行加密。 此功能僅存在於TLS 1.3中（做爲選項，它能夠實現兩端）而且與TLS 1.2及更低版本沒有向後兼容性。

CloudFlare正在這樣作，你能夠在這裏閱讀更多關於內部的內容 - 若是雞必須在雞蛋前面，你在哪裏放雞肉？

實際上，這意味着它不是以純文本形式傳輸FQDN（如Wireshark捕獲節目），而是加密。

注意：這比隱私方面更能解決隱私問題，由於反向DNS查找可能不管如何都會顯示預期的目標主機。

---

#5樓

您也不能始終依賴完整URL的隱私。 例如，正如企業網絡上的狀況同樣，像公司PC這樣的提供的設備配置了額外的「可信」根證書，這樣您的瀏覽器就能夠安靜地信任https流量的代理（中間人）檢查。 這意味着公開了完整的URL以供檢查。 這一般保存到日誌中。

此外，您的密碼也會暴露並可能已記錄，這是使用一次性密碼或常常更改密碼的另外一個緣由。

最後，若是沒有加密，請求和響應內容也會暴露。

Checkpoint在此描述了檢查設置的一個示例。 使用提供的PC的舊式「網吧」也能夠這種方式設置。