加密
網(wǎng)絡(luò)安全是一個(gè)非常重要的問(wèn)題乌妙。目前絕大多數(shù)的網(wǎng)絡(luò)站點(diǎn)都是通過(guò)https來(lái)保證web站點(diǎn)的安全可靠使兔，提到https就想到了 TLS/SSL。下面介紹一下ssl和tls的區(qū)別和歷史藤韵。
SSL和TLS的區(qū)別和歷史
- SSL 1.0 未公開(kāi)發(fā)布虐沥，因?yàn)榇嬖趪?yán)重的安全性漏洞。
- SSL 2.0 1995年2月發(fā)布泽艘，因存在安全漏洞欲险。在2011年被RFC 6176禁止。
- SSL 3.0 1996年誕生匹涮，代表的是SSL該協(xié)議的完全重新設(shè)計(jì)天试，但是3.0也在2015年被RFC 2246 禁止。
- TLS 1.0 作為SSL 的升級(jí)版本于1999年首次定義然低。同時(shí)應(yīng)微軟要求喜每，改名為T(mén)LS务唐。
- TLS 1.1 2006年誕生。
- TLS 1.2 2008年發(fā)版带兜。
- TLS 1.3 2018年發(fā)版枫笛。
TLS安全密碼套件
其套件大致分為4個(gè)組成部分：
密鑰交換
ECDHE這個(gè)是一個(gè)橢圓曲線加密算法。這個(gè)算法解決的是怎樣讓瀏覽器和服務(wù)端各自獨(dú)立生成一套相同的密鑰刚照。
- 客戶端瀏覽器隨機(jī)生成一個(gè)值Ra刑巧，計(jì)算Pa(x,y) = Ra*Q(x,y),Q(x,y)為全世界公認(rèn)的某個(gè)橢圓曲線算法的基點(diǎn)。將Pa(x,y)發(fā)送至服務(wù)器无畔。
- 服務(wù)器隨機(jī)生成一個(gè)值Rb啊楚，計(jì)算 Pb(x,y) = Rb * Q(x,y)。將Pb(x,y)發(fā)送到客戶端瀏覽器檩互。
- 客戶端計(jì)算Sa(x,y) = Ra * Pb(x,y)特幔，服務(wù)器計(jì)算Sb(x,y)=Rb*Pa(x,y)
- 算法保證了Sa=Sb=S, 提取其中的S的x向量作為密鑰。
舉個(gè)例子吧~~
假設(shè)約定算法參數(shù)：模數(shù)97闸昨，基數(shù)3。
張三自己隨機(jī)出來(lái)的私鑰是6薄风，李四自己隨機(jī)出來(lái)的私鑰是21饵较。
p = 97
g = 3
a = 6 , b = 21
A = (g**a)%p
B = (g**b)%p
(B ** a) % p = 47
(A ** b) % p = 47
最終 47 張三，李四都得到了遭赂。當(dāng)然實(shí)際中的模數(shù)足夠大 循诉，通常至少300位以上。
密鑰交換也可以由RSA來(lái)做撇他，這是一種古老的做法茄猫，即客戶端利用證書(shū)中的公鑰去加密預(yù)主密鑰，服務(wù)端再去用私鑰解密
身份驗(yàn)證（證書(shū)驗(yàn)證）
RSA的核心涉及的是公鑰和私鑰的概念困肩。也就是用公鑰加密后的數(shù)據(jù)只能私鑰解划纽，用私鑰加密的數(shù)據(jù)只能公鑰解開(kāi)。
- 客戶端發(fā)起請(qǐng)求锌畸，服務(wù)端首先回復(fù)自己的公鑰到客戶端勇劣。
- 客戶端使用隨機(jī)數(shù)算法，生成一個(gè)密鑰S潭枣，使用服務(wù)端發(fā)來(lái)的公鑰進(jìn)行加密比默，生成C，再將C發(fā)到服務(wù)端盆犁。
- 服務(wù)端收到C后命咐，用自己的私鑰進(jìn)行解密，得到S谐岁。
- 算法使得服務(wù)端和客戶端都得到了S醋奠，而S就是 密鑰（預(yù)主密鑰）
對(duì)稱加密算法榛臼，強(qiáng)度，分組
AES算法是高級(jí)加密標(biāo)準(zhǔn)钝域，也是最常見(jiàn)的對(duì)稱加密算法讽坏，對(duì)稱加密的特點(diǎn)即為加密解密需要相同的密鑰。具體的加密過(guò)程就不詳細(xì)介紹了例证。需要提出的分組路呜，GCM模式是一種新的分組模式，可以提升多核CPU的加解密速度织咧。
簽名hash算法
SHA256 是一個(gè)摘要算法胀葱，是為了將不定長(zhǎng)度的字符串，生成一個(gè)更短的固定長(zhǎng)度的摘要笙蒙。
HTTP 與 TLS
下圖中站點(diǎn)的維護(hù)人就是證書(shū)訂閱人抵屿，首先需要申請(qǐng)一個(gè)證書(shū)，需要在登記機(jī)構(gòu)登記自己的信息捅位。然后由CA機(jī)構(gòu)簽發(fā)證書(shū)轧葛。CA機(jī)構(gòu)生成一對(duì)密鑰，其中公鑰在CA中保存艇搀。
1.客戶端請(qǐng)求站點(diǎn)尿扯，Web服務(wù)器將自己的公鑰證書(shū)發(fā)給瀏覽器，而瀏覽器驗(yàn)證是否合法焰雕。
2.瀏覽器需要檢驗(yàn)證書(shū)是否合法過(guò)期衷笋。CA機(jī)構(gòu)會(huì)將所有的過(guò)期的證書(shū)放到CRL服務(wù)器上，而這些證書(shū)會(huì)形成一個(gè)鏈條矩屁，所以在CRL上查是性能很差的辟宗。所以CA機(jī)構(gòu)推出OCSP響應(yīng)程序，瀏覽器可以在OCSP上查取某一證書(shū)是否過(guò)期吝秕。但其實(shí)這樣的機(jī)制還是性能太差泊脐。所以Nginx 上有 OCSP 的開(kāi)關(guān)，開(kāi)啟后郭膛，由Nginx去主動(dòng)查詢晨抡。
證書(shū)類(lèi)型
域名驗(yàn)證(domain validated，DV) 證書(shū)
這種證書(shū)是最便宜的则剃，申請(qǐng)后可立即頒發(fā)耘柱。
- 審核的內(nèi)容：域名管理權(quán)限
- 一般用途：個(gè)人站點(diǎn)，登陸等單純的https加密需求棍现。
組織驗(yàn)證(organization validated, OV) 證書(shū)
這種證書(shū)一般貴调煎。申請(qǐng)后幾天后頒發(fā)。
- 審核的內(nèi)容：域名管理權(quán)限己肮，企業(yè)名稱士袄，地址悲关，電話等信息的真實(shí)性。
- 一般用途：企業(yè)網(wǎng)站
擴(kuò)展驗(yàn)證(extend validation娄柳， EV)證書(shū)
這種證書(shū)比較貴寓辱，簽發(fā)需要一個(gè)禮拜。
- 審核內(nèi)容：除上述需要驗(yàn)證的內(nèi)容外赤拒，還需要驗(yàn)證第三方數(shù)據(jù)庫(kù)審查秫筏，律師證明等。
-
一般用途：企業(yè)官網(wǎng)挎挖，電子商務(wù)網(wǎng)站这敬，P2P互聯(lián)網(wǎng)金融，正式的大型網(wǎng)站蕉朵。
EV證書(shū)如圖所示崔涂，有附加的地址欄，組織始衅，公司名稱冷蚂。
github官網(wǎng)(EV)證書(shū).png
證書(shū)鏈
首先打開(kāi)證書(shū)查看器
基本上所有的證書(shū)層次結(jié)構(gòu)都是這樣的，最上面是根證書(shū)汛闸。二級(jí)證書(shū)簽發(fā)機(jī)構(gòu)是DigCert帝雇。
- 根證書(shū)的驗(yàn)證是十分謹(jǐn)慎的，大部分瀏覽器都使用的是操作系統(tǒng)的根證書(shū)蛉拙。少部分的如firefox的根證書(shū)是自己維護(hù)的，也就是說(shuō)其實(shí)根證書(shū)是沒(méi)必要發(fā)給客戶端的彻亲。只需要將兩個(gè)證書(shū)發(fā)給客戶端就可以了孕锄。
如下圖：
github 證書(shū)查看
由上圖可以看到，在交互過(guò)程中.只有兩個(gè)證書(shū)被交給了客戶端苞尝，一個(gè)是guthubapp.com , 一個(gè)是DigCert 二級(jí)證書(shū)畸肆。瀏覽器會(huì)自動(dòng)驗(yàn)證證書(shū)有效性。
https過(guò)程
數(shù)字認(rèn)證機(jī)構(gòu)(CA)用自己的私鑰加密了web站點(diǎn)管理員的公鑰和身份信息宙址，而CA的公鑰是存在于客戶端瀏覽器和客戶端操作系統(tǒng)中的轴脐。web站點(diǎn)用加密后的證書(shū)證明自己，而瀏覽器端用自己的CA公鑰驗(yàn)證該網(wǎng)站的真實(shí)性抡砂。
注意：下圖有些老大咱，是還用RSA加密預(yù)主密鑰的方式，而用證書(shū)私鑰解密預(yù)主密鑰的方式是向前不安全的注益，即證書(shū)私鑰一旦丟失碴巾，就可能造成之前已加密傳輸數(shù)據(jù)的安全性，新的都是用DECH的丑搔，也就是多了一步server key exchange
接下來(lái)通過(guò)抓包的方式演示一下整個(gè)https的握手流程厦瓢。
如下圖
1. tcp 三次握手提揍，該過(guò)程略。
2. Client Hello
- 該階段煮仇，客戶端發(fā)送Client Hello 開(kāi)始TLS 通信劳跃，報(bào)文中包含客戶端支持的TLS 版本（都沒(méi)人支持SSL了.....），加密組件列表（Cipher suites）浙垫，隨機(jī)數(shù)刨仑，Session Ticket (這個(gè)之后在Nginx 與 https 文中講解)
3. Server Hello
- 該報(bào)文同樣包含一些TLS版本，服務(wù)端從客戶端加密組件篩選出匹配的绞呈。選擇加密套件中的Cipher suite贸人。壓縮算法等等。（這里選擇的加密套件規(guī)定了后續(xù)所有加密的算法佃声，如密鑰交換的算法艺智，之后對(duì)稱加密的算法，摘要驗(yàn)證的算法圾亏，PRF(偽隨機(jī)數(shù)函數(shù))）
4.Server Certificate
- 可以看到服務(wù)端將自己的兩個(gè)證書(shū)發(fā)送過(guò)來(lái)十拣，一個(gè)是baidu的，一個(gè)是二級(jí)證書(shū)GlobalSign志鹃。這里服務(wù)端是不需要發(fā)送根證書(shū)的夭问，因?yàn)楦C書(shū)，客戶端有曹铃＄智鳎客戶端收到證書(shū)后會(huì)進(jìn)行證書(shū)鏈的校驗(yàn)，有包括離線的CRL和在線的OCSP方式陕见。證書(shū)的有效期expiry date秘血。以及證書(shū)的域名是否和當(dāng)前訪問(wèn)的域名所匹配。
5.Server Key Exchange
- 這里就是 ECDHE 密鑰交換评甜。服務(wù)器將自己的ECDHE 數(shù)以及相應(yīng)的橢圓曲線參數(shù) 傳遞給客戶端灰粮。
對(duì)于RSA而言，Certificate Message 中已經(jīng)包含足夠的信息可以忍坷，而Client key Excahnge 可以使用這些信息進(jìn)行加密預(yù)主密鑰粘舟，但是對(duì)于DH 這類(lèi)算法而言，Certificate Message 中只包含部分信息佩研，剩余的就在Server Key Excahnge 中柑肴。也就是說(shuō)采用DH算法，證書(shū)只是用來(lái)驗(yàn)證身份的韧骗，而非是用來(lái)提取公鑰然后做加密預(yù)主密鑰的嘉抒。
若單純的使用RSA算法，RSA即用作驗(yàn)證服務(wù)器身份袍暴，又用來(lái)做加密預(yù)主密鑰些侍，RSA使用證書(shū)中的公鑰加密隶症。但是這樣向前不安全
DH算法所以和RSA算法一起使用醋界，RSA做驗(yàn)證服務(wù)器身份雄右，DH算法專門(mén)加密預(yù)主密鑰鳖眼，使用DH算法向前安全刃跛。
6.Server Hello Done
- 服務(wù)端通知客戶端酗失，信息發(fā)送結(jié)束叛甫。
7.Client Key Exchange
- 因本例使用了DH算法筹吐，所以不需要RSA了痘儡。這里的預(yù)主密鑰就有DH算法來(lái)解決了刊咳，如上圖彪见。當(dāng)然這個(gè)預(yù)主密鑰是為后來(lái)的對(duì)稱加密做準(zhǔn)備。
8.Change Cipher Spec
- 本過(guò)程的是告訴服務(wù)端娱挨，好了∮嘀福現(xiàn)在開(kāi)始后續(xù)的通信都采用協(xié)商后的通信密鑰進(jìn)行對(duì)稱加密吧。(圖在過(guò)程7中)
9. Encrypted Handshake Message
- 結(jié)合之前的所有通信參數(shù)的hash值與其他相關(guān)的數(shù)據(jù)跷坝，發(fā)送給服務(wù)器端用做數(shù)據(jù)與握手的驗(yàn)證酵镜。驗(yàn)證對(duì)端是否計(jì)算了相同的參數(shù)。（圖在過(guò)程7中）
10. Change Cipher Spec
- 服務(wù)端也發(fā)送 Change Cipher Spec柴钻，意思同意開(kāi)始對(duì)稱加密通信淮韭。
11. Encrypted HandShake Message
- 服務(wù)端也結(jié)合當(dāng)前的通信參數(shù)生成一段數(shù)據(jù)，并采用協(xié)商密鑰 session secret 與算法加密贴届，發(fā)送至客戶端靠粪。
參考文章：https://blog.csdn.net/mrpre/article/details/78025940
https://github.com/geektime-geekbang/geektime-nginx/blob/master/Nginx%E6%A0%B8%E5%BF%83%E7%9F%A5%E8%AF%86100%E8%AE%B2-%E7%AC%AC%E4%B8%80%E9%83%A8%E5%88%86%E8%AF%BE%E4%BB%B6.pdf
https://blog.csdn.net/andylau00j/article/details/54583769
這里推薦的文章：
HTTPS背后的加密算法
為什么強(qiáng)烈建議使用ECC證書(shū)
