一姐刁、前言
在說(shuō)HTTPS之前先說(shuō)說(shuō)什么是HTTP铃诬，HTTP就是我們平時(shí)瀏覽網(wǎng)頁(yè)時(shí)候使用的一種協(xié)議。HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的座哩，也就是明文的徒扶，因此使用HTTP協(xié)議傳輸隱私信息非常不安全。為了保證這些隱私數(shù)據(jù)能加密傳輸根穷，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密姜骡，從而就誕生了HTTPS。SSL目前的版本是3.0屿良，被IETF（Internet Engineering Task Force）定義在RFC 6101中圈澈，之后IETF對(duì)SSL 3.0進(jìn)行了升級(jí)，于是出現(xiàn)了TLS（Transport Layer Security） 1.0尘惧，定義在RFC 2246康栈。實(shí)際上我們現(xiàn)在的HTTPS都是用的TLS協(xié)議，但是由于SSL出現(xiàn)的時(shí)間比較早喷橙，并且依舊被現(xiàn)在瀏覽器所支持啥么，因此SSL依然是HTTPS的代名詞，但無(wú)論是TLS還是SSL都是上個(gè)世紀(jì)的事情贰逾，SSL最后一個(gè)版本是3.0饥臂，今后TLS將會(huì)繼承SSL優(yōu)良血統(tǒng)繼續(xù)為我們進(jìn)行加密服務(wù)。目前TLS的版本是1.2似踱，定義在RFC 5246中隅熙，暫時(shí)還沒(méi)有被廣泛的使用 ()
概念可參考百科
http://baike.baidu.com/link?url=M8pBu1j_22f0PW6izvAOCTjhepyRcT320U9LDmjyzb586OYS_aBALxfqIGVca1V-8MJeSl3bTUEOThMuwpamPK
二? HTTPS 驗(yàn)證原理
Https在真正請(qǐng)求數(shù)據(jù)前稽煤，先會(huì)與服務(wù)有幾次握手驗(yàn)證，以證明相互的身份囚戚，以下圖為例
2.1? 驗(yàn)證流程
注：文中所寫的序號(hào)與圖不對(duì)應(yīng)但流程是對(duì)應(yīng)的
1 客戶端發(fā)起一個(gè)https的請(qǐng)求酵熙，把自身支持的一系列Cipher Suite（密鑰算法套件，簡(jiǎn)稱Cipher）發(fā)送給服務(wù)端
2? 服務(wù)端驰坊，接收到客戶端所有的Cipher后與自身支持的對(duì)比匾二，如果不支持則連接斷開(kāi)，反之則會(huì)從中選出一種加密算法和HASH算法
以證書的形式返回給客戶端 證書中還包含了 公鑰 頒證機(jī)構(gòu) 網(wǎng)址 失效日期等等拳芙。
3 客戶端收到服務(wù)端響應(yīng)后會(huì)做以下幾件事
3.1 驗(yàn)證證書的合法性
頒發(fā)證書的機(jī)構(gòu)是否合法與是否過(guò)期察藐，證書中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等
證書驗(yàn)證通過(guò)后，在瀏覽器的地址欄會(huì)加上一把小鎖(每家瀏覽器驗(yàn)證通過(guò)后的提示不一樣 不做討論)
3.2 生成隨機(jī)密碼
如果證書驗(yàn)證通過(guò)舟扎，或者用戶接受了不授信的證書分飞，此時(shí)瀏覽器會(huì)生成一串隨機(jī)數(shù)，然后用證書中的公鑰加密睹限。
3.3 HASH握手信息
用最開(kāi)始約定好的HASH方式譬猫，把握手消息取HASH值，? 然后用 隨機(jī)數(shù)加密 “握手消息+握手消息HASH值(簽名)”? 并一起發(fā)送給服務(wù)端
在這里之所以要取握手消息的HASH值羡疗，主要是把握手消息做一個(gè)簽名染服，用于驗(yàn)證握手消息在傳輸過(guò)程中沒(méi)有被篡改過(guò)。
4? 服務(wù)端拿到客戶端傳來(lái)的密文叨恨，用自己的私鑰來(lái)解密握手消息取出隨機(jī)數(shù)密碼柳刮，再用隨機(jī)數(shù)密碼 解密 握手消息與HASH值，并與傳過(guò)來(lái)的HASH值做對(duì)比確認(rèn)是否一致痒钝。
然后用隨機(jī)密碼加密一段握手消息(握手消息+握手消息的HASH值 )給客戶端
5? 客戶端用隨機(jī)數(shù)解密并計(jì)算握手消息的HASH秉颗，如果與服務(wù)端發(fā)來(lái)的HASH一致，此時(shí)握手過(guò)程結(jié)束午乓，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密
因?yàn)檫@串密鑰只有客戶端和服務(wù)端知道，所以即使中間請(qǐng)求被攔截也是沒(méi)法解密數(shù)據(jù)的闸准，以此保證了通信的安全
非對(duì)稱加密算法：RSA益愈，DSA/DSS? ? 在客戶端與服務(wù)端相互驗(yàn)證的過(guò)程中用的是對(duì)稱加密
對(duì)稱加密算法：AES，RC4夷家，3DES? ? 客戶端與服務(wù)端相互驗(yàn)證通過(guò)后蒸其，以隨機(jī)數(shù)作為密鑰時(shí)，就是對(duì)稱加密
HASH算法：MD5库快，SHA1摸袁，SHA256? 在確認(rèn)握手消息沒(méi)有被篡改時(shí)
2.2? 客戶端如何驗(yàn)證 證書的合法性？
1. 驗(yàn)證證書是否在有效期內(nèi)义屏。
在服務(wù)端面返回的證書中會(huì)包含證書的有效期靠汁，可以通過(guò)失效日期來(lái)驗(yàn)證 證書是否過(guò)期
2. 驗(yàn)證證書是否被吊銷了蜂大。
被吊銷后的證書是無(wú)效的。驗(yàn)證吊銷有CRL(證書吊銷列表)和OCSP(在線證書檢查)兩種方法蝶怔。
證書被吊銷后會(huì)被記錄在CRL中奶浦，CA會(huì)定期發(fā)布CRL。應(yīng)用程序可以依靠CRL來(lái)檢查證書是否被吊銷了踢星。
CRL有兩個(gè)缺點(diǎn)澳叉，一是有可能會(huì)很大，下載很麻煩沐悦。針對(duì)這種情況有增量CRL這種方案成洗。二是有滯后性，就算證書被吊銷了藏否，應(yīng)用也只能等到發(fā)布最新的CRL后才能知道瓶殃。
增量CRL也能解決一部分問(wèn)題，但沒(méi)有徹底解決秕岛。OCSP是在線證書狀態(tài)檢查協(xié)議碌燕。應(yīng)用按照標(biāo)準(zhǔn)發(fā)送一個(gè)請(qǐng)求，對(duì)某張證書進(jìn)行查詢继薛，之后服務(wù)器返回證書狀態(tài)修壕。
OCSP可以認(rèn)為是即時(shí)的（實(shí)際實(shí)現(xiàn)中可能會(huì)有一定延遲），所以沒(méi)有CRL的缺點(diǎn)遏考。
3. 驗(yàn)證證書是否是上級(jí)CA簽發(fā)的慈鸠。
windows中保留了所有受信任的根證書，瀏覽器可以查看信任的根證書灌具，自然可以驗(yàn)證web服務(wù)器的證書青团，
是不是由這些受信任根證書頒發(fā)的或者受信任根證書的二級(jí)證書機(jī)構(gòu)頒發(fā)的（根證書機(jī)構(gòu)可能會(huì)受權(quán)給底下的中級(jí)證書機(jī)構(gòu)，然后由中級(jí)證書機(jī)構(gòu)頒發(fā)中級(jí)證書）
在驗(yàn)證證書的時(shí)候咖楣，瀏覽器會(huì)調(diào)用系統(tǒng)的證書管理器接口對(duì)證書路徑中的所有證書一級(jí)一級(jí)的進(jìn)行驗(yàn)證督笆，只有路徑中所有的證書都是受信的，整個(gè)驗(yàn)證的結(jié)果才是受信
