“HTTPS協(xié)議的工作原理是什么？”這是我在數(shù)天前工作項(xiàng)目中需要解決的問題。作為一名Web開發(fā)者，我當(dāng)然知道 HTTPS 協(xié)議是保障用戶敏感數(shù)據(jù)的好辦法，但并不知道這種協(xié)議的內(nèi)在工作機(jī)制。它怎么保護(hù)數(shù)據(jù)？有人監(jiān)聽線路的情況下，服務(wù)器與客戶端之間如何建立安全的連接？安全證書又是什么，為什么還要花錢買呢？

一系列通道

在深入講解原理細(xì)節(jié)之前，讓我們首先簡單了解下HTTPS所防范的的問題，以及安全連接為何如此重要吧。在你訪問自己喜歡的站點(diǎn)時(shí)，從你的電腦發(fā)送的請(qǐng)求會(huì)在各個(gè)不同的網(wǎng)絡(luò)之間傳遞——這些網(wǎng)絡(luò)很有可能是用來偷聽，甚至篡改你的信息。

局域網(wǎng)中，信息從你的電腦傳輸?shù)狡渌娔X，傳輸?shù)浇尤朦c(diǎn)，到ISP的路由器、交換機(jī)，最后到達(dá)骨干網(wǎng)線路。這樣的一個(gè)過程中，有許多不同的組織在傳送著你的請(qǐng)求。這時(shí)，如果不懷好意的用戶侵入這條線路之中的任何一個(gè)系統(tǒng)中時(shí)，他們將很有可能看到線路中傳送的內(nèi)容。而一般情況下，Web請(qǐng)求和相應(yīng)都經(jīng)由普通的HTTP協(xié)議明文傳送。HTTP協(xié)議默認(rèn)不使用加密協(xié)議，都是由于這些原因：

• 加密消耗了很多計(jì)算資源。
• 加密占用了更多的傳輸帶寬。
• 加密后緩存機(jī)制會(huì)失效。

不過，Web開發(fā)者會(huì)時(shí)不時(shí)遇到在連接中傳送密碼、信用卡號(hào)等敏感信息的情況。所以，有必要為這些頁面做好防嗅探的準(zhǔn)備措施。

傳輸層安全協(xié)議（TLS）

雖然下面講解的內(nèi)容和密碼學(xué)有關(guān)，但是這里只是一個(gè)簡單的介紹，不熟悉相關(guān)知識(shí)也應(yīng)該看得懂。在實(shí)踐中，是密碼學(xué)算法確保了通信過程的安全，同時(shí)也抵御了潛在的信息黑手——干擾通信和監(jiān)聽的人。

SSL協(xié)議的繼任者——TLS協(xié)議，常被用來實(shí)現(xiàn)安全HTTP連接（HTTPS）協(xié)議。在OSI網(wǎng)絡(luò)模型中，TLS協(xié)議比HTTP協(xié)議的工作更加底層。確切來說，就是TLS的那部分連接發(fā)生在HTTP的連接之前。TLS是一種混合的加密機(jī)制。它具有多種范式，接下來所看到的是對(duì)于這兩種范式（用于共享秘密信息和身份認(rèn)證（確保聲稱的身份和實(shí)際身份一致）的公鑰算法和用于加密請(qǐng)求與回應(yīng)機(jī)密信息的對(duì)稱式算法）的說明：

公鑰加密機(jī)制

使用公鑰加密機(jī)制，雙方各自擁有一份公鑰和一份私鑰，公鑰和私鑰通過數(shù)學(xué)演算聯(lián)系在一起。公鑰用于將明文轉(zhuǎn)化為密文（變成了一堆亂碼），私鑰用來解密這一堆亂碼般的信息。一旦信息被公鑰加密，它將只能由相應(yīng)的私鑰解密。兩者缺一不可，而且也不能反過來使用。公鑰可以自由傳播，無需擔(dān)心系統(tǒng)安全性降低；但私鑰應(yīng)妥善保管，不可將其泄露給未經(jīng)授權(quán)解密的信息的用戶，這就是公鑰和私鑰這兩個(gè)名稱的由來。公鑰機(jī)制相當(dāng)酷的地方在于，通信雙方可以在最初不安全的通道上建立起安全可靠的通信連接?？蛻舳撕头?wù)器都可以使用各自的私鑰，只要共享了一部分公開信息，也就是共用了同一個(gè)公鑰的情況下，就可以建立起相應(yīng)的會(huì)話。這意味著即使有人坐在客戶端或者服務(wù)器前查看連接過程，他們也不會(huì)知道客戶端或者服務(wù)的的私鑰，也不會(huì)知道會(huì)話所共享的密碼。

