了解SSL的作用和不起作用是很重要的，尤其是因為這是很常見的誤解來源。

• 它加密通道
• 它應用完整性檢查
• 它提供身份驗證

所以，快速答案應該是：“是的，它足以傳輸敏感數據”。但是，事情並不是那麼簡單。

• SSL的最新版本-版本3或更高版本：TLS（甚至TLS 1.2）絕對比以前的版本更好。例如。 SSL 2對MITM來說相對容易（中間是男人）。因此，首先取決於協議版本。
• 通道加密和完整性檢查均可在協議中配置，即，您可以選擇要使用的算法（密碼套件）。顯然，如果您使用的是RSA1024 / SHA512，您的處境會更加好...但是，SSL甚至支持NULL加密模式-即完全不加密，只需將請求打包到SSL協議的隧道中即可。即，沒有保護。 （這可以在客戶端和服務器上進行配置，所選密碼套件是根據配置順序的第一個匹配集）。
• SSL中的身份驗證有兩種模式：僅服務器身份驗證和相互身份驗證（客戶端證書）。在這兩種情況下，加密證書所保證的安全性絕對足夠強，但是實際身份驗證的有效性僅與有效性檢查一樣好：您是否還要檢查證書？您確保其有效性嗎？信任鏈？誰發行的？等等
• 在Web 應用中，最後一點的重新身份驗證要容易得多，其中客戶端可以輕鬆查看服務器證書，可以輕鬆查看鎖定圖標，等等。使用Web 服務，通常需要更明確地檢查其有效性（取決於您選擇的平台）。請注意，同一點已經使許多移動應用程序崩潰-即使應用程序開發人員記得在電話和服務器之間僅使用TLS，如果該應用程序未明確驗證證書，則TLS被破壞。
• 儘管從SSL的角度來看，對SSL密碼學的攻擊主要是理論上的，但它仍然足夠強大，幾乎可以用於所有目的，而且將持續很長時間。
• 另一端的數據實際上是做什麼的？例如。如果它的數據非常敏感，甚至是信用卡數據，則您不希望它在瀏覽器的緩存或歷史記錄等中出現。
• 可以在安全的SSL通道之間共享Cookie（因此可以進行身份驗證），並且一個非安全的HTTP通道-除非明確標記為“安全”屬性。是的，SSL 足夠安全，但是（與大多數情況一樣）它取決於您的使用方式。 ：）

這裡有一些問題，主要是身份驗證。兩端都需要確保他們正在與合適的人或機構交談，以阻止中間人攻擊。在您的終端上，至關重要的是，使用用戶瀏覽器信任的SSL證書。通過這樣做，用戶的瀏覽器可以確保它確實在與正確的站點通信。建立連接後，您可以確保一直與該用戶通話，並且連接已加密，即可以防止竊聽。

另一個方向上的身份驗證（即確保您正在與真實用戶交談）通常在應用程序級別的SSL協議之外通過用戶名/密碼，openID或某種其他形式的身份驗證進行處理。證書。

最後一點應提到的是，在SSL連接握手期間，客戶端和服務器同意 Cipher套件，並且客戶端可以假裝僅執行“空加密”，即，不加密任何數據。如果您的服務器同意該選項，則連接使用SSL，但是數據仍未加密。實際上這不是問題，因為服務器實現通常不提供空密碼作為選擇。

除了AviD列出的內容外，SSL的安全性還與將您定向到該服務器的DNS基礎結構以及通信路徑中的所有公司代理一樣安全。

如果DNS基礎結構被黑了（緩存中毒等），那麼攻擊者可能會使您的用戶遭受許多攻擊。

此外，如果客戶端正在使用像 Fiddler這樣的軟件或公司代理，該軟件可以easvdrop進行SSL對話。

為減輕這種情況，請查看SSL證書的“發行者”。如果SSL連接通過代理進行，則發行者將是代理的。如果通過直接連接，則將看到相關的公共信任的CA。

[更多信息]

企業HTTPS代理是用於管理Web瀏覽器與代理服務器之間連接的工具（其IP地址顯示在Web服務器日誌中）。在這種情況下，Web內容（也是HTTPS密碼）將被解密，然後在公司代理處重新加密並呈現給您的服務器。

