HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport Layer Security）這兩個協議，SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發 過 SSL3.0 之前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。

IETF 以 SSL3.0 為基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 為原型開發的協議，有時會統一稱該協議 為 SSL。當前主流的版本是 SSL3.0 和 TLS1.0。

SSL 和 TLS 實際上可以理解為 TLS 是 SSL 的升級版本，TLS 基於 SSL，至於兩者的具體區別還是留給專業人士，這裡順便普及一下 SSL 和 TLS 的相關背景。

為什麼不適用HTTPS

HTTPS 由於使用了 SSL(包括 TLS) 而變得安全可靠，但是 SSL 由於要進行加密處理會導致整個通訊變慢，頻繁的加密、解密會消耗服務端和客戶端的硬體資源。

SSL 不僅會導致通訊慢，還會由於大量消耗 CPU 和記憶體等資源，導致整個處理速度變慢，和 HTTP 相比，網路負載可能可能會變慢 2 到 100 倍，如下圖所示：

為什麼不使用HTTPS

如果使用了 HTTPS，那就意味著要增加硬體成本，此外從數字認證機構購買證書也是需要開銷的。

看到答非所問，真是著急，下面是要點：

1、ssh或者https 都是使用TLS協議；

2、TLS 使用非對稱金鑰交換對稱金鑰，這個對稱金鑰是每個對話開始前隨機生成的，每次都不一樣，專業名詞叫“前向安全”。

那麼答案來了：ssh重放時，對端會要求重新協商對稱金鑰，很顯然：失敗！

看了下回答這個問題的人真少，估計大家可能經常用ssh,但是對ssh協議可能不是很瞭解。下面分享一下我對這個問題的看法：

第一，ssh協議中的傳輸協議會為為會話產生一個會話id，這個會話id可以被高層協議用於將資料和特定的會話繫結，防止之前會話資料的重放。

第二，本協議會為資料包計算mac或hmac，在計算時會將單增序號作為輸入，可有效的防止重放，這也是防止重放的慣用手段。

第三，協議中的加密演算法套件會使用cbc模式，cbc方式加密時，會傳入iv。iv每次加密完成後均會改變，也可以起到防重放作用。

當然，防重放得措施不止這些，ssh協議主要用到了以上三種。

本人具有多年的java開發經驗，熟悉多種框架，熟悉網路程式設計，熟悉java安全程式設計，熟悉大資料，熟悉多種安全協議，熟悉併發程式設計，有興趣的同學可以互相關注，互相學習！！！

SSH是一個什麼樣的存在？

SSH類似於TLS，站在TCP 埠22上，TLS站在TCP 埠443上。

所以，這兩者是平起平坐的，都可以提供安全加密服務。對SSH不熟悉的同學，可以用TLS的知識來學習SSH。

網路安全有一個經典口號，不造輪子，只使用輪子！

什麼意思呢？

私自造輪子，本來想提供安全的通訊，可是考慮不周全，引入了更多的安全漏洞，得不償失。

使用酒精考驗的輪子，經歷了全人類不斷捶打的輪子，使用起來更放心！

所以，SSH和TLS儘管名稱不同，安全的三要素是相同的套路。

SSH與TLS認證方式有一點區別，TLS採用第三方CA認證，而SSH為了簡化，沒有采用第三方的CA，而是採用雙方互相認證。

SSH公鑰認證

當客戶端與伺服器完成TCP三次握手，緊接著就是SSH雙方開始了握手協商的過程。

伺服器會將自己的公鑰以明文的方式推送給客戶端，為了避免被第三方篡改，公鑰的尾部報文還附帶伺服器私鑰的簽名保護。

客戶端獲得伺服器的公鑰，用公鑰解密簽名，可以解開，說明公鑰完好。解不開說明公鑰被篡改。

這裡有一個問題，客戶端永遠都不知道公鑰是不是伺服器的，對嗎？

伺服器出示一張名片，上面赫然寫著“馬雲”，客戶端就相信這個是馬雲了？

客戶端儘管傻，但是設計SSH人並不傻，設計人員是這麼想的。

假如客戶端與伺服器第一次通訊，是在一個安全的局域網裡，雙方如同在一個小會議室見面，然後雙方交換名片，以後雙方即使在網際網路上通訊，依然只認在小會議室交換的名片，是不是就可以避免被第三方欺騙？

重放攻擊

所謂重放攻擊，就是第三方捕獲了雙方的歷史通訊報文，在合適的時間重新發送一次或多次不等。

如何防止重放攻擊？

安全協議為了應對這個挑戰，通常會在報文頭裡嵌入一個序列號，從0開始單向增長的整數，接收方維護著一個類似TCP滑動視窗，不在視窗以內的序列號統統拋棄。即使在視窗內，也要比較接收序列號與快取的序列號是否相同，如果相同，一樣拋棄處理！