Https其實就是在TLS之上的http協(xié)議纵朋，所以各種頭信息以及數(shù)據(jù)格式和http其實都一樣，主要區(qū)別就在TLS，下面我們來看看TLS是如何工作的（建議用電腦查看圖片）滓鸠。

TLS 握手

訪問百度拾碌，并用wireshark 抓包吐葱。看一下具體的流程：

下面是幾個重要過程的數(shù)據(jù)包

Client Hello

1. 客戶端支持的TLS協(xié)議版本校翔，這里會有一個list弟跑，目前主流的是TLS1.2。
2. 一個隨機數(shù)防症，我們記為CR孟辑，具體的作用是用來生成對話密鑰，我們稍后會用到蔫敲。
3. 支持的加密方法套件饲嗽。
4. 支持的壓縮方法。
5. 擴展信息奈嘿。擴展信息會有非常多貌虾，類似時間戳，域名等等信息裙犹，具體的可以參看RFC文檔尽狠。

    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 196
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 192
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: Sep 17, 2001 11:39:28.000000000 HKT
                Random Bytes: bc19ae324b40e089aa93497dc631b11e9ac623631eba8c2e...
/*
     Session Id。跟SSO的cookie的概念有點類似伯诬，就是當你這次握手成功之后晚唇，
     下次直接帶上這個session Id，如果服務端認為合法盗似，那么就不用再進行握手哩陕，
     直接可以開始用之前已經(jīng)商量好的對稱加密密鑰開始通信了。
*/
            Session ID Length: 0 
            Cipher Suites Length: 28
            Cipher Suites (14 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 123
            Extension: Unknown 31354
            Extension: renegotiation_info
            Extension: server_name
                Type: server_name (0x0000)
                Length: 18
                Server Name Indication extension
                    Server Name list length: 16
                    Server Name Type: host_name (0)
                    Server Name length: 13
                    Server Name: www.baidu.com
            Extension: Extended Master Secret
            Extension: SessionTicket TLS
            Extension: signature_algorithms
/*
     服務端設置了`status_request`的應答標志位，答應客戶端會直接返回服務端證  書的OCSP校驗結(jié)果悍及。
*/
            Extension: status_request
                Type: status_request (0x0005)
                Length: 5
                Certificate Status Type: OCSP (1)
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: signed_certificate_timestamp
            Extension: Application Layer Protocol Negotiation
            Extension: channel_id
            Extension: ec_point_formats
            Extension: elliptic_curves
            Extension: Unknown 27242

Server Hello

1. 確認TLS協(xié)議的版本闽瓢，如果客戶端的協(xié)議服務端不支持的話，服務端會選擇關(guān)閉這個連接心赶。
2. 從客戶端支持的加密方法中扣讼，選擇一個加密方式，并告知客戶端缨叫。
3. 生成一個隨機數(shù)椭符，我們記為SR，后續(xù)我們會結(jié)合CR生成對話密鑰耻姥，稍后會用到销钝。
4. 從客戶端支持的壓縮算法中，選擇一個壓縮算法琐簇。

    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 63
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 59
            Version: TLS 1.2 (0x0303)
            Random
                GMT Unix Time: Jul 13, 2017 17:36:48.000000000 HKT
                Random Bytes: 604b936787061df57c30ab5a30ab5e72f960975f8c91fc81...
            Session ID Length: 0
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Compression Method: null (0)
            Extensions Length: 19
            Extension: SessionTicket TLS
                Type: SessionTicket TLS (0x0023)
                Length: 0
                Data (0 bytes)
            Extension: Application Layer Protocol Negotiation
                Type: Application Layer Protocol Negotiation (0x0010)
                Length: 11
                ALPN Extension Length: 9
                ALPN Protocol
                    ALPN string length: 8
                    ALPN Next Protocol: http/1.1

Certificate

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Certificate
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 2894
        Handshake Protocol: Certificate
            Handshake Type: Certificate (11)
            Length: 2890
            Certificates Length: 2887
            Certificates (2887 bytes)
                Certificate Length: 1748
                Certificate: 308206d0308205b8a003020102020c18da1aafdb3d41309f... (id-at-commonName=baidu.com,id-at-organizationName=BeiJing Baidu Netcom Science Technology ,id-at-organizationalUnitName=service operation department.,id-at-localityName=beij
                    signedCertificate
                    algorithmIdentifier (sha256WithRSAEncryption)
                    Padding: 0
                    encrypted: 4b73ec2dd7ecca08f39dbd9554b100225948299248108d31...
                Certificate Length: 1133
                Certificate: 3082046930820351a003020102020b040000000001444ef0... (id-at-commonName=GlobalSign Organization Validation CA - SHA256,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE)
                    signedCertificate
                    algorithmIdentifier (sha256WithRSAEncryption)
                    Padding: 0
                    encrypted: 462aee5ebdae0160373111867174b64649c81016fe2f6223...

Server Key Exchange

這一步也是可選的蒸健，取決于雙方的加密方法，這里就不得不提到TLS的兩種密鑰協(xié)商方式：

• TLS_RSA_XXXX婉商。這類算法里面似忧，RSA的作用是Key Transmission
  ，也就是說對稱加密的密鑰是由客戶端生成丈秩，然后通過證書里面的公鑰加密發(fā)送給服務端盯捌。如果采用的是RSA算法，那么這一步就不需要了癣籽。
• TLS_DHE_XXXX挽唉。這類算法里面，使用DH算法進行密鑰協(xié)商筷狼，DH的作用就是Key Exchange瓶籽，密鑰是由客戶端和服務端共同生成的。

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 333
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 329
            EC Diffie-Hellman Server Params
                Curve Type: named_curve (0x03)
                Named Curve: secp256r1 (0x0017)
                Pubkey Length: 65
                Pubkey: 04fae2fd600115cd62361d34ed6c6d9b7bda6c9e6517ad1f...
                Signature Hash Algorithm: 0x0401
                    Signature Hash Algorithm Hash: SHA256 (4)
                    Signature Hash Algorithm Signature: RSA (1)
                Signature Length: 256
                Signature: a0ba11e63a9c2155f0e895d0849518536951ca93039ab7d4...

科普一下DH

DH用于解決對稱加密中密鑰傳遞的安全問題埂材。 DH加密算法為非對稱加密算法塑顺，所謂非對稱即加密與解密使用的密鑰不同。一個公開俏险，稱為公鑰严拒；一個保密，稱為私鑰竖独。

B必須使用A的公鑰作為參數(shù)來構(gòu)建自己的密鑰對裤唠，否則無法確保B 和A使用同一個私鑰。

雖然A 和B雙方使用了不同的密鑰來構(gòu)建本地密鑰莹痢，但得到的密鑰是一致的种蘸。這里的說明可以更好的理解為什么密鑰是一致的墓赴。

Server Hello Done

告訴客戶端，整個Server Hello 階段已經(jīng)結(jié)束航瞭，等待客戶端回復诫硕。

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 4
        Handshake Protocol: Server Hello Done
            Handshake Type: Server Hello Done (14)
            Length: 0

Client key exchange ,Change Cipher Spec

這里把DH算法的客戶端公鑰發(fā)送給服務端，這條消息必須在Client Certificate（如果有的話）之后立即發(fā)送刊侯。

這里的Key Exchange交換的就是pre-master key章办，有了pre-master key和我們之前生成兩個隨機數(shù)CR和SR就能夠計算出我們的對稱加密的密鑰了，這里總共分為兩種情況：

• 如果采用的是RSA算法滨彻，這里就是一個客戶端產(chǎn)生的48 byte的隨機數(shù)藕届，用服務端的公鑰加密之后發(fā)送。這里需要用公鑰加密的原因在于疮绷，前兩個隨機數(shù)都是明文傳輸?shù)暮采啵捎肦SA方式傳輸密鑰，如果三個隨機數(shù)都是明文冬骚，那么就可以計算出對稱加密的密文了，所以這里一定是要加密傳輸懂算。

• 如果采用的是DH算法及各種變種算法（如：ECDHE）只冻，這里發(fā)送的就是客戶端公鑰。這個消息不用公鑰加密计技，原因在于DH算法本身的作用就是在不安全的通信通道交換一個安全的加密密鑰喜德。

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 70
        Handshake Protocol: Client Key Exchange
            Handshake Type: Client Key Exchange (16)
            Length: 66
            EC Diffie-Hellman Client Params
                Pubkey Length: 65
                Pubkey: 046ac098d21b903b341e16a49d8ec2cbfde65e91ae199fa4...
    TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.2 (0x0303)
        Length: 1
        Change Cipher Spec Message
    TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 40
        Handshake Protocol: Hello Request
            Handshake Type: Hello Request (0)
            Length: 0
        Handshake Protocol: Hello Request
            Handshake Type: Hello Request (0)
            Length: 0

整個流程可以簡單概括為：

• 通過TLS握手后，客戶端拿到服務端的公鑰構(gòu)建密鑰對垮媒，并把客戶端的公鑰發(fā)送給服務端舍悯。這時候的公鑰也就是pre-master secret。
• C和S 通過使用各自pre-mastersecret以及結(jié)合CR + SR睡雇，生成對稱密鑰萌衬。
• 隨后的通訊使用對稱密鑰加密。

服務器與瀏覽器的Https握手

服務器與瀏覽器在傳輸數(shù)據(jù)之前它抱，會進行一次握手秕豫，握手過程中會確定雙方加密傳輸數(shù)據(jù)的密碼信息。握手及數(shù)據(jù)傳輸過程遵循TLS/SSL協(xié)議观蓄。
服務器與瀏覽器握手的意義在于：確定通信信道的安全混移，通過握手協(xié)商出雙方傳輸數(shù)據(jù)的密碼，只要保證了通信信道的安全侮穿，雙方就可以用對稱密碼加密通信內(nèi)容歌径，因為對稱加密的速度要比非對稱加密快得多。

TLS/SSL中使用了非對稱加密亲茅，對稱加密以及HASH算法回铛。握手過程的簡單描述如下：

• 瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站金矛。

• 網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器勺届。證書里面包含了網(wǎng)站地址驶俊，加密公鑰，以及證書的頒發(fā)機構(gòu)等信息免姿。

• 獲得網(wǎng)站證書之后瀏覽器要做以下工作：

  • 驗證證書的合法性（頒發(fā)證書的機構(gòu)是否合法饼酿，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任胚膊，則瀏覽器欄里面會顯示一個小鎖頭故俐，否則會給出證書不受信的提示。

  • 如果證書受信任紊婉，或者是用戶接受了不受信的證書药版，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密喻犁。

  • 使用約定好的HASH計算握手消息槽片，并使用生成的隨機數(shù)對消息進行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站肢础。

• 網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：

  • 使用自己的私鑰將信息解密取出密碼还栓，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致传轰。

  • 使用密碼加密一段握手消息剩盒，發(fā)送給瀏覽器。

• 瀏覽器解密并計算握手消息的HASH慨蛙，如果與服務端發(fā)來的HASH一致辽聊，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密期贫。

這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證跟匆，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù)唯灵，為后續(xù)真正數(shù)據(jù)的傳輸做一次測試贾铝。

