3、加密鏈結建立的核心基礎是ssl/tls的握手過程，這個過程要比tcp協議建立鏈結的3次握手過程複雜一些。參考了wikipedia中描述的過程自己大概整理了一下這個握手過程，大概是下面這個樣子的：
4、從上面的這個過程可以總結一下這個安全鏈結建立的過程：
client和server通訊為了保證安全性，所以通訊的訊息得加密，即網路上密文傳輸。為了方便對方獲得真實的訊息，這個加密得使用對稱加密演算法。於是，這個加密的安全性就取決於金鑰本身的強度以及所選用的對稱加密演算法了。
可是到底用什麼金鑰和對稱加密演算法呢？client和server互不認識，怎麼會有默契上來就知道這兩個東東都用啥？於是這事兒得client和server談判！
client給server傳送了個clienthello，裡面包括：client能支援的tls的最高版本、乙個隨機數a、client所能支援的加密演算法集合、client所能支援的壓縮演算法集合。
server收到個clienthello之後，拿出自己所能支援的tls的最高版本跟client發過來的最高版本比較一下，這兩個版本取個max，這裡標記為：max_tls_version。server自己再生成個隨機數b，從client傳過來的加密演算法集合中挑乙個具體的加密演算法m（注意，這裡的m其實也是乙個集合，包括：非對稱加密演算法用於加密上圖的pre-master secret，比如rsa演算法、對稱加密演算法用於資料傳輸時雙方使用的加密自己的內容解密對方內容的依據、mac演算法用於校驗資訊是否被篡改、偽隨機演算法用於生成最終通訊時對稱加密演算法所需要的金鑰master secret），從壓縮演算法集合中挑乙個具體的壓縮演算法n。然後傳送乙個serverhello作為回應給client，這個serverhello就包括上面提到的max_tls_version/b/m/n。
注意，這時client和server雙方之間的資訊基本比較對稱了。因為雙方已經協商好整個握手過程中所有可能需要涉及到的演算法。
server傳送自己經過第三方認證的證書給client，告訴他：哥是有證經營的，你可以拿我的證去隨便調查。
client拿著server發過來的證書跑去權威的有關部門驗證去了。。。（這兩步涉及到的ca證書認證內容又很大，這裡不展開描述，先將主要精力放在tls握手上）
假設上面的證書驗證通過了，這就意味著client相信server發過來的證書了，也就意味著client同意用server發過來的public key開始通訊了。注意，非對稱加密的過程在這裡開始了。client生成了乙個pre-master secret（通常也是乙個隨機數）p，使用server提供的public key加密p之後生成p'， 將p'發給了server。
server收到p'後，用自己的private key解密還原出了p。注意這個p和之前a的最大不同是加密傳輸過來的哦。而且理論上在server沒有洩露自己private key的情況下， 只有server能夠從p'還原出p。so，此時，client和server雙方已經具備了生成雙方後面通訊時對稱加密需要使用的master secret的條件：雙方都有的乙個確定的偽隨機函式、3個彼此都知道的隨機數a、b和p。
於是，雙方在自己一方，通過共同的偽隨機數和共同的素材，生成出來了master secret。到這裡，雙方談判的過程基本上可以結束了。因為談判的初衷已經完全符合了。回想一下，整個過程不就是為了在公網上這個非安全的環境中讓彼此都清楚使用啥對稱加密演算法以及使用什麼金鑰嗎？等等，這個握手過程為了保證可用性，還拿出來先測試一下，是否真的行得通才行啊。於是還有下面的兩步。
client用雙方同意的mac（message authentication code）演算法，比如md5，加密一段明文q（這個明文是啥應該都沒關係，因為都會發給server的）生成了mac。然後用雙方同意的對稱加密演算法（比如aes）加密了q和mac之後，生成了一段finished message發給了server。（這裡，根據tls record protocol，這個finished message其實是個具體的tls record，他攜帶的content type為20，這相當於告訴server：i am ready to begin the normal communication.）
server收到這條tls record之後，就會嘗試先解密密文（decryption），再用約定的mac演算法驗證內容是否被篡改（verification）。這時，如果這兩個任何一項工作失敗了，就前功盡棄了。。。這裡假設都成功了，於是server做了上一步client同樣的事情：生成乙份content type為20的finished message，發給client。至此，整個握手過程正式結束。。。下面的通訊就是雙方直接使用對稱加密演算法直接加解密message的過程啦，當然每次互動的過程中，還會包括上面描述的mac驗證的過程
Https協議原理
對稱加密 加密和解密同用乙個金鑰 非對稱加密 公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰，另一把叫做公開金鑰 使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰進行解密 tls ssl 其利用非對稱加密實現身份認證和金鑰協商，對稱...
Https協議原理總結
文章是根據中科大郭燕老師的資訊保安實踐課程的lecture1 https的內容外加自己的理解改寫的。眾所周知，http協議存在非常大的安全隱患，首先它在網路上傳輸明文，這樣導致其傳輸的內容非常容易在網路上被人竊聽 其次，它無法給伺服器或者客戶端提供有效的身份認證手段。因此而誕生了https協議彌補這...
HTTPS傳輸協議原理介紹
我們常常在使用網上銀行時看到的連線都是以 https 開始的，那麼這個https是什麼呢？這其實是表示目前連線使用了ssl進行加密，能保證客戶端到伺服器端的通訊都在被保護起 來，那麼瀏覽器是如果實現的呢？下面我們介紹一下ssl的基本實現方法。首先我們有兩種基本的加解密演算法型別 對稱加密，非對稱加密...