這得靠什么實(shí)現(xiàn)？靠數(shù)學(xué)！

Diffie-Hellman

這種密鑰交換最常使用是Diffie-Hellman的密鑰交換法。這項(xiàng)過程允許服務(wù)器和客戶端雙方商定共同的保密信息，而不需要在傳輸過程中交換這個(gè)信息。這樣一來，即使嗅探者查看每個(gè)數(shù)據(jù)包，也不能確定連接上傳輸?shù)墓蚕砻艽a是什么。

在最初的DH式密鑰交換發(fā)生之后所生成的共享信息，可以在會(huì)話接下來的通信中使用更簡潔的對(duì)稱式加密法，我們之后就會(huì)看到對(duì)稱式加密法的說明。

一點(diǎn)點(diǎn)數(shù)學(xué)

公鑰算法的特點(diǎn)就是很容易由算子計(jì)算出結(jié)果，而基本上不可能作逆向運(yùn)算。這也就是使用了兩個(gè)質(zhì)數(shù)的所要達(dá)到的目的。

現(xiàn)在假設(shè)Alice和Bob分別是參與DH式密鑰交換過程的兩方，他們一開始會(huì)商議確定一個(gè)小質(zhì)數(shù)（一般是2,3,5這樣的小數(shù)字）和一個(gè)大質(zhì)數(shù)（有300位以上）作為加密的原始信息。小質(zhì)數(shù)和大質(zhì)數(shù)都可以直接傳輸，不必?fù)?dān)心交換過程中的不安全。需要明白的是，Alice和Bob各自都持有著自己的私鑰（100多位的數(shù)），而且也永遠(yuǎn)不應(yīng)該共享自己的私鑰。不光是兩人之間，也包括其他不相關(guān)的人都不應(yīng)該擁有這兩組私鑰。網(wǎng)絡(luò)中傳輸?shù)氖撬麄兊乃借€、小質(zhì)數(shù)和大質(zhì)數(shù)混合運(yùn)算得到的結(jié)果。更確切來說，就是：

• Alice的結(jié)果 = （小質(zhì)數(shù)^{Alice的密碼}）% 大質(zhì)數(shù)
• Bob的結(jié)果 = （小質(zhì)數(shù)^Bob的密碼）% 大質(zhì)數(shù)
• （“%” 符號(hào)表示取模運(yùn)算，即取得除法運(yùn)算的余數(shù)）

所以Alice使用大質(zhì)數(shù)和小質(zhì)數(shù)加上自己的私鑰運(yùn)算，就會(huì)得出結(jié)果，而Bob做同樣的計(jì)算，也能得到相同的結(jié)果。當(dāng)他們接收到對(duì)方的運(yùn)算結(jié)果時(shí)，他們可以由數(shù)學(xué)計(jì)算導(dǎo)出會(huì)話中所要傳輸?shù)男畔ⅲ簿褪钦f：

Alice計(jì)算的是

• （Bob的結(jié)果^{Alice的密碼}）% 大質(zhì)數(shù)

而Bob則計(jì)算

• （Alice的結(jié)果^Bob的密碼）% 大質(zhì)數(shù)

Alice和Bob得出來的數(shù)字相同，這個(gè)數(shù)字也就是會(huì)話中所要共享的密碼。請(qǐng)注意，雙方都沒有向?qū)Ψ絺鬏敻髯缘乃借€，而連接過程中也沒有明文傳遞保密信息。這一點(diǎn)真是太棒了！對(duì)數(shù)學(xué)不好的人而言，維基百科上有一張混合顏料的圖可以用來說明情況：

請(qǐng)注意圖中一開始的顏色（黃色）最后都會(huì)有Alice和Bob的顏色參與計(jì)算。這就是雙方會(huì)得到同樣結(jié)果的原因。對(duì)于觀看中間過程的人來說，唯一在連接中發(fā)送的半合成信息是毫無意義的。

對(duì)稱式加密機(jī)制

每次會(huì)話中只需要產(chǎn)生一次公鑰交換的過程。在接受了同一個(gè)共享保密信息以后，服務(wù)器和客戶端之間會(huì)使用更為高效的對(duì)稱式加密機(jī)制進(jìn)行通信，省去了來回交換的額外花銷。在接受了之前的共享保密信息之后，還會(huì)使用一套密碼機(jī)制（一般是一組加密算法），使用共享的密碼安全地通信，加密解密各自的信息。而竊聽者只會(huì)看到一堆亂碼在傳來傳去。

身份認(rèn)證

