Https原理解析

序言

我們已知http是基于明文傳輸,所以在網(wǎng)絡(luò)中傳輸一些隱私數(shù)據(jù)沒有辦法保證一些安全性.所以我們可以通過(guò)一些加密方式來(lái)完成,加密方式有對(duì)稱加密和非對(duì)稱加密,下面會(huì)詳細(xì)介紹一下兩者加密方式特性.本文不對(duì)tcp握手流程作過(guò)多講解. (有問題歡迎留言探討)

對(duì)稱加密

對(duì)稱加密:加密和解密用的是同一個(gè)秘鑰
常用對(duì)稱加密算法有DES仙逻、3DES、AES
3DES就是三次DES加密
AES加密算法就是眾多對(duì)稱加密算法中的一種帮碰，它的英文全稱是Advanced Encryption
Standard碗旅，翻譯過(guò)來(lái)是高級(jí)加密標(biāo)準(zhǔn)美澳，它是用來(lái)替代之前的DES加密算法的竞阐。
AES為分組密碼僚害，分組密碼也就是把明文分成一組一組的硫椰，每組長(zhǎng)度相等，每次加密一組數(shù)
據(jù)萨蚕，直到加密完整個(gè)明文靶草。在AES標(biāo)準(zhǔn)規(guī)范中，分組長(zhǎng)度只能是128位岳遥，也就是說(shuō)奕翔，每個(gè)分組
為16個(gè)字節(jié)（每個(gè)字節(jié)8位）。密鑰的長(zhǎng)度可以使用128位浩蓉、192位或256位派继。密鑰的長(zhǎng)度不
同，推薦加密輪數(shù)也不同捻艳。如AES-128驾窟，也就是密鑰的長(zhǎng)度為128位，加密輪數(shù)為10輪认轨。
關(guān)于AES加密绅络，

詳細(xì)可參考博客：點(diǎn)擊直達(dá)

非對(duì)稱加密

非對(duì)稱加密有兩個(gè)秘鑰,分為公鑰和私鑰,公鑰和私鑰可以相互解密對(duì)方加密的密文.常見的
對(duì)稱加密算法有：RSA、ECC（移動(dòng)設(shè)備用）嘁字、Diffie-Hellman(密鑰協(xié)商)恩急、
ElGamal、DSA（數(shù)字簽名用）纪蜒。

Diffie-Hellman算法

DH算法的主要功能是用于在不安全的通道中交換對(duì)稱加密的密鑰,而不適用于加密數(shù)據(jù)進(jìn)行
傳輸(效率慢)
DH算法原理:
    1.通信雙方A和B約定兩個(gè)大整數(shù) n 和 g (^為次方,mod為取余)(n和g不是隨便的,
      需要滿足DH算法,不然很容易就暴力破解)
    2.A生成一個(gè)隨機(jī)數(shù)a(密鑰),a保密,并且把g的a次方對(duì)n取余(結(jié)果Ka)發(fā)送個(gè)B
      (Ka = g^a mod n)
    3.B生成一個(gè)隨機(jī)數(shù)b,b保密,并且吧G的b次方對(duì)n取余(結(jié)果Kb)發(fā)送給A
      (kb = g^b mod n)
    4.A現(xiàn)在擁有Kb和a,B現(xiàn)在擁有Ka和b
    5.A計(jì)算K = Kb ^ a mod n
    6.b計(jì)算k = Ka ^ b mon n
    7.Kb ^ a mod n = (g^b mod n) ^ a mon n 
                   = (g ^ a mod n) ^b mod n 
                   (emm,離散不好表示沒想明白,數(shù)學(xué)家證明了上面是成立的)
    8.所以k就是密鑰.
    攔截者只能獲取到Ka和Kb,n和g,對(duì)于大數(shù)n和g,利用離散對(duì)數(shù)來(lái)計(jì)算k是非常困難的事.
    
