HTTPS協(xié)議詳細(xì)解釋
HTTPS以保密為目標(biāo)研發(fā)，簡單講是HTTP的安全版。其安全基礎(chǔ)是SSL協(xié)議，因此加密的詳細(xì)內(nèi)容請看SSL。全稱Hypertext Transfer Protocol over Secure Socket Layer。
它是一個URI scheme，句法類同http:體系。它使用了HTTP，但HTTPS存在不同于HTTP的默認(rèn)端口及一個加密／身份驗(yàn)證層（在HTTP與TCP之間）。這個協(xié)議的最初研發(fā)由網(wǎng)景公司進(jìn)行，提供了身份驗(yàn)證與加密通訊方法，現(xiàn)在它被廣泛用于互聯(lián)網(wǎng)上安全敏感的通訊，例如交易支付方面。
SSL極難竊聽，對中間人攻擊提供一定的合理保護(hù)。嚴(yán)格學(xué)術(shù)表述HTTPS是兩個協(xié)議的結(jié)合，即傳輸層SS＋應(yīng)用層HTTP。
HTTPS默認(rèn)使用TCP端口443（HTTP默認(rèn)則是TCP端口80），也可以指定其他TCP端口。
要使協(xié)議正常運(yùn)作，至少服務(wù)器必需有PKI證書，而客戶端則不一定。
它的加密強(qiáng)度依賴軟件的正確實(shí)現(xiàn)，以及服務(wù)器客戶端雙方加密算法的支持。
即便HTTPS被正確實(shí)現(xiàn)，仍有以下人為因素：
冒充網(wǎng)站
釣魚攻擊
制造與原網(wǎng)站相似的假冒網(wǎng)址，并誘導(dǎo)客戶訪問，常見例子是仿制銀行網(wǎng)站。
中間人攻擊
在通訊線路中途篡改證書，從而充當(dāng)網(wǎng)站客戶雙方的中間人，這樣可知道全部通訊內(nèi)容。檢查證書才有可能發(fā)現(xiàn)中間人的存在。
冒充客戶
由于證書費(fèi)用昂貴，通常只有網(wǎng)站服務(wù)器擁有證書。往往客戶身份得不到驗(yàn)證。
在TLS 1.1之前SSL證書僅能對應(yīng)IP，使得HTTPS無法在虛擬主機(jī)（僅有域名）上正常運(yùn)作。現(xiàn)在的TLS 1.1早已完全支持基于域名的虛擬主機(jī)。
HTTPS和HTTP的區(qū)別：
https協(xié)議需要到ca申請證書，一般免費(fèi)證書很少，需要交費(fèi)。
http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議
http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
http的連接很簡單,是無狀態(tài)的
HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議 要比http協(xié)議安全
HTTPS解決的問題：
1 . 信任主機(jī)的問題. 采用https 的server 必須從CA 申請一個用于證明服務(wù)器用途類型的證書. 改證書只有用于對應(yīng)的server 的時候,客戶度才信任次主機(jī). 所以目前所有的銀行系統(tǒng)網(wǎng)站,關(guān)鍵部分應(yīng)用都是https 的. 客戶通過信任該證書,從而信任了該主機(jī). 其實(shí)這樣做效率很低,但是銀行更側(cè)重安全. 這一點(diǎn)對我們沒有任何意義,我們的server ,采用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的數(shù)據(jù)的泄密和被竄改
1. 一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點(diǎn)一樣.
b) 服務(wù)端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產(chǎn)生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.
ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因?yàn)樗麤]有密鑰. 當(dāng)然竄改也就沒有什么意義了.
2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這里客戶端證書,其實(shí)就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認(rèn)證過的身份. 應(yīng)為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認(rèn)自己的身份.
b) 目前少數(shù)個人銀行的專業(yè)版是這種做法,具體證書可能是拿U盤作為一個備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡單的http協(xié)議,一個get一個response. 由于https 要還密鑰和確認(rèn)加密算法的需要.單握手就需要6/7 個往返.
i. 任何應(yīng)用中,過多的round trip 肯定影響性能.
b) 接下來才是具體的http協(xié)議,每一次響應(yīng)或者請求, 都要求客戶端和服務(wù)端對會話的內(nèi)容做加密/解密.
i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.
ii. 加密后數(shù)據(jù)量的影響. 所以，才會出現(xiàn)那么多的安全認(rèn)證提示
