公開密鑰加密技術(shù)
公私鑰加密簡單來說就是提供服務(wù)方有唯一一把私有的密鑰和無數(shù)把公開的密鑰，他把公鑰發(fā)給所有請求服務(wù)的客戶端才写，但只有自己知道并持有私鑰葡兑。通過公鑰加密過的數(shù)據(jù)，只有私鑰才能解開赞草。
公鑰加密的數(shù)據(jù)用私鑰可以解開讹堤，用私鑰加密過的數(shù)據(jù)用公鑰也可以解開。加密和解密其實是雙向的厨疙。后面說到的數(shù)字證書就是服務(wù)端用私鑰加密后洲守，客戶端再用公鑰解密；而客戶端向服務(wù)器端發(fā)送預(yù)主密鑰（premaster secret）的時候又是用服務(wù)器提供的公鑰加密沾凄，服務(wù)器再用私鑰解密梗醇。兩個過程正好是雙向加密解密的過程。
對稱密鑰加密技術(shù)
對稱密鑰就是加密和解密用相同的密鑰撒蟀。和公開密鑰相比叙谨，因為算法相對簡單所以效率比公開密鑰高，而https在經(jīng)過認證過程后便會采用對稱密鑰加密進行通訊保屯。
數(shù)字簽名 & 數(shù)字證書
舉個例子手负，身份證和名片都能體現(xiàn)一個人的姓名等信息，但身份證因為各種技術(shù)原因難以偽造所以可信度極高姑尺，而名片卻相反竟终。
數(shù)字簽名就是一種讓信息擁有較高的可信度的技術(shù)。而數(shù)字證書是帶有具體信息和數(shù)字簽名的一張身份證切蟋。
- 數(shù)字認證機構(gòu)(CA)
一般情況頒發(fā)數(shù)字認證的機構(gòu)越是正規(guī)统捶，所采用的數(shù)字簽名就越不容易被偽造，信息可信度也就越高柄粹。提供服務(wù)方為確保通訊安全喘鸟，會去找正規(guī)的CA為他頒發(fā)數(shù)字認證。
- 數(shù)字簽名
數(shù)字簽名是經(jīng)過加密的字符串镰惦。典型的數(shù)字簽名加密對象包含但不限于：
- 證書格式版本號
- 證書序列號
- 證書簽名算法
- 證書頒發(fā)者
- 有效期
- 提供服務(wù)方的名稱
- 提供服務(wù)方的公開密鑰
其中證書序列號是CA生成的唯一整數(shù)迷守，CA生成的每個證書都要有一個唯一的序列號犬绒。個人理解這個序列號應(yīng)該是用來防止重放攻擊的旺入，保證相同認證機構(gòu)、相同服務(wù)商每次生成的數(shù)字簽名都不可能相同。
提供服務(wù)方的公開密鑰是用作后續(xù)把傳給服務(wù)器的數(shù)據(jù)進行加密的茵瘾。
對以上信息進行加密生成數(shù)字簽名應(yīng)該是個非常復(fù)雜的過程礼华，不知道這輩子有沒有機會去好好學(xué)密碼學(xué)搞清楚……反正最后通過CA密鑰就生成了這么一個非常非常難以破解和偽造的簽名字符串。
數(shù)字證書及認證
把參與數(shù)字簽名加密的對象拗秘，附帶上加密后的數(shù)字簽名圣絮，生成的一組信息，就是數(shù)字證書雕旨。
服務(wù)器將數(shù)字證書發(fā)給客戶端力圖表明正身扮匠，客戶端就要對這個證書進行認證。本質(zhì)上就是校驗解密后的數(shù)字簽名凡涩，和證書上的其他信息是否匹配棒搜。
客戶端瀏覽器一般都會將世界上知名的可信賴的認證機構(gòu)頒發(fā)的公共密鑰事先就存在本地，遇到這些認證機構(gòu)提供的數(shù)字證書的時候活箕，就直接拿著響應(yīng)的公共密鑰對數(shù)字簽名做解密力麸。這樣就可以比對證書上的其他信息判斷證書的真?zhèn)瘟恕?/p>
對于那些非正規(guī)的認證機構(gòu)提供的證書，瀏覽器會給出提示育韩，要求用戶確認是否相信這些非正規(guī)認證機構(gòu)提供的證書克蚂。至于對數(shù)字簽名進行解密的公鑰，是服務(wù)器直接提供還是啥的筋讨，暫時不太清楚埃叭，找大牛們問問去……
SSL
前面說了這么多，都是SSL做的事情版仔。
SSL協(xié)議主要確保幾件事情：
- 服務(wù)器認證：客戶端知道他們是在和真正的服務(wù)器通話游盲；
- 客戶端認證：服務(wù)器知道他在和真正的客戶端通話；
- 完整性：客戶端和服務(wù)器之間傳輸?shù)男畔⒉粫淮鄹模?/li>
- 加密：客戶端和服務(wù)器之間的對話是私密的蛮粮，無需擔(dān)心被竊聽益缎；
SSL協(xié)議建立在HTTP協(xié)議和TCP協(xié)議之間，就是用來保證通訊安全的安全層然想。
- SSL握手
在發(fā)送已加密的http報文之前莺奔，客戶端和服務(wù)器要進行一次SSL握手，流程如下：
- 客戶端生成隨機數(shù)(client random下面簡稱cr)發(fā)送給服務(wù)器变泄；
- 服務(wù)器保存收到的cr令哟，同時生成服務(wù)器隨機數(shù)(server random下面簡稱sr)，并將數(shù)字證書連同sr一起返回給客戶端妨蛹；
- 客戶端保存收到的sr屏富，然后用公鑰對數(shù)字證書進行驗證，認證無誤后蛙卤，根據(jù)cr和sr經(jīng)過一些算法生成一個48位的預(yù)主密鑰(premaster secret下面簡稱ps)狠半，最后將sr+數(shù)字證書+ps一起用服務(wù)器公鑰加密后噩死，發(fā)送給服務(wù)器；
- 服務(wù)器收到加密后的數(shù)據(jù)后神年，用私鑰進行解密從中得到ps已维。
- 此時客戶端和服務(wù)器都擁有了cr，sr和ps已日，安全通道即完成建立垛耳。客戶端和服務(wù)器都通過cr+sr+ps通過相同算法產(chǎn)生共同的會話密鑰(session
key)飘千，后續(xù)通訊即建立在對稱密鑰加密上堂鲜，而無需再使用效率較低的公開密鑰加密。
整個過程借用小胡子哥李靖博客的圖展示一下：
HTTPS
最后再來說下HTTPS护奈。
淘寶泡嘴、百度首頁進去的時候，地址欄最前面都是https://開頭逆济∽糜瑁客戶端遇到這種url，就會打開一條到服務(wù)器端口443（默認情況下）的連接奖慌，然后與服務(wù)器進行SSL握手抛虫，握手完成后，SSL初始化就完成了简僧，客戶端就可以將請求報文發(fā)送給安全層了建椰，而在將這些報文發(fā)送給TCP之前，還要先對其進行加密岛马。
然后棉姐，就不知道還要說什么了……
個人感覺https重點就是SSL，https本身其實就是http+ssl啦逆，理解SSL原理差不多就等于理解HTTPS原理了伞矩。
最后感謝小胡子哥李靖的一片文章，讓我從中理解了一些http權(quán)威指南里沒說得特別清楚的地方夏志。參考：
