產(chǎn)生原因：
- HTTP：未加密础倍、明文捅膘。
-
SSL（Secure Sockets Layer）=>TLS（Transport Layer Security）郁妈，目前大部分https都是用的TLS堡距，只不過SSL出現(xiàn)最早我們有時候也依然叫SSL猩系。 - HTTPS = HTTP + TLS
對稱加密和非對稱加密
對稱加密就是用同一個密鑰加密媚送、解密。
如圖寇甸，A如果直接發(fā)送data塘偎，肯定會經(jīng)過若干中間人M（如路由等），HTTP就是純明文的拿霉，M可以獲取所有明文數(shù)據(jù)吟秩。
而通過對稱加密，如果A和B都有密鑰key绽淘，M沒有密鑰就無法得到明文的data涵防。
但問題來了，現(xiàn)在A生成了一個密鑰key沪铭，怎么將其傳給B呢壮池？若直接發(fā)送，那M也會得到伦意，那加密也沒啥意義了火窒。非對稱加密就是為了解決這個而誕生的。
非對稱加密驮肉，就是生成倆key熏矿，一個公鑰key1一個私鑰key2，key1加密的數(shù)據(jù)只能用key2解密离钝，而key2加密的數(shù)據(jù)只能用key1解密票编。這種算法事實上有很多，常用的是 RSA卵渴，其基于的數(shù)學原理是兩個大素數(shù)的乘積很容易算慧域，而拿到這個乘積去算出是哪兩個素數(shù)相乘就很復雜了。好在以目前的技術浪读，分解大數(shù)的素因數(shù)確實比較困難昔榴，尤其是當這個大數(shù)足夠大的時候（通常使用2的10次方個二進制位這么大）辛藻，就算是超級計算機解密也需要非常長的時間。
- 先在A生成公鑰key1和私鑰key2互订，發(fā)送公鑰key1給B吱肌，M可以拿到明文的key1，但拿到也沒啥用仰禽。
- B拿到公鑰key1后氮墨，生成一個密鑰key，然后用公鑰key1把密鑰key加密吐葵，回傳給A规揪。此時通過M時，因為數(shù)據(jù)只能用私鑰key2才能解密温峭，M只有key1猛铅，所以并不能看到其內(nèi)容。
- A拿到加密后的密鑰key后诚镰，通過key2解密奕坟。此時，A清笨、B都擁有了密鑰key，可以通過密鑰key進行對稱加密了刃跛。
CA證書（Certification Authority）
然而抠艾，非對稱加密一定是安全的嗎？
- M在收到公鑰key1的時候桨昙，把key1存起來检号，同時又生成一個偽公鑰key_a和偽私鑰key_b，
- M把偽公鑰key_a發(fā)送給B蛙酪，B依然按照原來的邏輯生成密鑰key齐苛。然后通過收到的偽公鑰key_a加密密鑰key，然后發(fā)送給M桂塞。
- M收到數(shù)據(jù)后凹蜂，通過偽私鑰key_b解密，得到了明文的密鑰key阁危。然后用key1加密密鑰玛痊，再發(fā)送給A，最后A通過key2解密得到密鑰key狂打。
-
此時A擂煞、B、M都知道了密鑰趴乡，但是A对省、B并不知道M已經(jīng)知道了密鑰蝗拿，接下來的消息傳遞對M來說都是明文的了。
這就要用到了CA證書蒿涎。CA 是一些非常權威的專門用于認證一個網(wǎng)站合法性的組織蛹磺。服務商可以向他們申請一個證書，使得他們建立安全連接時可以帶上 CA 的簽名同仆。而 CA 的安全性由操作系統(tǒng)或瀏覽器來認證萤捆。你的 Windows、Mac俗批、Linux俗或、Chrome、Safari 等會在安裝時帶上一個他們認為安全的 CA 證書列表岁忘。如果和你建立安全連接的人帶著這些人的簽名辛慰，那么認為這個安全連接是安全的，沒有遭到中間人攻擊干像。
CA 證書通常情況下是安全的帅腌。因為一旦某個 CA 頒發(fā)出的某個證書被用于了非法用途，瀏覽器和操作系統(tǒng)一般會通過更新將整個 CA 頒發(fā)過的全部證書全部視為不安全麻汰。這使得 CA 通常在頒發(fā)證書時是比較小心的速客。
所以通過 對稱加密 + 非對稱加密 + CA認證 這三個技術混合在一起，才使得 HTTP 的后面加上了一個 S —— Security五鲫。
HTTPS原理
下圖是一個簡單的原理：
- 1.瀏覽器輸入url請求網(wǎng)站溺职，并附帶自己支持的一套加密規(guī)則。
- 2.網(wǎng)站制作證書位喂，這個應該是網(wǎng)站建站的時候就已經(jīng)弄好了浪耘。證書分為服務器證書和客戶端證書，我們所說的證書一般都是指服務器證書塑崖。制作過程如下：
ssl證書相關：http://www.reibang.com/p/4494774963a9
- a) 制作CSR文件七冲。就是制作Certificate Secure Request證書請求文件，制作過程中规婆，系統(tǒng)會產(chǎn)生2個密鑰澜躺，一個是公鑰就是這個CSR文件，另一個是私鑰聋呢，存在服務器上苗踪。
- b) CA認證。將CSR文件提交給CA削锰，一般有兩種認證方式：域名認證 和 企業(yè)文檔認證通铲。
- c) 證書安裝。收到CA證書后器贩，將證書部署在服務器上颅夺。
- 3.網(wǎng)站從瀏覽器發(fā)過來的加密規(guī)則中選一組自身也支持的加密算法和hash算法朋截，并向瀏覽器發(fā)送帶有公鑰的證書，當然證書還包含了很多信息吧黄，如網(wǎng)站地址部服、證書的頒發(fā)機構、過期時間等拗慨。
- 4.瀏覽器解析證書廓八。
- a) 驗證證書的合法性。如頒發(fā)機構是否合法赵抢、證書中的網(wǎng)站地址是否與訪問的地址一致剧蹂，若不合法，則瀏覽器提示證書不受信任烦却，若合法宠叼，瀏覽器會顯示一個小鎖頭。
- b) 若合法其爵，或用戶接受了不合法的證書冒冬，瀏覽器會生成一串隨機數(shù)的密碼（即密鑰），并用證書中提供的公鑰加密摩渺。
- c) 使用約定好的hash計算握手消息简烤，并使用生成的隨機數(shù)（即密鑰）對消息進行加密，最后將之前生成的所有消息一并發(fā)送給網(wǎng)站服務器证逻。
- 5.網(wǎng)站服務器解析消息乐埠。用已有的私鑰將密鑰解密出來，然后用密鑰解密發(fā)過來的握手消息囚企，并驗證是否跟瀏覽器傳過來的一致。然后再用密鑰加密一段握手消息瑞眼，發(fā)送給瀏覽器龙宏。
-
6.瀏覽器解密并計算握手消息的HASH，如果與服務端發(fā)來的HASH一致伤疙，此時握手過程結束银酗，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證徒像，目的是為了保證雙方都獲得了一致的密碼黍特，并且可以正常的加密解密數(shù)據(jù)，為后續(xù)真正數(shù)據(jù)的傳輸做一次測試锯蛀。
另外灭衷，HTTPS一般使用的加密與HASH算法如下：
非對稱加密算法：RSA，DSA/DSS
對稱加密算法：AES旁涤，RC4翔曲，3DES
HASH算法：MD5迫像，SHA1，SHA256
其中非對稱加密算法用于在握手過程中加密生成的密碼瞳遍，對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密闻妓，而HASH算法用于驗證數(shù)據(jù)的完整性。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關鍵掠械，因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密由缆。非對稱加密算法會生成公鑰和私鑰，公鑰只能用于加密數(shù)據(jù)猾蒂，因此可以隨意傳輸均唉，而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密，所以網(wǎng)站都會非常小心的保管自己的私鑰婚夫，防止泄漏浸卦。
TLS握手過程中如果有任何錯誤，都會使加密連接斷開案糙，從而阻止了隱私信息的傳輸限嫌。正是由于HTTPS非常的安全，攻擊者無法從中找到下手的地方时捌，于是更多的是采用了假證書的手法來欺騙客戶端怒医，從而獲取明文的信息，但是這些手段都可以被識別出來奢讨。
其他參考:http://www.admin5.com/article/20150505/597061.shtml
https://wenku.baidu.com/view/4112d2cf960590c69ec376b4.html
https://wenku.baidu.com/view/b753d97a79563c1ec4da715d.html?from=search
