題:
SSL / TLS（https）是否隱藏正在訪問的網址
Jus12
2011-09-29 17:45:18 UTC
view on stackexchange narkive permalink

假設我在瀏覽器中輸入了

  https://www.mysite.com/getsecret?username=alice&password=mysecret

攻擊者正在監視從我到ISP的所有流量。

哪些信息受HTTPS保護？網址顯示了嗎？

還顯示HTTP請求的參數嗎？

此外，HTTPS是否為URL提供完整性？

我嘗試查看各種HTTPS文章和TLS規範，但無法弄清楚。

[EDIT：]可以，只要僅顯示服務器域名即可。但是，不應顯示？username = alice&password = mysecret 的任何部分。

另請參閱[我的公司可以看到我去過的HTTPS站點嗎？]（http://security.stackexchange.com/q/2914/971）-不是重複的，但是可能是相關的。
相關：[通配符證書是否隱藏了URL以防止被訪問？]（http://security.stackexchange.com/questions/7739/can）
六 答案:
Paŭlo Ebermann
2011-09-29 18:15:12 UTC
view on stackexchange narkive permalink

HTTPS協議等效於通過 SSL或TLS連接（通過TCP）使用HTTP。

因此，首先是與服務器的TCP連接（端口443）已打開。這通常足以向攻擊者透露服務器的主機名（在您的情況下為 www.mysite.com ）。 IP地址是直接觀察到的，並且：

  1. 您通常在之前未進行過DNS加密查詢，
  2. 許多HTTPS服務器每個IP地址僅服務一個域，
  3. 服務器的證書以純格式發送，並包含服務器名稱（可能在多個證書之間）。
  4. 在較新的TLS版本中，有服務器名稱指示，客戶端通過該指示來指示服務器希望使用哪個主機名，如果服務器有多個證書，則服務器可以提供正確的證書。 （這樣做是為了能夠脫離2。）
    5. ol>

    然後發生TLS握手。這包括協商密碼套件，然後協商密鑰交換。假設您的瀏覽器和服務器中至少有一個沒有在接受的套件中包含 NONE 密碼，則密鑰交換之後的所有內容都會被加密。

    並假設沒有成功中間人攻擊（即確實攔截了連接並提供您的瀏覽器接受的偽造的服務器證書的攻擊者），密鑰交換是安全的，並且任何竊聽者都無法解密隨後在您與服務器之間發送的任何內容，並且攻擊者也無法更改內容的任何部分而不會被注意到。這包括URL和HTTP請求的任何其他部分，以及來自服務器的響應。

    當然，以D.W.提到，從加密的數據流中可以看到請求的長度（其中包含的可變數據比URL少很多，可能還包含一些Cookies）。這可能會破壞保密性，尤其是在服務器上只有少量不同資源的情況下。還有任何後續資源請求。

    您在URL（或請求的任何其他部分）中的密碼仍然應該是安全的-最多可以知道其長度。

另外，服務器名稱包含在服務器作為握手的一部分發送回客戶端的證書中，並且該證書是“明文”發送的，因此目標服務器名稱實際上根本不是秘密的。
http://www.securityweek.com/hackers-can-intercept-https-urls-proxy-attacks
簡而言之：如果您訪問某個NSFW URL，則該行中的任何人都可以當時知道*您*已連接到該**站點，但是沒有人可以知道您所請求的NSFW內容
@everydayjoe感謝您的編輯建議，但我認為這裡不需要。它也已經合併到其他答案中。
gowenfawr
2011-09-30 05:03:51 UTC
view on stackexchange narkive permalink

正如@PaŭloEbermann和@Jeff Ferland告訴您的那樣，GET請求是使用SSL加密的，因此是安全的。 但是，請不要忘記許多Web服務器記錄GET請求和參數，並且您通過GET發送的任何憑據或其他敏感信息都可以寫入某處的日誌中。因此，提交敏感數據時應使用POST（也將使用SSL加密）。

