SSL和TLS發展歷程
SSL/TLS的作用
OpenSSL和HTTPS分別是什麼及區別
TLS/SSL 協議通信原理
一文看懂SSL/TLS/OPENSSL/HTTPS看了上篇文章的閱讀量，我知道算法理論對運維同學太不友好了~ 所以果斷跳過算法下篇，直接介紹本次的 SSL,TLS,OPENSSL,HTTPS~ 感興趣的同學自行研究啦
話說，這4個概念都是起源了上次內容介紹的網際網路通信安全，要幾句話介紹清楚可能就別想了，做技術還是需要板凳坐穿的耐心了。so，今天的文章又是難啃的骨頭。打好預防針，我們即刻開始本次內容。
上次內容提到，網際網路安全的最終形態是數學。數學家絞盡腦汁發明了很多加密算法，但還需要程式設計師自己去寫工具寫程序去調用這些算法，才能實現數據加密。
在WEB化應用中，每家公司都自己開發，生產力不就這樣浪費了嗎，有人的地方就有江湖，所以有人出來寫了一套供大家使用，這就是開源精神嘛。
傳輸層安全協議（英語：Transport Layer Security，縮寫：TLS），及其前身安全套接層（Secure Sockets Layer，縮寫：SSL）是一種安全協議，目的是為網際網路通信，提供安全及數據完整性保障。
SSL和TLS發展歷程網際網路加密通信協議的歷史，幾乎與網際網路一樣長
SSL（Secure Sockets Layer） 是網景公司（Netscape）設計的主要用於Web的安全傳輸協議，這種協議在Web上獲得了廣泛的應用。
基礎算法由作為網景公司的首席科學家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為「SSL之父」。
1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布。1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞。1996年，SSL 3.0版問世，得到大規模應用。1999年，網際網路標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版。2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經實現了TLS 1.2的支持。
SSL/TLS的作用SSL 是洋文「Secure Sockets Layer」的縮寫，中文叫做「安全套接層」。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明了很多 Web 的基礎設施——比如「CSS 樣式表」和「JS 腳本」）
為啥要發明 SSL 這個協議捏？因為原先網際網路上使用的 HTTP 協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是為了解決這些問題。
到了1999年，SSL 因為應用廣泛，已經成為網際網路上的事實標準。IETF 就在那年把 SSL 標準化。標準化之後的名稱改為 TLS（是「Transport Layer Security」的縮寫），中文叫做「傳輸層安全協議」。
很多相關的文章都把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。
OpenSSL和HTTPS分別是什麼及區別SSL是啥？
大家知道我們訪問網站的時候，以HTTPS開頭的表示你和伺服器之間傳輸的數據經過了加密，這裡所使用的加密協議就是SSL（Secure Sockets Layer，後來又推出了它的後續版本，改名叫TLS）。也就是說，把HTTP協議經過一層SSL協議進行加密包裝，就變成了HTTPS。當然，SSL/TLS還用在很多協議中，例如VPN、加密的電子郵件協議等。
那麼OpenSSL又是啥？
在SSL協議中，我們使用了很多密碼學手段來保護數據，其中包括對稱密碼、公鑰密碼、數字籤名、證書、完整性校驗、偽隨機數生成等。由於這些算法和操作都非常複雜，於是開源社區就開發了一套庫，這個庫裡面提供了很多現成的標準方法，其他開發者只要用正確調用這些方法，就可以實現SSL協議中的各種加密/解密操作了。因此，OpenSSL是一套開源的密碼學工具包（open source cryptography toolkit）
OpenSSL 是一個強大的安全套接字層密碼庫，囊括主要的密碼算法、常用的密鑰和證書封裝管理功能及 SSL 協議，並提供豐富的應用程式供測試或其他的目的使用。
SSL層OpenSSL由三部分組成：
這4個概念了解清楚後，大頭戲才剛剛開始。
在前面的文章中，我們介紹了數據通信原理，現在在應用層和傳輸中中間夾了一層SSL，那整個通信方式有了哪些變化呢？
TLS/SSL 協議通信原理SSL會話四個階段ssl會話握手"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的 。
首先，客戶端（通常是瀏覽器）先向伺服器發出加密通信的請求，這被叫做ClientHello請求。在這一步，客戶端主要向伺服器提供以下信息。
一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。這裡需要注意的是，客戶端發送的信息之中不包括伺服器的域名。也就是說，理論上伺服器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什麼通常一臺伺服器只能有一張數字證書的原因。
對於虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向伺服器提供它所請求的域名。
伺服器收到客戶端請求後，向客戶端發出回應，這叫做SeverHello。伺服器的回應包含以下內容。
確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與伺服器支持的版本不一致，伺服器關閉加密通信。一個伺服器生成的隨機數，稍後用於生成"對話密鑰"。索要客戶端證書（非必須），銀行金融系統會需要，其它很少有網點會索取除了上面這些信息，如果伺服器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，裡面就包含了一張客戶端證書。
客戶端收到伺服器回應以後，首先驗證伺服器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。如果證書沒有問題，客戶端就會從證書中取出伺服器的公鑰。然後，向伺服器發送下面三項信息。
一個隨機數。該隨機數用伺服器公鑰加密，防止被竊聽。編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供伺服器校驗。上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以後，客戶端和伺服器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。
至於為什麼一定要用三個隨機數，來生成"會話密鑰" ，看如下解釋：
"不管是客戶端還是伺服器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。對於RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
Pre-master-key的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"
此外，如果前一步，伺服器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
伺服器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的"會話密鑰"。然後，向客戶端最後發送下面信息。
編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。至此，整個握手階段全部結束。接下來，客戶端與伺服器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。
引用官方非常經典的一幅圖，值得看10遍！
官方圖