大致流程如下:
    1. server 構(gòu)建密鑰對(duì):公鑰public key1 和私鑰 private key1
    2. server --> client:server向client公開自己的公鑰public key1
    3. client (根據(jù)public key1,就是上面所述的n和g) 構(gòu)建自己的本地密鑰對(duì):
        public key2 和private key2
    4. client --> server:client 向server 公開自己的公鑰public key2
    5. server 使用密鑰對(duì):private key1,public key2計(jì)算出密鑰Y1
    6. client 使用密鑰對(duì):private key2,public key1計(jì)算出密鑰Y2
    7. 根據(jù)上面描述的算法,密鑰Y1 = Y2

• DH算法參考(直達(dá))
• DH算法參考(直達(dá))

SSL和TLS

SSL和TLS參考區(qū)別(直達(dá))

分析https的流程必要性

• 只用對(duì)稱加密來(lái)實(shí)現(xiàn)
  • 分步驟分析,如果我們選擇對(duì)稱加密來(lái)加密數(shù)據(jù),client和server都是用相同密鑰來(lái)加密和解密,實(shí)現(xiàn)數(shù)據(jù)的安全性.但是中間存在兩個(gè)問題
  • 密鑰如何保證傳輸安全的問題
  • 服務(wù)端需要維護(hù)大量的密鑰對(duì)
• 只用非對(duì)稱加密來(lái)實(shí)現(xiàn)
  • 非對(duì)稱加密和對(duì)稱加密都有相同的問題,就是這個(gè)密鑰如何傳輸?shù)膯栴}.
  • 需要維護(hù)大量的密鑰對(duì)

所以我們單獨(dú)使用其中一種是沒有辦法很好的實(shí)現(xiàn)的,所以https就是將兩者結(jié)合起來(lái),取其精華

https握手流程

先大致講一下整體流程,下面會(huì)分析如何保證安全,為何需要這樣操作保證安全.

1. 客戶端 -> 服務(wù)端 Handshake Type : Client Hello 同時(shí)會(huì)帶一個(gè)隨機(jī)的串random1(這個(gè)后面會(huì)用到),客戶端支持的加密算法列表和客戶端支持的TLS版本給server
   
   client hello

2. 服務(wù)端 -> 客戶端 一次會(huì)順序返回3個(gè)包,這個(gè)好像也是HTTPS的一種優(yōu)化
   • Handshake Type : Server Hello 第一個(gè)包內(nèi)容包含一個(gè)隨機(jī)的串random2(這個(gè)后面也會(huì)用到)

server hello_1

• Handshake Type : Certufucate 第二個(gè)包會(huì)把證書信息返回給客戶端,證書里面包含有效期,公鑰信息,服務(wù)器選擇的對(duì)稱加密算法

server_hello_2.png

• Handshake Type : Server Key Exchange 第三個(gè)包會(huì)將dh算法參數(shù)和生成的公鑰返回給client,并且發(fā)送Server Hello Done表示結(jié)束

  
  
  server_hello_3.png

3. 客戶端 -> 服務(wù)端 客戶端使用相同的DH算法參數(shù)生成客戶端的公鑰和私鑰,將公鑰發(fā)送給服務(wù)端.(客戶端和服務(wù)端可以通過(guò)DH算法,算出對(duì)稱加密密鑰)

   
   
   client_dh.png

4. (優(yōu)化)客戶端會(huì)發(fā)送一個(gè)ticket給服務(wù)端,用于短時(shí)間內(nèi)如果重新連接時(shí),https快速驗(yàn)證復(fù)用.
   

   client_ticket.png

到此為止,SSL or TLS 握手就已經(jīng)完成,client和server都有了對(duì)稱加密密鑰,這時(shí)候就會(huì)使用第二步約定好的對(duì)稱加密算法進(jìn)行數(shù)據(jù)的傳輸.

在第三步的過(guò)程中,使用的是DH算法,還有一種方式是使用RSA算法,使用公鑰加密random3發(fā)送給server,server使用私鑰進(jìn)行解密,這樣獲得的random1+random2+random3就是對(duì)稱加密的密鑰.

