jojo
2011-10-15 05:23:38 UTC
有一個桌面客戶端A通過https連接連接到網站W
A --> W A和W之間存在某種方式是代理G。
A --> G --> W - 在這種情況下，G將能夠獲得證書
題:
七 答案:
Hendrik Brummermann
2011-10-22 01:19:03 UTC
HTTPS如何工作？
HTTPS基於公鑰/私鑰加密。這基本上意味著有一個密鑰對：公鑰用於加密，而私鑰則用於解密。
證書基本上是帶有密鑰的公鑰。標籤來標識所有者。
因此，當您的瀏覽器連接到HTTPS服務器時，該服務器將使用其證書進行回答。瀏覽器檢查證書是否有效：
- 所有者信息需要與用戶請求的服務器名稱匹配。
- 證書需要
如果不滿足這些條件之一，則將問題告知用戶。
驗證後，瀏覽器提取公鑰，然後將其用於加密某些信息，然後再將其發送到服務器。服務器可以解密它，因為服務器具有匹配的私鑰。
HTTPS如何防止中間人攻擊？
在這種情況下，G是否可以從W獲得A先前獲得的證書？
是的，該證書是帶有標籤的公鑰。網絡服務器會將其發送給連接它的任何人。
如果G可以獲取證書，這是否意味著G能夠解密數據？
不。證書包含網絡服務器的公共密鑰。惡意代理不具有匹配的私鑰。因此，如果代理將真實證書轉發給客戶端，則它無法解密客戶端發送給Web服務器的信息。
代理服務器可能嘗試偽造證書並提供自己的公共密鑰。但是，這將破壞證書頒發機構的簽名。瀏覽器將警告無效證書。
代理服務器是否可以讀取HTTPS？
如果您的計算機的管理員可以配合使用，則代理服務器可以嗅探https連接。在某些公司中使用此命令來掃描病毒並執行可接受的使用準則。
設置了本地證書頒發機構，管理員告訴您的瀏覽器該 CA值得信賴。代理服務器使用此CA對他的偽造證書進行簽名。
哦，當然，用戶傾向於單擊安全警告。
如果管理員和計算機配合，則不會出現證書警告。用戶如何知道代理是否收聽對話？我的公司Afaik掃描https，但是當我檢查https站點的證書時，在鏈信任中沒有看到自簽名證書。
您可以檢測到它。第一，您的公司證書不是自簽名證書。它是由權威機構正式簽名的證書，該證書自動嵌入世界上的所有Internet Explorer中。要在不通知您的情況下檢測所有“魔術”證書配額，有一條唯一但困難的途徑。刪除Internet Explorer中所有經過魔術授權的根證書。從此開始，您將必須明確接受**所有服務器證書**。您將必須閱讀，理解它們並接受您**信任**的內容。
一個問題是：我看不到離開網絡的內容，但是服務器發送回瀏覽器的響應又如何了，現在我有了公共密鑰，這是否意味著我可以解碼所有響應並且看到了所有瀏覽器是什麼看到了嗎？
公鑰僅允許您加密數據，並且僅用於會話密鑰協商。 （@Hendrik，您可能會改進有關瀏覽器使用公鑰的部分）
能夠為使用您計算機信任的任何ca的簽名證書籤名的代理生成證書的人都可以攔截您的連接。是否有任何RFC /技術可以阻止這種連接？我知道一些提供證書指紋數據庫的插件，並會警告您，如果您獲得的證書指紋與插件服務器獲得的證書不同，但也會被攔截。儘管https代理如今僅在公司中使用，正如您所描述的，這為具有足夠影響力的攻擊者打開了mitm攻擊方式，使他們可以使用受信任的CA。
@masi有一個名為[Certificate Patrol]（http://patrol.psyced.org/）的項目，該項目跟踪以前看到的證書，並可以在證書意外更改時提醒您。它在上述公司環境中沒有用，但在您的本地網絡充滿敵意時可以在移動設備上提醒您。
W返回給A的響應又如何呢？ G可以閱讀嗎？
@se7entyse7en號就像W具有私鑰一樣，A在通信開始時也建立了這樣的密鑰。G沒有這兩個鍵。
@zinking不，您不能，公共/專用密鑰僅用於創建會話密鑰，並且該會話密鑰用於加密/解密https客戶端/服務器之間的所有流量，因為對稱加密必須更快。
好文章。謝謝。我有一個問題：在會話密鑰協商之前，`G`可以從Web服務器捕獲公共密鑰並比`A`更早地進行會話密鑰協商，以便他可以充當`A`嗎？
@Jeon,的公開密鑰（和證書信息）是公開的，因此任何人都可以抓住它。但是在TLS握手期間，服務器必須證明它知道關聯的私鑰。在某個時候，客戶端將使用公鑰加密一條無法猜測的信息，而服務器必須使用其私鑰對其解密，以繼續進行握手。有關詳細信息，請參見[關於TLS的維基百科文章]（https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake）。
您可以在此處添加更多信息嗎：“銷毀證書頒發機構的簽名”。那麼，為什麼“ G”不能將其公鑰提供給“ A”並以正確的方式使用自己的私鑰對證書進行欺騙呢？所以它是雙重簽名的，一次是由“ W”簽名的，一次是由“ truzsted證書提供者的簽名的”，而`A`也知道這個公鑰的。
這如何給Web應用程序帶來安全風險？
另一個破壞該概念的情況可能是預裝的膨脹軟件的形式。我記得最突出的案例是Lenovo安裝“ SuperFish”。儘管最終這僅相當於“管理員合作”，但在這種情況下是不知不覺中的。
請注意，對於非NSS批准的證書，較新版本的Firefox將顯示“由Mozilla不能識別的證書頒發者驗證的連接。”，因此（與Chrome和IE不同），Firefox用戶可以注意到當前的COTS TLS代理只需點擊一下法醫調查即可。
D.W.
2011-10-15 07:38:17 UTC
假設用戶沒有單擊證書警告（並假設您正在運行未修改的客戶端），答案是：否，代理無法解密數據。
有關HTTPS如何防止中間人解密流量的詳細說明，請參閱SSL / TLS上的任何標準資源，例如
PS該證書是公共數據。它包含服務器的公鑰和域名，兩者都不是秘密。遵守證書並不能幫助攻擊者解密數據。 （是的，代理可以觀察證書，但這是無害的。）
假設沒有根CA被彈出並失去對其私鑰的控制。
一個合理的假設是，（根和委託）CA將向其國家情報機構提供偽造的證書。顯然，使用這些類型的證書的代理設備已經公開上市，這很可能是偶然的。
實際上，[Blue Coat ProxySG]（https://www.bluecoat.com/products/proxysg）長期以來一直在HTTPS上執行MiTM，這取決於通過訪問它們的客戶端上安裝的自定義受信任證書，基本上是假裝CA成為_caching_代理。通過在客戶端上安裝受信任的根證書，然後通過其欺騙的CA服務器代理所有請求，諾基亞（Nokia），Opera Mobile，亞馬遜（Amazon）Kindle等也是如此。簡而言之，聲稱或似乎正在緩存，重新壓縮或以其他方式優化HTTPS內容的任何人都在這樣做。
當然，代理可以解密數據-您為代理建立一個ssl conn，該代理將解密所有內容，然後在響應上建立到實際目的地的ssl conn，反之亦然：http://www.zdnet.com/article/how-the- NSA和您的老闆可以攔截並破解SSL /
@markmnl要求將客戶端設置為信任代理的證書，或者用戶盲目忽略由此產生的錯誤消息（坦率地說，這是一個不錯的選擇）。在您鏈接的文章中：“如果您的公司正確設置了代理，您將不會發現任何問題，因為他們會安排在您的計算機上將代理的內部SSL證書註冊為有效證書。否則，您會收到一條彈出錯誤消息，如果單擊繼續，它將接受“偽造”數字證書。”
manav m-n
2014-09-17 12:33:31 UTC
摘自 Philipp C. Heckel的技術博客，進行了一些簡短的編輯：
儘管可以處理未加密的HTTP流量，而無需處理X.509證書和證書頒發機構（CA），SSL加密的HTTPS連接對客戶端與服務器端到端之間的每個請求和響應進行加密。並且由於傳輸的數據是使用共享密鑰加密的，因此中間人（或代理）無法解密交換的數據包。當客戶端打開到安全Web服務器的SSL / TLS連接時，它將通過檢查兩個條件來驗證服務器的身份：首先，它檢查其證書是否由客戶端已知的CA簽名。其次，確保服務器的公用名（CN，也稱為主機名）與它連接的公用名匹配。如果兩個條件都成立，則客戶端將假定連接是安全的。
為了能夠嗅探到該連接，代理服務器可以充當證書頒發機構，但是，不是一個非常值得信賴的證書頒發機構：通過向實際人員或組織頒發證書，代理可以動態生成針對連接所需主機名的證書。例如，如果客戶端要連接到 https://www.facebook.com，則代理將為“ www.facebook.com”生成證書，並使用其自己的CA對其進行簽名。如果客戶端信任此CA，則上述兩個條件都為真（可信的CA，相同的CN），這意味著客戶端認為代理服務器實際上是“ www.facebook.com”。下圖顯示了此方案的請求/響應流。這種機制稱為透明HTTPS代理。
為使此攻擊有效，必須滿足一些條件：
- 代理服務器作為標準網關（HTTP和HTTPS）：對於HTTP和HTTPS代理，代理服務器當然必須能夠攔截IP數據包-這意味著它必須位於IP數據包中的某個位置。數據包路徑的方式。實現此目的的最簡單方法是將客戶端設備中的默認網關更改為代理服務器地址。
- 受信任的代理CA（僅HTTPS）：為了使HTTPS代理正常工作，客戶端必須知道（並信任！）代理CA，即必須將CA密鑰文件添加到客戶端的信任存儲中。
如果您對透明嗅探普通SSL套接字感興趣，則可以嘗試使用
SSLsplit（透明的TLS / SSL中間人代理）。攻擊SSL的方法有很多，但是您不需要偽造的SSL證書，惡意的證書頒發機構（CA）或安全專家Moxie Marlinspike的中間人SSL攻擊的變體。當您只需購買SSL攔截代理（如Blue Coat Systems的ProxySG或最近購買的Netronome SSL設備）來為您完成工作時，為什麼還要麻煩呢？
摘自ZDNet上的 Steven J. Vaughan-Nichols（摘錄）：
Blue Coat是SSL攔截業務中的大名，遠非唯一的提供SSL攔截功能並打破常規。例如，直到最近，Microsoft才會向您出售一個程序Forefront Threat Management Gateway 2010，它也可以為您完成這項工作。使用SSL攔截代理程序或設備後，實際發生的事情是：
如果您的公司正確設置了代理服務器，您將不會發現任何問題，因為它們將安排在您的計算機上將代理服務器的內部SSL證書註冊為有效證書。否則，您將收到一條彈出錯誤消息，如果單擊繼續，它將接受“偽造”數字證書。無論哪種情況，您都可以與代理建立安全連接，也可以與外部站點建立安全連接-通過代理髮送的所有內容都可以純文本格式讀取。哎呀。
是否可以從中間人生成的原始Facebook證書中分辨出來？
您可以通過告訴facebbok.com並顯示在任何可以使用證書的地方來確定@manav嗎？
@SudhanshuGaur您真的相信上述信息足以破解facebbok.com！所提供的信息是非常基礎的，而且是舊的，當今的組織安全系統在硬件和軟件加密/解密方面均遙遙領先
Rory McCune
2014-03-26 13:52:25 UTC
根據您所使用的網絡的配置，管理員可能可以查看HTTPS連接（以及VPN）的內容。
顯然可以攔截網絡上的流量，但是通常的問題是它們無法為您訪問的所有站點頒發有效的證書，因此每次您都會看到很多證書警告您訪問HTTPS站點，如果他們試圖解密流量以查看它。
但是，如果您使用的是公司提供的計算機，則他們可以安裝新的證書頒發機構，然後將其用於為您訪問的站點創建SSL證書，這樣就不會出現問題。
對於VPN來說，如果VPN不使用SSL，但是理論相同，可能會更加複雜。適用。如果您從他們控制的網絡上其他人擁有的計算機訪問Internet，則他們很可能可以訪問您輸入的任何內容。
如果您希望避免此類問題，我會使用您擁有/控制的用於訪問Internet的設備，這樣一來，如果發生SSL攔截，您應該得到警告。
Bill McGonigle
2014-03-30 08:43:06 UTC
正確，公司網絡管理員使用自己的CA對TLS客戶端實施了中間人攻擊，以便他們可以看到離開網絡的內容。他們可能會使用一種設備，該設備會在您訪問gmail.com時即時創建對gmail.com有效的證書。他們這樣做的原因不是扮演Evil博士，而是為了防止商業秘密通過互聯網連接從建築物中竄出。認真地，不要在工作計算機上進行私人銀行業務。
如果您使用的軟件產品不使用系統證書存儲（例如OpenVPN實例），那麼，否，它們將無法攔截並解碼您的流量，因為您不信任他們的CA。例如，使用Firefox便攜式應用程序可能會獲得相同的結果。並且在大多數瀏覽器中，您可以檢查安全連接的詳細信息，並查看誰是CA，以確保誰在偵聽。
Erik van Velzen
2017-03-10 05:16:09 UTC
代理可以阻止https，並且僅允許瀏覽器中的http。然後，它可以啟動自己的https連接，以將請求傳遞到服務器。
大多數用戶不會注意到。
HSTS應該可以阻止這種情況，但並未得到廣泛使用。
Danny Lieberman
2015-09-01 14:46:51 UTC
SSL終止或Bluecoat之類的SSL代理產品需要安裝在您的網絡上，並考慮成本，涉及的安裝過程以及任何組織安裝這些產品的組織所應遵循的常規安全策略-使用商業SSL的惡意攻擊者的威脅終接乘積幾乎為零。 OTOH-可以訪問NOC（網絡運營中心）的受信任內部人員實際上可以監視SSL終止的流量並洩露敏感信息。
對於實施DLP系統的公司來說，這是一個普遍的擔憂（無論是否合理）
這一切都說明了-在家庭銀行業務領域中，有另一種常見的攻擊媒介，它不需要網絡代理，並且在瀏覽器中是“背帶式” /“ shim”式攻擊-因為DOM可以訪問在文本流量到達SSL管道之前將其清除-這是一種方便的攻擊手段，通常通過瀏覽器擴展程序進行安裝。在墊片上有一篇很好的Stackexchange文章-是否可以在用戶不知情的情況下將墊片（aka polyfill）安裝在IE，FF或Chrome中，並且它可以讀取用戶在登錄頁面上輸入的密碼嗎？
ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 3.0許可。