如何查看伺服器的tls版本

① 鍚鐢ㄤ簡SSL 3.0,TLS 1.0,TLS 1.1 鍜 TLS 1.2榪樻槸鏃犳硶鏄劇ず緗戦〉鎬庝箞鍔

闇瑕佸紑鍚闃茬伀澧443絝鍙鏉ヨВ鍐抽棶棰橈紝鏂規硶濡備笅錛

1銆侀栧厛錛屽崟鍑昏＄畻鏈轟笂鐨勫惎鍔ㄧ晫闈錛岀劧鍚庡崟鍑鎺у埗闈㈡澘閫夐」錛屽備笅鍥炬墍紺猴紝鐒跺悗榪涘叆涓嬩竴姝ャ

② 用WireShark簡單看看SSL/TLS協議

HTTPS目前是網站標配，否則瀏覽器會提示鏈接不安全，同HTTP相比比，HTTPS提供安全通信，具體原因是多了個「S」層，或者說SSL層[Secure Sockets Layer]，現在一般都是TLS[Transport Layer Security]，它是HTTP 明文 通信變成安全 加密通信 的基礎，SSL/TLS介於應用層和TCP層之間，從應用層數據進行加密再傳輸。安全的核心就在加密上：

如上圖所示，HTTP明文通信經中間路由最終發送給對方，如果中間某個路由節點抓取了數據，就可以直接看到通信內容，甚至可以篡改後，路由給目標對象，如下：

可見HTTP傳輸是不安全的，但，如果傳輸的是只有雙方可校驗的密文，就可以避免被偷竊、篡改，保證傳輸的安全性，這就是SSL/TLS層做的事情。

SSL/TLS協議主要從三方面來保證數據傳輸的安全性：保密、鑒別、完整：

對用戶端而言：怎麼保證訪問的網站就是目標網站？答案就是 證書 。每個HTTPS網站都需要TLS證書，在數據傳輸開始前，服務端先將證書下發到用戶端，由用戶根據證書判斷是否是目標網站。這其中的原理是什麼，證書又是如何標識網站的有效性呢？證書也叫 digital certificate 或者public key certificate，是密碼學中的概念，在TLS中就是指CA證書【 由證書的簽發機構（Certificate Authority，簡稱為 CA）頒布的證書 】，好比是權威部門的公章，WIKI網路解釋如下：

大意就是證書包含了目標站點的身份信息，並可以通過某種方式校驗其合法性，對於任何一個HTTPS網站，你都可以拿到其CA證書公鑰信息，在Chrome瀏覽器中點擊HTTPS網站的鎖標志，就可以查看公鑰信息，並可以導出CA二進制文件：

瀏覽器就是通過這個文件來校驗網站是否安全合法，可以看到，證書其實內置了一個頒發鏈條關系，根證書機構->次級證書機構->次次級->網站自身，只要驗證這個鏈條是安全的，就證明網站合法，背後的技術其實是 信任鏈+RSA的非對稱加密+系統內置根證書 。CA在頒發證書的時候，會用自己的私鑰計算出要頒發證書的簽名，其公鑰是公開的，只要簽名可被公鑰驗證就說明該證書是由該CA頒發的，核心校驗邏輯如下

那麼上級的CA又是如何保證安全呢？重復上述操作即可，最終都是靠根證書來驗證的，根證書的安全性不需要驗證，由系統保證，如此就形成了一個證書的信任鏈，也就能驗證當前網站證書的有效性，證書的信任鏈校驗如下：

TLS協議最大的提升點就是數據的安全，通HTTP通信相比，HTTPS的通信是加密的，在協商階段，通過非對稱加密確定對稱加密使用的秘鑰，之後利用對稱秘鑰進行加密通信，這樣傳輸的數據就是密文，就算中間節點泄漏，也可以保證數據不被竊取，從而保證通信數據的安全性。

第三個問題，雖然中間節點無法竊取數據，但是還是可以隨意更改數據的，那麼怎麼保證數據的完整性呢，這個其實任何數據傳輸中都會有這個問題，通過MAC[Message Authentication Codes]信息摘要演算法就可以解決這個問題，同普通MD5、SHA等對比，MAC消息的散列加入了秘鑰的概念，更加安全，是MD5和SHA演算法的升級版，可以認為TLS完整性是數據保密性延伸，接下來就藉助WireShark看看TLS握手的過程，並看看是如何實現身份鑒別、保密性、完整性的。

HTTPS安全通信簡化來說： 在協商階段用非對稱加密協商好通信的對稱秘鑰 ，然後 用對稱秘鑰加密進行數據通信 ，簡易的WireShark TLS/SSL協商過程示意如下：

細化分離後示意如下：

握手分多個階段，不過一次握手可以完成多個動作，而且也並不是所有類型的握手都是上述模型，因為協商對稱秘鑰的演算法不止一種，所以握手的具體操作也並非一成不變，比如RSA就比ECDHE要簡單的多，目前主流使用的都是ECDHE，具體流程拆分如下：

Client Hello是TLS/SSL握手發起的第一個動作，類似TCP的SYN，Client Hello 階段客戶端會指定版本，隨機數、支持的密碼套件供服務端選擇，具體的包數據如下