取決於誰在管理代理以及如何使用其日誌，從您的角度來看，這可能是可接受的，也可能是壞事。

有關如何進行SSL攔截的更多信息，請參見以下鏈接：

當SSL代理攔截SSL連接時，它將向客戶端瀏覽器提供模擬的服務器證書。客戶端瀏覽器向最終用戶發出安全彈出窗口，因為該瀏覽器不信任ProxySG使用的發行者。如果SSL代理使用的頒發者證書作為客戶端瀏覽器的證書存儲區中的受信任根導入，則不會出現此彈出窗口。

ProxySG使所有配置的證書都可以通過其管理控制台下載。您可以要求最終用戶通過Internet Explorer或Firefox下載頒發者證書，並將其作為受信任的CA安裝在他們選擇的瀏覽器中。這消除了證書彈出窗口 仿真證書...

一些公司通過將GPO的根證書（代理服務器）部署到每個工作站來解決上述證書彈出問題。儘管這只會影響使用Microsoft證書存儲的軟件。 Firefox和Chrome之類的軟件需要進行不同的更新。

由於SSL依賴於證書頒發機構（CA），並且基本上任何組織都可以成為CA，因此使用偽造但由CA簽名的證書的中間人攻擊始終是可能的。因此，儘管SSL相對於完全不加密仍是一個巨大的改進，但由於CA系統損壞，其安全性被高估了。在這方面，自簽名證書與任何CA簽名證書一樣安全，但是瀏覽器將其標記為可疑。

SSL非常安全，儘管如果您在未加密的行上運行ANY頁面，則有人可以竊取其會話cookie。如果可以的話，我將使站點成為全SSL。或者可能使cookie僅發送加密連接，並且具有不特定於該用戶的不安全公共頁面。

仍有中間人攻擊的可能性，在您的情況下，這是用戶連接到聲稱是您的站點的第三方，然後轉發請求。當然，精明的用戶應該注意到缺少SSL連接或證書錯誤，但是大多數用戶並沒有打開電源並被掛鎖圖標欺騙。

這不是SSL真正的問題本身，只是需要注意的事情。您可以放心地假設，沒有人能夠竊聽您的站點和連接源之間的SSL連接。但是，您不能確保連接的來源確實是用戶。

由於SSL會加密傳輸，因此無法竊聽數據（因為證書是受信任的）。

問題出在您在Web應用程序中使用SSL的位置（和使用數量）：例如，您只需要SSL連接就可以驗證您的用戶身份（讓他們將加密的用戶/密碼對發送給您的服務器），那麼當您發送回cookie時，您應該意識到它很容易被攔截（例如您的用戶處於不受保護的無線連接上。）

最近的FireSheep電視劇就是關於此的。

不。 流量分析仍然可以告訴別人很多東西。

流量分析是攔截和檢查消息以從通信模式中推斷出信息的過程。即使消息已加密且無法解密，也可以執行此操作。通常，觀察到的消息數量越多，甚至被攔截和存儲的消息數量越多，可以從流量中推斷出更多信息。

TLS通常用於保護機密性-攻擊者對通信的內容不應抱有高度的信心。

假設，

1. 攻擊者知道您的協議，
2. 攻擊者知道攻擊者無法與誰通信。
3. 攻擊者無法解密消息。
4. 您不會在大量無意義的流量（chaff）中掩蓋真實流量
ol>

無論使用哪種協議，攻擊者都可能會告訴您什麼時候醒著，什麼時候睡著了，並且取決於所使用協議的性質，攻擊者可能還可以提供更多信息。

---

如果您的協議非常簡單：

1. 當您要發射核武器時，您會發送一條消息“在...處發射核武器”
2. 您不會發送當您不想發射任何核武器時會顯示一條消息。
ol>

無法解密您的數據的竊聽者c

---

如果您的協議較為複雜，則由您是否希望向其發射核武器的消息來確定。

---

3. 我將內容髮送給您。
ol>

攻擊者可能無法分辨誰正在閱讀“戰爭與和平”與“ Atlas聳了聳肩”，但是可以完全根據消息的大小來區分他們是在閱讀前者還是卡夫卡55頁小說《變形記》中的一本。

SSL執行兩項基本任務：身份驗證和加密。