整個(gè)SSL or TLS 握手流程都是明文傳輸?shù)?也沒有辦法進(jìn)行加密,攔截者可以獲取到公鑰,random1和random2串,但是dh交換(或者RSA算法)得到的random3是沒有辦法被攔截者獲取的.因此來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?

分析如果被攔截,是否有風(fēng)險(xiǎn)

• 如果client -> server : client Hello 被攔截,攔截者成為中間者,發(fā)送自己的證書,公鑰,簽名給client,如何處理?

  答:如果攔截者發(fā)送自己的證書,那么client 在解析證書時(shí),對(duì)比CA機(jī)構(gòu)信息和域名信息,瀏覽器根本不會(huì)信任這個(gè)證書,也就不會(huì)信任這個(gè)鏈接,在chrome上訪問指定域名(但是返回證書不是這個(gè)域名),會(huì)直接拒絕鏈接.即使攔截者自己簽發(fā)了證書,域名信息對(duì)了,但是CA機(jī)構(gòu)大多數(shù)內(nèi)置在瀏覽器之內(nèi),還是不信任鏈接.

• 中間是否會(huì)被攔截者攔截到隱私數(shù)據(jù),或者會(huì)被攔截者拿到對(duì)稱加密密鑰解析出數(shù)據(jù)?

  答:我們經(jīng)過(guò)上面的分析發(fā)現(xiàn),攔截者只能拿到random1串和random2串,和非對(duì)稱加密的公鑰,并沒有辦法拿到RSA算法加密的random3串,也就沒有辦法拿到對(duì)稱加密密鑰.

• 攔截者是否能夠成為DH算法中的中間者?如果成為中間者,是否可以和client交換獲取密鑰?

  答:這個(gè)問題其實(shí)就是DH算法能否被破解的問題,答案,很難,當(dāng)兩個(gè)共有數(shù)都為大數(shù)時(shí),基本不可能被破解.首先,攔截者可以獲取共有數(shù)A和B,client的共有PBc和server的共有數(shù)PBs,但是還是很難計(jì)算出密鑰,所以暫時(shí)來(lái)看基本很難破解.

HTTPS優(yōu)化

1. 會(huì)話復(fù)用(session ID和session ticket)

   會(huì)話復(fù)用原理也比較簡(jiǎn)單,就是連接過(guò)之后,客戶端和服務(wù)端都保存下大家協(xié)商好的密鑰,在后續(xù)請(qǐng)求中直接使用.

   • session ID

     client或server會(huì)保存session ID,后續(xù)需要重新請(qǐng)求的時(shí)候,會(huì)帶上session ID,如果server能找到匹配的session ID,則快速握手完成.

     
     
     session_id.png

   • session ticket

     nginx已經(jīng)默認(rèn)優(yōu)先使用了session ticket,session ticket是用服務(wù)端密鑰加密過(guò)的會(huì)話信息,保存在瀏覽器本地,如果需要 重新請(qǐng)求握手,會(huì)在client hello中帶上session ticket,如果server可以解析成功,則快速握手完成. (nginx中使用 ssl_session_ticket_key file; 指令來(lái)配置用于加密或解密SSL session_ticket的密鑰, 如果用了多個(gè)指令文件,則僅第一個(gè)指令文件中的密鑰用來(lái)加密; 其它的密鑰文件,并且第一個(gè)密鑰文件都可以用做解密.)

     session ID其實(shí)是有一些弊端,首先,當(dāng)負(fù)載均衡時(shí),如果多機(jī)沒有同步session ID信息,那我們并不能保證session ID能被上次保存的server接收.

2. CDN接入

   利用CDN可以大大減少傳輸時(shí)延

3. 硬件加速

   可以接入一些專門用于解密計(jì)算的SSL硬件加速卡,解放CPU,加快解密速度

參考

加密算法直達(dá)