啟動TLS握手過程， 提供自己所能支持各種演算法，同時提供一個將來所能用到的隨機數 。

ContentType指示TLS通信處於哪個階段階段，值22代表Handshake，握手階段，Version是TLS的版本1.2，在握手階段，後面鏈接的就是握手協議，這里是Client Hello，值是1，同時還會創建一個隨機數random給Server，它會在生成session key【對稱密鑰】時使用。之後就是支持的供服務端選擇的密碼套件，接下來等服務端返回。

Handshake Type: Server Hello (2)，作為對Client Hello的響應 ， 確定使用的加密套件 : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密鑰協商使用 ECDHE，簽名使用 RSA，
數據通信通信使用 AES 對稱加密，並且密鑰長度是128位，GCM分組，同時生成一個服務端的random及會話ID回傳。

這一步伺服器將配置的證書【鏈】發送給客戶端，客戶端基於上文所述的證書鏈校驗證書的有效性，這里發送的證書是二進制格，可以利用wireshark右鍵「Export Packet Bytes」功能，導出.CER格式的證書。如下可以看到傳輸的證書鏈。

導出的CER格式的證書如下，最關鍵的就其公鑰跟數字簽名。

Server Key Exchange是針對選定的ECDHE協商所必須的步驟，Diffie-Hellman模型解釋如下：

大意就是ephemeral Diffie-Hellman不會使用證書中的靜態公鑰參與對稱秘鑰的生成，而是需要服務端與客戶端通過彼此協商確定對稱秘鑰，而D-H演算法模型需要兩對非對稱秘鑰對，各端保留自己的私鑰，同時握有雙方的公鑰，然後基於D-H演算法雙端可以算出一樣的對稱加密秘鑰，而這就需要C/S互傳自己的公鑰

服務端做完這一步，其實ECDHE演算法中服務端需要提供的信息已經結束，發送 Server Hello Done告訴客戶端，然後等待客戶端回傳它的D-H公鑰。

演算法：

其中p和g是公開的DH參數，只要P是一個足夠大的數，在不知道私鑰的情況下，即使截獲了雙方的公鑰，也是很難破解的。

客戶端收到服務端的證書後，利用信任鏈檢測證書有效性，同時也會同Server Key Exchange 類似，將自己的Diffie-Hellman公鑰發送給Server端，

至此，ECDHE協商所需要的信息都傳輸完畢， 雙方都可以基於ECDHE演算法算出的共享密鑰，同時結合之前的隨機數生成最終的對稱加密秘鑰：

之後客戶端發送Change Cipher Spec與 Encrypted Handshake Message標識握手完成，同時傳輸一個加密的數據給Server，驗證雙方確立的秘鑰是否正確，這就需要服務端也要重復這個操作給客戶端，這樣才能驗證彼此的加解密一致，即服務端也要來一次Encrypted Handshake Message回傳給客戶端校驗，

走完如上流程，雙方就確認了正確的對稱加密通道，後面就是TLS的數據通信，其Record Layer的ContentType 也會變成 Content Type: Application Data (23)：

最終對稱會話密鑰包含三部分因子：

Client Hello與Server Hello階段交換的隨機數，是為了提高秘鑰的「隨機」程度而進行的，這樣有助於提高會話密鑰破解難度。

HTTPS通過加密與完整性校驗可以防止數據包破解與篡改，但對於主動授信的抓包操作是沒法防護，比如Charles抓包，在這個場景用戶已經風險，並且將Charles提供的證書信任為根證書，這從源頭上構建了一條虛擬的信任鏈：在握手階段，Charles利用自己的公鑰，生成客戶端可以信任的篡改證書，從而可以充作中間人進而抓包，所謂中間人攻擊，感覺跟Https抓包原理一樣，都是要強制添加一個自己的信任根證書。

③ linux如何配置openssh文件，支持TLS1.1 1.2

TLS全稱為：Transport Layer Security——安全傳輸層協議，用於在兩個通信應用程序之間提供保密性和數據完整性。TLS 1. 0 和TLS 1. 1 是分別於 1996 年和2006年發布的老版協議，使用的是弱加密演算法和系統。比如SHA-1和MD5，這些演算法和系統十分脆弱，存在重大安全漏洞，容易受到降級攻擊的嚴重影響，而在 2008 年和 2017 年分別發布了協議的新版本，分為TLS 1. 2 和TLS 1.3，無疑更優於舊版本，使用起來也更安全。網路搜索《Linux就該這么學》一起來學習。

1，Chrome、Firefox等瀏覽器最新版本升級後，不在支持 TLS 1. 0 和TLS 1. 1。 如果使用的網站上貼上標簽，在URL地址欄和鎖定圖標顯示「不安全」標識，暗示用戶HTTPS連接並不像他們想像的那樣安全。

2，目前北金所部分系統使用的是低版本協議，存在重大安全漏洞，容易受到降級攻擊的嚴重影響。

操作：

1，伺服器安裝部署SSL證書的，只要開啟支持TLS 1.2或以上版本的加密協議即可。nginx開啟如下圖:

ssl_ciphers 填自己的加密方式;