身份驗證是通過證書頒發機構（CA）進行的。瀏覽器隨附用於CA簽名密鑰的SSL證書列表。 CA簽署描述實體公鑰的證書。例如，如果我擁有Google.com，我將向Verisign證明這一點，他們將在一段時間內簽署我的證書。 CA出現的問題會簽署他們不應該簽署的證書。當有人假裝擁有另一個域，獲取的通配符證書範圍太廣，或者只是普通的 XKCD CA簽發了一些邪惡的東西（可能是政府）時，就會發生這種情況。我們已經看到了上述所有情況的實例，但是這種情況很少見。

如果網站的證書已正確簽名，並且信任鏈中不存在任何假證書，那麼當您連接到您可以（出於討論目的）在站點上確信證書匹配。通常情況下，該連接是加密的。這會阻止任何人讀取您的數據。

SSL證書非常複雜，並且存在許多針對SSL實現的攻擊。 SSL可以有效地做的是，當您在GMail上檢查電子郵件時，阻止我查看本地星巴克的流量。它不能做的是阻止我使用MITM攻擊，在這種情況下，我無需SSL就將所有內容中繼給您，並且沒有設置您的客戶端來困擾您從未啟動加密會話的事實。

假設您使用的是SSL 3.0和強加密，則不計算其他人關於其他潛在問題的各種答案。

使用較舊的ssl協議（2.0）或使用弱加密密鑰可能會使您面臨漏洞。

SSL通常通過提供以下內容來提高安全性：

1. 服務器身份驗證（用戶知道他們正在與“正確的”站點對話）
2. 數據完整性（用戶和服務器）
3. （可選，但通常是）知道數據在途中未被修改）（用戶和服務器知道在途中未攔截到流量）
4. （可選（但很少見）客戶端身份驗證，如果客戶端也有證書
ol>

本質上只有兩種類型的SSL證書，即服務器證書（始終涉及）和客戶端證書（其中是可選的）。

這只是一個草圖，並且有許多if，ands和buts。在最典型的情況下，即基於瀏覽器的SSL，該方案在很多情況下都可以破壞而不會破壞密碼或協議，而只是依靠用戶執行錯誤的操作（即忽略瀏覽器警告並以任何方式連接）。網絡釣魚攻擊也可以通過將用戶發送到偽造的受SSL保護的站點而起作用，該站點在各個方面都類似於真實的URL站點。

說過，SSL及其表親TLS仍然非常有用。它們至少允許安全的通信，儘管遠非萬無一失。

當有人使用SSL（https）連接到我們的服務並提交了正確的身份驗證數據時，通過此行傳輸所有敏感數據是否安全？或者是否仍然存在竊聽行為？

該鏈中的薄弱環節幾乎可以肯定不是SSL，而是用戶，通常可以誘騙用戶通過Web欺騙/超鏈接欺騙或通過提供無效的證書來連接到偽造的中間站點。消除瀏覽器警告並繼續進行連接。

無論如何，您所描述的系統都是最佳實踐，您無能為力（除了教育您的用戶認真對待SSL警告外）。

當您不使用SSL時，可以很容易地攔截所有通信-唯一需要做的就是啟動數據包嗅探器（即Wireshark）。
SSL可以防止所有數據包都被加密，因此無法知道您要發送的內容。基本上，它用於保護密碼和私人內容免遭攔截。您顯然不希望其他人閱讀您的私人電子郵件，對嗎？
對於Google搜索，他們只是為了隱藏人們的要求而已。這是因為一些政府對此太好奇了。

SSL如何提高安全性？它本身不是。加密（SSL密鑰）和PKI（公共密鑰基礎結構）的組合-主要是證書。好，問題是如何。一方面，它確保了您的通信渠道的安全（請參見上文），另一方面，它確保了您與合法企業的交流-認證服務器。因此，該通道是安全且受信任的。

有許多SSL證書，因為有許多 PKI服務。基本上，不同的服務需要不同類型的SSL證書。因此，有用於代碼簽名，電子郵件加密和簽名的證書，以及有關服務器身份驗證的證書，等等。

