https、包括CA證書是為了解決http明文傳輸不安全的問題订雾，提出http over ssl/tls的方案肢预。
接下來筆者按照自己的理解，講一下這個(gè)方案可能的推理形成的過程洼哎。有不當(dāng)之處歡迎指正烫映，永遠(yuǎn)懷著謙卑的心。
公鑰-私鑰 非對(duì)稱加密
首先容易想到的是方案一噩峦，使用非對(duì)稱開放公鑰密鑰體系：
1锭沟、客戶端向服務(wù)端請(qǐng)求正式數(shù)據(jù)之前，先請(qǐng)求公鑰识补，服務(wù)端自己保留私鑰族淮。
2、客戶端用公鑰加密正式數(shù)據(jù)凭涂，傳給服務(wù)端祝辣，服務(wù)端用私鑰解密。
漏洞與劫持
上面的方案漏洞在于切油，一旦客戶端與服務(wù)端之間被安插了一個(gè)proxy蝙斜，這個(gè)惡意代理收到客戶端的公鑰請(qǐng)求，然后代替客戶端向服務(wù)端拿到了真正的公鑰澎胡，但卻把自己的假公鑰返回給了客戶端孕荠，之后客戶端用假公鑰加密的數(shù)據(jù)都將會(huì)被代理解密獲取攻谁！更可怕的是岛琼，在這個(gè)過程中代理由于獲得了服務(wù)端公鑰，仍然可以當(dāng)作沒事兒一樣假扮客戶端跟服務(wù)端進(jìn)行通信巢株，客戶端和服務(wù)端完全意識(shí)不到雙方的加密通信已經(jīng)被竊聽。這就是傳說中的劫持熙涤。
而且阁苞，除去安全漏洞不說，上述方案一直在用非對(duì)稱加密方式進(jìn)行通信祠挫，性能也不太好那槽。
解決這個(gè)漏洞 CA證書
回過頭來看一下，上面的方案的問題在于：客戶端缺少一種能夠識(shí)別獲得的公鑰到底是不是服務(wù)端真正公鑰的手段等舔！
由此骚灸，我們引入方案二：CA證書。
1慌植、客戶端先安裝權(quán)威機(jī)構(gòu)也就是CA頒布的根證書（也就是CA的公鑰）：任何使用本方案的服務(wù)端會(huì)把自己的公鑰事先提供給CA甚牲，CA使用自己的私鑰對(duì)公鑰加密后生成所謂的“CA證書”义郑，而CA根證書則可以驗(yàn)證服務(wù)器公鑰的真實(shí)性。
2丈钙、客戶端向服務(wù)端請(qǐng)求CA證書（也就是經(jīng)過CA私鑰加密后的服務(wù)端公鑰）非驮，順便告訴服務(wù)端自己支持那些對(duì)稱加密算法。
3雏赦、客戶端收到CA證書之后劫笙，先識(shí)別一下真實(shí)性，然后本地生成一個(gè)隨機(jī)密碼星岗、并用已經(jīng)驗(yàn)證了真實(shí)性的服務(wù)端公鑰對(duì)這個(gè)隨機(jī)密碼進(jìn)行加密填大。
4、服務(wù)端對(duì)收到的隨機(jī)密碼包進(jìn)行解密俏橘，拿到真正的隨機(jī)密碼允华。
5、到這里敷矫，雙方都獲得了一個(gè)可以用于對(duì)稱加密驗(yàn)證的隨機(jī)密碼例获，之后的流程，就是客戶端與服務(wù)端使用這個(gè)隨機(jī)密碼進(jìn)行對(duì)稱加密通信的過程了曹仗。
總結(jié)一下
兜了這么大圈子榨汤，其實(shí)一開始使用對(duì)稱加密通信也是OK，關(guān)鍵在于如何可靠的讓雙方都知道對(duì)稱加密算法中的密鑰怎茫。
當(dāng)面把密鑰定下來收壕、雙方都知道了，這肯定可以轨蛤，但這太扯淡和原始了蜜宪。
于是發(fā)明了非對(duì)稱開放公鑰體系：把公鑰讓所有人都知道，然后你們盡管密文發(fā)來祥山，服務(wù)端有辦法驗(yàn)證這密文是不是用自己開放出去的公鑰加密的圃验。
但是又有上面說的劫持的那種情況，于是問題變成了怎么想辦法安全的傳遞密鑰缝呕，只要密鑰是安全傳遞了澳窑，那之后用對(duì)稱加密其實(shí)也行了。于是引入了CA證書供常。
更多請(qǐng)參考 SSL/TLS協(xié)議運(yùn)行機(jī)制的概述 - 阮一峰的網(wǎng)絡(luò)日志 (ruanyifeng.com) 阮一峰老師講解的非常深入淺出
