https是否加密整個URL？

Question

我GOOGLE了很多，很多答案是是的。例如：Is GET data also encrypted in HTTPS?但是我們公司的高級安全工程師告訴我URL不會被加密。

該圖像表明，如果URL被加密，DNS服務器如何找到主機並連接？

我認爲這是非常強大的一點，雖然這是對大多數答案。所以我很困惑，我的問題是：

1. https是否加密了請求中的所有內容？ （包括URL，主機，路徑，參數，頭文件）
2. 如果是，DNS服務器如何解密請求並將其發送到主機服務器？

我試圖訪問https://www.amazon.com/gp/css/homepage.html/ref=ya_surl_youracct，我的IE瀏覽器發送兩個請求到服務器：

第一：

CONNECT www.amazon.com:443 HTTP/1.0 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: www.amazon.com 
Content-Length: 0 
DNT: 1 
Connection: Keep-Alive 
Pragma: no-cache 

二：

GET /gp/css/homepage.html/ref=ya_surl_youracct HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: en-US,zh-CN;q=0.5 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: www.amazon.com 
DNT: 1 
Connection: Keep-Alive 

看來我的瀏覽器已經請求兩次：第一次是建立與主機的連接（不加密），第二次通過https發送加密的請求？我對嗎？如果我正確理解這一點，當客戶端使用https調用RESTFUL API時，它每次發送請求（連接和獲取/發佈）兩次？

Answer 1

URL IS從離開瀏覽器的時間開始直到它到達目標服務器。

什麼情況是瀏覽器從URL中提取域名和端口並使用它來解析DNS本身。然後它啓動到目標服務器IP：端口的加密通道。然後它通過該加密通道發送HTTP請求。

重要的部分是任何人，但您和目標服務器只能看到您連接到特定的IP地址和端口。他們不能告訴其他任何東西（比如特定的URL，GET參數等）。

攻擊者在大多數情況下甚至無法看到域（儘管如果實際上有DNS查找 - 如果沒有緩存，他們可以推斷出它）。

要理解的重點是DNS（域名服務）是一種完全不同於HTTP的協議。瀏覽器使DNS查找請求將域名轉換爲IP地址。然後它使用該IP地址發出HTTP請求。

但是，DNS服務器在任何時候都不會收到HTTP請求，並且在任何時候都不會爲用戶提供域名 - IP映射。

Answer 2

的URL（也稱爲 「統一資源定位器」）包括四個部分：

1. 協議（如HTTPS）
2. 主機名（如stackoverflow.com）
3. 端口（並不總是包括，通常80 http和https爲443）
4. 路徑和文件名或查詢

一些例子：

ftp://www.ftp.org/docs/test.txt 
mailto:user@test101.com 
news:soc.culture.Singapore 
telnet://www.test101.com/ 

作爲整個單元的URL實際上並未加密，因爲它並未完整傳遞。這個URL實際上被拆分成不同的部分，每個部分以不同的方式使用。例如。協議部分會告訴瀏覽器如何使用URL的其餘部分，主機名將告訴它如何查找目標收件人的IP地址，並且端口會告訴它，以及使用哪個端口。 在有效負載中傳遞的URL的唯一部分是路徑和查詢，並且該部分已加密。

如果你看看在原始的HTTP請求時，它看起來是這樣的：

GET /docs/index.html HTTP/1.1 
Host: www.test101.com 
Accept: image/gif, image/jpeg, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 
(blank line) 
--Body goes here-- 

你在上面的例子中所看到的傳遞。注意完整的網址無處顯示。主機頭實際上可以完全省略（它不用於路由）。此處顯示的URL的唯一部分位於GET謂詞的右側，並且僅包含原始URL的最右側部分。協議和端口號在消息本身中無處顯示。

簡答：網址中端口號右側的所有內容都包含在https請求的有效負載中，並且事實上是加密的。

Answer 3

雖然其他答案在他們去的時候是正確的，但除瀏覽器和服務器之間的加密外，還有許多其他考慮因素。這裏有一些事情要考慮...

• 服務器的IP地址已解析。
• 瀏覽器使用TLS與服務器的IP地址建立TCP套接字連接。這是您在示例中看到的CONNECT。
• 該請求通過加密會話發送到服務器。

如果這就是它，你就完成了。沒問題。

但是等等，還有更多！

在一間GET，而不是一個POST領域揭示了敏感數據時...

• 有人看在服務器日誌。這可能是一個史努比員工，但它也可以是國家安全局或其他三個字母的政府機構，或者如果在審判中被傳喚，日誌可能會成爲公開記錄。
• 攻擊者導致網站加密回落到明文或破碎的密碼。看看來自Qualsys實驗室的the SSL checker，看看一個網站是否容易受此影響。
• 任何頁面上的鏈接到外部網站將顯示頁面的URI作爲referrer。用戶ID和密碼無意中通常以這種方式向廣告網絡提供。我有時會在我自己的博客中看到這些。
• 該URL在瀏覽器歷史記錄中可用，因此可供腳本訪問。如果計算機是公開的（有人從賓館或機場休息室的賓客計算機檢查您的網站），GET請求會將數據泄露給使用該設備的其他人。

正如我所提到的，我有時在我的博客的引用日誌中找到ID，密碼和其他敏感信息。就我而言，我聯繫了推介網站的所有者，並告訴他們他們將用戶暴露給黑客。一個不那麼認真的人會通過鏈接到他們自己的網站來添加對該網站的評論或更新，以便在其引用日誌中收集敏感數據。

因此，貴公司的高級安全工程師是正確的，該網址在許多地方都沒有加密，因爲這是非常重要的。您和其他受訪者也是正確的，它在對TLS會話環境中的瀏覽器與服務器通話的非常狹窄的用例中進行了加密，其中爲。也許你提到的混淆與這兩個用例範圍的不同有關。

另請參閱：

• Testing for Exposed Session Variables (OTG-SESS-004)
• Session Management - How to protect yourself（請注意， 「總是使用POST」 重複一遍又一遍在此頁。）
• Client account hijacking through abusing session fixation on the provider