簡短答案不是。更長的答案：上面答案的集合加上：如果我們解決了身份驗證問題，那麼中間人就可以使用傳統的SSL connectyion somone列出流量，如果以後可以解密它他們獲得了服務器密鑰（例如NSA和National Security Letters）。TLS協議中有一個選項可以使用Diffie-Helman協議來確保鏈接的機密性。當我使用Chrome訪問gmail.com時，請參見下圖。

查看帶有SHA1的文本RC4_128，以進行消息認證ECDHE_ECDSA。內容為：

1. 服務器提供了具有SHA摘要的SSL通道RC4_128b
2. 在此隧道內，每條消息均使用黃道曲線加密，其中密鑰使用Diffie-Helman函數導出，並且換句話說，即使有人擁有SSL服務器的私鑰，消息也會被臨時密鑰加密，並在之後不久將其從內存中丟棄使用。 NSA祝你好運！

@Vladimir認為 http://en.wikipedia.org/wiki/Forward_secrecy是正確的，但細節有誤。服務器從瀏覽器提供的中選擇該密碼套件。 “使用SHA1的RC4_128加密進行消息身份驗證”確實使用RC4 128位加密和HMAC-SHA-1完整性檢查。 （直到最近才使用SSL / TLS的密碼套件名稱說SHA，但它們的意思是SHA-1，實際上是HMAC-SHA-1。）“ ECDHE_ECDSA作為密鑰交換機制”不適用於單個消息，它是（大部分）在會話開始時發生一次握手：ECDHE在臨時模式下使用Diffie-Hellman的Elliptic Curve變體（加上一些此處不重要的附加步驟）來創建用於加密和HMAC的會話 key ;而ECDHE密鑰交換（僅）由“數字簽名算法”的“橢圓曲線”變體簽名。 （您永遠不能使用DH或ECDH直接加密任何東西，它們只會做密鑰或其他小秘密協議。）

對用戶安全還是對您安全？假設發生中間人攻擊。攻擊者設法捕獲用戶的流量，冒充您成為用戶，並冒充您。這種攻擊通常會失敗，因為提供給用戶的證書將不正確。例如，攻擊者為用戶提供了您網站的自簽名證書。但是，如果用戶愚蠢的行為，他們可能會接受該自簽名證書。因此，現在攻擊者可以讀取和修改用戶與您之間的所有流量，據我所知，您無法檢測到此流量。

因此，如果偵聽和修改流量傷害了用戶，那實際上是他們自己的錯，也是他們自己的問題。而且您也無法完全阻止它，因為MITM可以完全切斷您的權限，而只是與假裝自己的用戶交談。但是，如果偵聽和更改流量會傷害您，那麼您必須信任用戶不要愚蠢，或者更好地對用戶進行身份驗證（用戶將需要證書，並且可以通過MITM不能進行的方式進行檢查假）。

我認為這裡的人不明白這個問題：

如果您的線路不安全，並且通過此線路成功建立了SSH / SSL連接，他現在會問是否可以安全地進行假設該行是“安全的”，並且未加密的數據可以與加密的連接（例如，在普通情況下，不在加密的SSL / SSH連接內部）一起傳遞。

我會拒絕。在這種情況下，可能會有一個被動的竊聽者，它會忽略加密的數據並保存未加密的數據。

但是您可以確定沒有主動的竊聽器（MITM），這意味著您可以安全地建立未經身份驗證的SSL / SSH連接具有與已驗證行相同的源/目標。這沒有提供MITM某些連接器的選擇性竊聽器，但是，竊聽者無法知道您是否要驗證連接，因此他不知道要與MITM進行哪個連接逃避檢測。如果他是MITM，則MITMer將會是MITM所有連接，並希望人們簡單地單擊所有身份驗證對話框。

因此：如果您將經過身份驗證的SSL連接從123.123.123.123更改為24.24.24.24，則您只要您可以信任對方NAT路由器或防火牆後面的所有內容，就可以安全地將SSH客戶端從123.123.123.123連接到24.24.24.24，而無需相互驗證SSH指紋。

但是即使那通常是安全的，也意味著，竊聽者只是隨機地將MITM連接隨機化並希望不被發現的可能性很小，因此，既然您已經具有到目標IP的經過身份驗證的連接，為什麼不使用該經過身份驗證的連接來相互驗證SSH指紋？只需在SSL安全的網站上發布正確的SSH指紋即可！