這屬於“加密不是解決所有問題的不可思議的安全性”類別。 / p>

日誌問題是可以的。在我的攻擊模型中，攻擊者只能攔截流量，而不能侵入服務器。但是，由於您提到的原因，在將來的版本中，我將開始使用POST。
@Jus12這對於抵抗社會攻擊（攻擊者可以從屏幕上讀取URL）也更好。
請注意，僅使用`POST`是不夠的（它將以相同的方式記錄），還需要確保“秘密”信息位於請求正文中，而不是URL中。
D.W.
2011-09-30 13:08:20 UTC
view on stackexchange narkive permalink

您應該假定該URL沒有受到保護，也就是說，一個被動的竊聽者可能能夠了解您正在訪問的URL。

我意識到這與其他人所聲稱的相矛盾，所以我最好解釋一下。

的確，域名發送後的所有內容都是加密的。例如，如果URL是 https://www.example.com/foo/bar.html ，則 www.example.com 對攻擊者可見，而HTTP請求（ GET /foo/bar.html HTTP / 1.0 ）已加密。這確實防止了竊聽者直接看到URL的路徑部分。 但是，竊聽者可能會看到URL路徑部分的長度。此外，竊聽者還可能看到其他信息（例如，您訪問的頁面的長度）。這是攻擊者的大門。如果攻擊者可以竊聽您的https流量，則有一些研究利用這隻腳在門上來了解您正在訪問的URL。

但不能保證這些攻擊將成功，我建議最好假設最壞的情況：假設竊聽者可能能夠了解您正在訪問的URL。因此，您應該不假定SSL / TLS從竊聽者隱藏了您正在訪問的頁面。

是的，https確實為您訪問的URL提供了完整性。

PS另一種警告：在實踐中，如果網站未使用 HSTS，則sslstrip和其他中間人攻擊可能會成功地攻擊許多或大多數用戶。這些攻擊可能會侵犯URL的機密性和完整性。因此，如果用戶正在通過不安全的網絡（例如開放的Wifi）訪問未使用HSTS的網站，則應警惕攻擊者可能能夠獲悉用戶正在訪問哪些頁面。緩解sslstrip威脅的部分緩解措施是，用戶在各處使用HTTPS，讓站點採用HSTS。

Jeff Ferland
2011-09-29 18:25:27 UTC
view on stackexchange narkive permalink

在您的會話開始之前，以下內容將洩漏：

  • 服務器的IP地址
  • 服務器的證書
    • 其中將包括域證書上發布的名稱，儘管不能保證它會與您使用的名稱匹配。
  • 您的DNS查詢

無數據或與創建SSL連接無關的請求（ GET ... ）在SSL會話開始之前已發送到服務器。該URL作為頁面請求的一部分發送，並與會話中的任何流量一樣受到保護。

Nakedible
2011-09-30 12:46:04 UTC
view on stackexchange narkive permalink

是，不是。

URL已正確加密，因此永遠不要直接顯示查詢參數。

但是，流量分析通常可以獲取URL的長度-並且知道服務器和url的長度通常足以竊聽正在訪問的頁面，尤其是在假設單擊頁面上的鏈接的情況下。 Google用於“流量分析ssl瀏覽”或類似的方法（如果您感興趣的主題）。

在您的用例中，這僅是至關重要的。流量分析的巧妙使用可能會顯示用戶名的長度和/或密碼的長度，這取決於所獲取的其他URL是否也包含用戶名。如果將用戶名/密碼固定為固定長度，則可以避免這些攻擊，但這可能不值得麻煩。

Steve Dispensa
2011-09-30 06:34:16 UTC
view on stackexchange narkive permalink

TLS堆棧開始發送服務器名稱指示（SNI， http://en.wikipedia.org/wiki/Server_Name_Indication； http://www.ietf.org/rfc /rfc3546.txt）。這是明文發送的，這意味著竊聽者可以看到您在地址欄中鍵入的服務器名稱。



ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。
Loading...