其中非對稱加密算法用于在握手過程中加密生成的密碼，對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密埠帕，而HASH算法用于驗證數(shù)據(jù)的完整性垢揩。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關(guān)鍵，因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密敛瓷。非對稱加密算法會生成公鑰和私鑰叁巨，公鑰只能用于加密數(shù)據(jù)，因此可以隨意傳輸呐籽，而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密锋勺，所以網(wǎng)站都會非常小心的保管自己的私鑰蚀瘸，防止泄漏。

擴展閱讀

What's the purpose of Server Key Exchange when using Ephemeral Diffie-Hellman?

SSL Introduction with Sample Transaction and Packet Exchange

Differences between the terms “pre-master secret”, “master secret”, “private key”, and “shared secret”?

TLS, Pre-Master Secrets and Master Secrets

SSL握手協(xié)議

PlantUML Code

記下UML圖生成代碼庶橱，方便以后修改贮勃。

@startuml
actor Client
actor Server
Client -> Server : 1) Client Hello 
note left 
        支持的TLS協(xié)議版本 ,支持的加密方法,支持的壓縮方法 ,隨機數(shù)CR,
        擴展信息里面包括：請求域名，服務器證書的校驗結(jié)果苏章，檢驗方式.
end note
Server -> Client : 2) Server Hello
note right
            確認TLS協(xié)議版本寂嘉，確定加密方法，隨機數(shù)SR枫绅，確認壓縮算法
