經典愚蠢的事情做的是通過GET查詢字符串傳遞ALA一些與安全相關的信息：完整性檢查：SSL + POST與未加密的GET
http://foo?SecretFilterUsedForSecurity=username
...任何雅虎可以只使用提琴手或某些人看到發生了什麼......
然而，通過POST將此信息傳遞到應用程序服務器（運行SSL）有多安全？這從提琴手網站的鏈接似乎預示着一個可以解密HTTPS流量：
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/DecryptHTTPS
因此，這是同樣愚蠢的，如果我們的目標是確保客戶端不能捕獲/讀取信息，你更喜歡他們不是？看起來是這樣。
謝謝。
這取決於您試圖保護數據的人數以及您對客戶端軟件的控制程度。基本上，在任何客戶端 - 服務器應用程序中，客戶端必須知道它發送給服務器的內容。
如果執行得當，SSL將阻止任何中間人嗅探或更改流量，而無需修改客戶端。但是，這依賴於使用有效的證書爲服務器域加密的連接，如果不是這種情況，則客戶端拒絕採取措施。鑑於這種情況，連接只能由擁有該SSL證書私鑰的人解密。 如果您的「客戶」僅僅是一個網絡瀏覽器，這意味着第三方（例如在公共無線網絡位置）不能在沒有提醒使用該網站的人有可疑事件的情況下攔截數據。但是，它不會阻止用戶故意在瀏覽器中忽略該提示，以便自己嗅探流量。
如果你的客戶端是一個自定義二進制應用程序，對於「黑客」用戶來說事情會更安全一些：爲了檢查流量，他們必須修改客戶端以繞過你的證書檢查（例如更改目標URL或欺騙應用程序以信任僞造的證書）。
總之，沒有什麼可以完全停止確定用戶嗅探自己交通（儘管你可以使它更難），但正確實施SSL將停止第三方攔截流量。
除了「只有持有該證書的私鑰的人解密」這部分以外，這大部分都是正確的。除了建立服務器的身份之外，私鑰在通信中不起作用。 – EJP 2013-04-24 21:53:59
@EJP使用普通的RSA套件時，服務器的私鑰用於解密將從其派生會話密鑰的共享會話密鑰。所以它不僅用於驗證服務器，還用於保密。與ECDHE_RSA等適當的套件相比，這使得密鑰交換顯着減弱，其中服務器的私鑰不參與密鑰交換本身，並且僅識別服務器。 – CodesInChaos 2013-04-25 07:13:13
@EJP好的，我沒有意識到這一點。那麼更好地說「只能由具有該域的簽名證書的人攔截（用於假端點）」？ – IMSoP 2013-04-25 07:41:15
是的，它「同樣愚蠢」。 SSL僅保護數據不被第三方讀取;它不會阻止客戶端（或服務器）讀取它。如果您不信任客戶端讀取某些數據，則不應該讓他們訪問該數據，即使只是爲了製作POST。
是，任何用戶可以容易地檢查數據在POST請求中，甚至通過HTTPS/SSL，使用軟件等Burp Suite，Webscarab，或Paros Proxy。這些代理將完成與服務器的SSL交易，然後將數據傳遞給客戶端。所有通過代理傳遞的數據都存儲並且對客戶端可見。
也許您試圖在客戶端存儲敏感/祕密數據以減輕服務器的負載？要做到這一點，以便用戶無法查看（或更改它）即使是使用代理，也只能使用服務器已知的強對稱密鑰進行加密。如果你想確保加密數據不被篡改，請輸入HMAC。確保使用足夠隨機的密鑰和強大的加密算法和密鑰長度，如AES 256。
如果你這樣做，你可以卸載這些數據的存儲到客戶端，但仍然有保證，自服務器最後一次看到它沒有改變，客戶端無法看到它。
第三方只有在其中一個終端協作，出錯或CA給他們僞造密鑰時才能這樣做。問題在於OP不擔心第三方，他假設第一方，用戶想要閱讀他們自己的溝通。 – CodesInChaos 2013-04-25 07:16:37
@CodesInChaos哎呀，我的意思是說「一個用戶」，但說第三方，而不是： - 我的腦海裏想着別的東西。我會更新答案，以便更清楚。 – 2013-04-25 16:05:44
另一個更重要的原因是不要將GET機密信息添加到GET請求的URL中，Web服務器和路上的任何代理都會記錄它。 POST參數默認情況下不會被記錄。
您不希望您的密碼顯示在服務器日誌中 - 日誌通常會受到很多保護，遠遠低於密碼數據庫本身。
如果您的目標是*混淆*通信不安全*通信，那麼SSL不會幫助您。 – CodesInChaos 2013-04-25 07:09:02
如果你想要DRM，你必須在問題上儘可能多地混淆，然後祈禱沒有人能勝任攻擊它。這是不可能的。 – CodesInChaos 2013-04-25 07:14:38