DH式密鑰交換允許雙方創(chuàng)建私有的，共有的密碼，但通信雙方怎么確保是真正想要對(duì)話的人呢？這里就涉及到了身份認(rèn)證的問題。假設(shè)我拿起電話，跟我的朋友進(jìn)行DH式密鑰交換，在電話已經(jīng)被干擾的情況，實(shí)際上是在跟其他人交換信息。在使用共享密碼了以后，我仍然可以安全地與“朋友”交換信息，沒有人可以解密我們的通信信息，但是“朋友”并不真的是我的朋友，這可是十分不安全的！要解決身份認(rèn)證問題，需要有配套的公鑰基本設(shè)施，來核實(shí)用戶的真實(shí)身份。這些設(shè)施用來創(chuàng)建，管理，發(fā)布，收回?cái)?shù)字證書。而數(shù)字證書正是你需要為站點(diǎn)使用HTTPS協(xié)議付費(fèi)的惱人事項(xiàng)。但是，什么是數(shù)字證書，數(shù)字證書又是如何保證信息更加安全的呢？

證書

從更高的層次來講，數(shù)字證書是將機(jī)器上的公鑰和身份信息綁在一起的數(shù)字簽名。數(shù)字簽名擔(dān)保某份公鑰屬于某個(gè)特定的組織和機(jī)構(gòu)。證書將域名（身份信息）和特定公鑰關(guān)聯(lián)起來。這就避免了竊聽者將自己的服務(wù)器偽裝成用戶將要連接的服務(wù)器，并進(jìn)行攻擊的行為。在上面打電話的例子中，攻擊者可以嘗試展示自己的公鑰，裝作是你的“朋友”，但是證書上面的簽名信息便顯示出：這份證書不是來自我信任的人的。要受到一般瀏覽器的信任，證書本身還應(yīng)當(dāng)受到CA的信任。CA公司對(duì)認(rèn)證會(huì)進(jìn)行人工核查，確定申請(qǐng)主體滿足以下兩個(gè)條件：

1.  在公共記錄中存在著這個(gè)人/這家公司。
2. 需要簽名的證書上標(biāo)明的域名的確由申請(qǐng)主體實(shí)際控制。

當(dāng)CA查證，得出申請(qǐng)人屬實(shí)，并且的確擁有這個(gè)域名的結(jié)果，CA便會(huì)為證書頒發(fā)簽證，蓋上“已核準(zhǔn)”的戳記，表明網(wǎng)站的公鑰屬于這個(gè)網(wǎng)站，而且可以信任。你的瀏覽器中會(huì)內(nèi)置一系列受信任的CA列表。如果服務(wù)器返回的是未經(jīng)過受信任CA簽證的證書，瀏覽器會(huì)彈出大大的警告，這就在系統(tǒng)中多了一層安全措施，如果不然，任何人都可以四處簽售偽造的證書。

這樣一來，即使攻擊者將自己的公鑰拿出來，生成這份密鑰，聲稱自己的偽造服務(wù)器就是“facebook.com”，瀏覽器也會(huì)因?yàn)闄z查到“未經(jīng)受信任CA簽名的證書”而彈出提示。

一些關(guān)于證書的其他事項(xiàng)

增強(qiáng)式認(rèn)證

在常規(guī)的X.509 證書之外，增強(qiáng)式認(rèn)證證書提供了更強(qiáng)力的認(rèn)證。要授予增強(qiáng)式認(rèn)證證書，CA會(huì)對(duì)域名持有著做更加深入的查驗(yàn)（通常需要提供護(hù)照和水電費(fèi)賬單等信息）。這種類型的證書，瀏覽器中大鎖圖標(biāo)的顯示位置背景也會(huì)變成綠色。

在同一臺(tái)服務(wù)器上運(yùn)行的多個(gè)網(wǎng)站

在HTTP協(xié)議連接開始之前進(jìn)行的TLS協(xié)議握手流程，很有可能存在著多個(gè)網(wǎng)站存放在同一個(gè)服務(wù)器，使用相同IP地址的情況。虛擬主機(jī)的Web路由是由Web服務(wù)器分發(fā)，但是TCP握手的過程，卻是發(fā)生在連接之前。整個(gè)系統(tǒng)的單張證書會(huì)被發(fā)送到服務(wù)器的所有請(qǐng)求之中，這種流程會(huì)在共享主機(jī)的環(huán)境中發(fā)生問題。如果你正在使用Web主機(jī)上提供的服務(wù)，他們會(huì)在你使用HTTPS協(xié)議之前要求使用獨(dú)立的IP地址。不然主體提供商就需要每次在服務(wù)器上有新站點(diǎn)的時(shí)候，取得新證書（并且向CA重新申請(qǐng)認(rèn)證）

原文鏈接：??http://blog.hartleybrody.com/https-certificates/??

譯文鏈接：??http://blog.jobbole.com/45530/??