end note
Server -> Client : 3) Server Certificate,Server Key Exchange(optional),Client Certificate Request(optional)
note right
            1)發(fā)送證書鏈給客戶端驗證
            2)發(fā)送Server的Pre Master Secret給客戶端
            3)要求驗證客戶端的證書
end note
Server -> Client :  4) Server Hello Done
note right
            告訴客戶端泉孩，整個Server Hello
            階段已經(jīng)結(jié)束，等待客戶端回復并淋。
end note 
Client -> Server : 5) Client Certificate (optional)
note left
            只有在服務端要求驗證客戶端證書(上面的第三步)寓搬，客戶端發(fā)
            才送證書.這是客戶端在Server Hello Done之后發(fā)送的第
            一條數(shù)據(jù)。
end note 
Client -> Server : 6) Client Key Exchange
note left
            此消息必須在Client Certificate（如果有的話）之后立即發(fā)送县耽。
            把Client的Pre Master Secret發(fā)送給Server句喷。用于結(jié)合之前生成
            兩個隨機數(shù)CR和SR生成對稱加密密鑰。
end note 

Client -> Server : 7) Change Cipher Spec
note left
            告訴服務端：客戶端之后通信就開始使用
            之前約定好的加密方式來加密傳輸了
end note 
Client -> Server : 8) Encrypted Handshake Message
note left
            這一步的作用是把之前握手的所有消息酬诀，用加密套件里的hash算法計算出一個值脏嚷，然后用
            剛剛協(xié)商好的對稱加密的密鑰進行加密，發(fā)送給服務端瞒御，即能驗證之前發(fā)送的消息有沒有
            被篡改，又能驗證下服務端計算的密鑰對不對神郊，如果計算不對就解不出明文肴裙。
end note 
Server -> Client : 9) Change Cipher Spec
note right
            告訴客戶端：服務端之后通信就開始使用之前約定好
            的加密方式來加密傳輸了
end note 
Server -> Client : 10 )Encrypted Handshake Message
@enduml