什么是https？？

wikipedia的解釋是：

超文本傳輸安全協(xié)議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進行通信，但利用SSL/TLS來加密數(shù)據(jù)包。HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務(wù)器的身份認證，保護交換數(shù)據(jù)的隱私與完整性

我們再來看看網(wǎng)絡(luò)安全的幾個基本問題?？梢源致缘姆殖伤膫€相互交織的領(lǐng)域：

• 保密

  它的任務(wù)是確保信息不會被未經(jīng)授權(quán)的用戶訪問

• 認證

  當你在展示敏感信息或者進入電子商務(wù)交易之前你必須要確定自己在和誰通話

• 不可否認

  契約的任何一方不能否認自己曾經(jīng)簽過名的特性

• 完整性控制

  用來確定你收到的信息是真實的而不是被惡意攻擊者在傳輸圖中篡改過的偽造信息

所以，理論上說將這四個問題解決就可以形成一個網(wǎng)絡(luò)安全的實現(xiàn)。而https是一個典型的網(wǎng)絡(luò)安全問題解決方案，前面定義中涉及到的SSL/TLS加密、身份認證、完整性等也都和這幾個問題呼應(yīng)。下面介紹基本的密碼學(xué)原理。

有哪些密碼學(xué)原理？？

保密——加密算法

密碼學(xué)眾所周知有兩種典型的加密技術(shù)：

對稱密鑰加密技術(shù)

發(fā)送端和接收端要共享相同的密鑰k才能進行通信，發(fā)送端接收端用共享的密鑰來加密報文和恢復(fù)報文，流行的對稱密鑰算法包括：DES、Triple-DES、AES，RC2和RC4

算法的細節(jié)我們不用考慮，不過很顯然，對稱加密的弱點就在于密鑰的管理。

對稱密鑰加密技術(shù)的缺點之一就是發(fā)送者和接收者在互相對話之前一定要有一個共享的保密密鑰，如果有N個節(jié)點每個節(jié)點都要和其他所有N-1個節(jié)點進行安全對話，總共大概會有N的平方個保密密鑰，這將是一個管理噩夢。

同時，加密安全性依賴于密鑰本身的安全性，共享密鑰的環(huán)節(jié)密鑰一旦泄露再健壯的算法也會被瞬間攻破。

對稱密鑰泄露

公開密鑰加密技術(shù)

針對對稱密鑰的缺點，公開密鑰加密技術(shù)應(yīng)運而生：

沒有對每對主機使用單獨的加密/解密密鑰，而是使用了兩個（非對稱）密鑰：一個用來對主機報文編碼，另一個用來對主機報文解碼。編碼密鑰是眾所周知的（這也是公開密鑰加密這個名字的由來），但只有主機才知道私有的解密密鑰，這樣每個人都能找到特定主機的公開密鑰編碼，而只有接收端才能對發(fā)送給它的報文進行解碼

即——<u>公鑰加密，私鑰解密</u>。A和B每個主機有自己的公鑰，也有自己的私鑰，B想要給主機A發(fā)送報文，B就用主機A的公鑰進行加密，然后傳遞給A，A再利用自己的私鑰進行解密就可以了。反之亦然。對于一個接受者來說，任何人都可以用我分發(fā)出去的公鑰加密，但是加密之后只有我才能解密。這個方法解決了共享密鑰產(chǎn)生的密鑰安全性問題。

非對稱加密算法

典型的非對稱加密算法是RSA。

同樣我們不需要知道算法的細節(jié)，但是要了解的是，非對稱加密的缺點就是速度很慢，如果數(shù)據(jù)都使用非對稱加密進行編碼傳輸效率會非常低。

上述的SSL/TLS本身并不是加密算法，他們是一組安全協(xié)議，構(gòu)成網(wǎng)絡(luò)協(xié)議棧當中的一個安全層。這個安全層提供一種機制讓收發(fā)雙方進行參數(shù)協(xié)商，認證，保密通信，數(shù)據(jù)的完整性保護等等，稍后會詳細說明。

完整性——數(shù)據(jù)校驗和

加密提供了對明文保密的機制，不過它并不能保證發(fā)送內(nèi)容不被篡改。比如A向B發(fā)送加密數(shù)據(jù)，攻擊者C雖然不能解密A發(fā)送的密文信息，但是可以自己隨意用B的公鑰加密一段密文或者在鏈路上竊取一段密文替換部分真實的A密文，從而破壞信息的正確性和完整性。那么如何做到被加密之后還不能被篡改呢？

對于保證數(shù)據(jù)完整性，密碼學(xué)給出的典型方案就是為明文計算一個校驗和或者叫摘要的信息（又叫指紋信息），目前比較流行摘要有MD5，SHA1等等，它們能生成一個數(shù)據(jù)完整性的校驗和（MAC），和密文一并發(fā)送出去。接收方拿到密文解密之后，用同樣的算法計算校驗和傳過來的校驗和比對，即可知道數(shù)據(jù)是否被篡改。加密內(nèi)容與校驗和是互校驗的，在加密算法安全的條件下，整個密文與校驗和是配套的，二者任何一處被修改都能被檢驗出來。

校驗和

可是緊接著問題又來了，如果報文并非期待的對象發(fā)出，而是攻擊者擅自發(fā)出的加密報文，整個報文都是假的呢？

認證與不可否認——數(shù)字簽名

簽名的原理我們都理解，它用來證明文件是出自簽名者本人，對于文件的接受人來說它具有認證的作用（確認文件的來源），對于文件的起草者有不可否認的作用（對于文件出自他不能抵賴）。

那么在網(wǎng)絡(luò)環(huán)境中有沒有什么辦法起到“簽名”或者“按手印”這樣的作用呢。當然有，也就是我們經(jīng)常聽到的一個詞叫“數(shù)字簽名”。

還記得剛剛講到的公開密鑰加密算法嗎，比如RSA，它的加密方式是公鑰加密，私鑰解密。但是RSA算法也支持相反的一種工作方式，即<u>私鑰加密，公鑰解密</u>（私鑰加密的數(shù)據(jù)，只有對應(yīng)的公鑰可以解開）。你可能困惑，這還加什么密啊，人人都能解密。的確是這樣，所以這種工作方式不在于向?qū)Ψ絺鬟f加密數(shù)據(jù)，而是為了說明數(shù)據(jù)的來源，如果一段密文能夠用公鑰正確解密說明這個數(shù)據(jù)就是來自于私鑰屬主，這恰恰是數(shù)字簽名的一種典型實現(xiàn)。

數(shù)字簽名

有了數(shù)字簽名，之前完整性校驗留下的問題是不是可以解決了？假設(shè)A需要發(fā)送一個報文，現(xiàn)在的報文結(jié)構(gòu)是密文+校驗和，如果我在此基礎(chǔ)上將校驗和用A的私鑰加密（也就是添加A的簽名），看看是什么效果：

對于攻擊者C來說，他拿到這樣一個報文，首先他并不能解密密文（假設(shè)算法與密鑰安全），其次他也不能篡改這個報文的任何一部分（加密密文，簽名的校驗和），因為這兩部分是互校驗的，同時他也不能偽造整個報文，因為他不可能對校驗和有正確的簽名（沒有正確私鑰）。由此可見加密+校驗和+數(shù)字簽名的方案很好的解決了破解、篡改與偽造的問題。

所以數(shù)字簽名也可以簡單的理解成：<u>對校驗和進行私鑰加密</u>。

這個思路距離https實際的工作過程已經(jīng)很接近了，不過之前我們一直有個問題沒考慮清楚。就是到底

采用哪一類加密算法？？

如果使用對稱加密算法，并且存儲通訊對象的密鑰，那么管理成本非常大，也很危險。如果每次通信都交換密鑰，密鑰泄露的風(fēng)險就變得更大。但是反過來一旦安全交換了密鑰，加密通信性能會比較好。同時對稱加密由于密鑰只關(guān)系到雙方，所以約定密鑰的人可以采用一個隨機值，這樣安全交換密鑰之后，雙方可以不對自己的報文簽名也能驗證起到認證的作用。

如果使用非對稱加密算法，在密鑰安全性方面相比對稱加密會好很多（依賴獲取的公鑰的安全性），但是每次通信獲取對方公鑰的成本會很高，同時加密解密的性能會很差。因為本身算法性能就差，而且非對稱加密的接受方每次必須通過簽名確認報文的屬主。于是發(fā)送方必須在發(fā)送報文時添加簽名，也就是說每個報文發(fā)送方要做兩次加密，接收方要做兩次解密。這種性能肯定是不能忍的。

所以對于這兩個矛盾又互補的方案來說，最好的辦法就是將它們結(jié)合起來使用，因此，現(xiàn)實中https的方案：

是在兩個節(jié)點之間通過便捷的公開密鑰加密技術(shù)建立起安全通信，然后再用那條安全的通道產(chǎn)生發(fā)送臨時的隨機對稱密鑰，通過更快的對稱加密技術(shù)對其余的數(shù)據(jù)進行加密

更簡單一點理解，就是用<u>非對稱加密傳輸對稱加密的密鑰，然后用對稱加密通信</u>。

采用哪一類加密算法

假設(shè)A發(fā)起與B的通信，首先A獲取B的公鑰（先用非對稱加密），然后A告訴B，“自己要用AES算法進行對稱加密，密鑰是xxx”，這個密鑰是一個隨機數(shù)，然后這條報文用B的公鑰加密傳給B，這條報文只有B能解密所以很安全，緊接著A和B就采用AES和約定的隨機密鑰加密報文，愉快的通信起來……

居然阻止不了“中間人攻擊”

這個方法看起來天衣無縫，首先用非對稱加密解決了對稱加密密鑰交換的問題，對稱加密解決了性能問題，還不用每個報文都添加簽名認證……如果說還有什么不安全的地方，對，聰明的你一定發(fā)現(xiàn)了，那就是獲取公鑰時的安全性。

還是剛才那個完全一樣的過程，只是第一步A獲取B公鑰時出現(xiàn)了問題，假設(shè)A在四處打聽B的公鑰是什么，這時候攻擊者C跳出來說，我是B，我的公鑰是kkk，A很天真的相信了C的話，用kkk加密把密鑰給了C然后把跟B通信的內(nèi)容都發(fā)給了C，和C愉快的通信起來……

更過分的是C可能不一定會露出馬腳讓A發(fā)現(xiàn)他是偽裝者，他這邊與A建立通信之后反手又冒充A與真正的B建立通信，收到A的信息之后轉(zhuǎn)發(fā)給B，B回傳的響應(yīng)再轉(zhuǎn)發(fā)給A，他就這樣神不知鬼不覺的將AB之間的通信盡收眼底，時不時還能再添點油加點醋，前面研究半天的加密措施，全都被繞過了！

中間人攻擊

由此可見，公鑰的安全管理非常重要，一旦拿到的是假公鑰那么連簡單的“中間人攻擊”都抵擋不了，前面利用那么多加密認證手段都前功盡棄了。

可是，非對稱加密以及后續(xù)全套加密全部工作就是建立在對所持公鑰的信任基礎(chǔ)上，我去哪拿安全的公鑰呢，拿到公鑰的可信度又由誰來保證呢？

數(shù)字證書——由一個可信組織簽名擔保公鑰安全性

又是一個熟悉的名詞，“數(shù)字證書”：

數(shù)字證書中包含了由某個受信任組織擔保的用戶或公司的相關(guān)信息。數(shù)字證書中還包含一組信息，所有這些信息都是由一個官方的“證書頒發(fā)機構(gòu)”已數(shù)字方式簽發(fā)的。有一些常見的內(nèi)容

• 對象的名稱（這個證書所描述的實體，人、服務(wù)器、組織等）
• 過期時間
• 證書發(fā)布者（由誰為證書擔保）
• <u>來自證書發(fā)布者的數(shù)字簽名</u>
• <u>對象的公開密鑰</u>
• 對象和所用的簽名算法的描述性信息

可以這么理解，<u>數(shù)字證書上面寫著你要通信的服務(wù)器的公鑰，同時這個證書加上了一個權(quán)威擔保機構(gòu)的簽名</u>，證明這個公鑰的真實性。

也就是說，A現(xiàn)在要和B服務(wù)器進行安全通信，不需要四處尋找B的公鑰了，B會給A發(fā)送一個證書過來，其實就是一張名片，上面寫著我是誰誰誰，地址在哪，公鑰是多少，上面還蓋著一個“世界超級值得信任評估委員會”的大印。

A肯定會懷疑“世界超級值得信任評估委員會”是個什么鬼？因為這個擔保機構(gòu)可信度不高。由此可見，無論是人還是協(xié)議都得有一個信任的衡量標準，什么“世界”，什么“大機構(gòu)”都是空話。

證書與根證書

對于服務(wù)器發(fā)過來的證書，瀏覽器的信任標準，就在機器的本地。每臺機器的操作系統(tǒng)當中都安裝了很多的“根證書”，這些是權(quán)威機構(gòu)給自己頒發(fā)的，<u>不需要其他人擔保的證書</u>。它上面的內(nèi)容也是有信譽的大機構(gòu)（CA組織）的公鑰。根證書只要安裝到機器當中，瀏覽器（客戶端）就無條件認為上面的公鑰是可信的，而這些公鑰的作用就是驗證服務(wù)器發(fā)送過來的證書的簽名。比如上述“世界超級值得信任評估委員會”的簽名，如果我的機器上安裝有該機構(gòu)的根證書，那么我就認為這個簽名是可信任的，然后就可以建立后續(xù)的安全通信了。

很多時候我們收到的證書并不只有一個，而是一組，比如一個B公司的站點給我一個證書，上面是B公司的信息，簽名是一個C機構(gòu)的，也就是由C機構(gòu)擔保（記作：<B,C>），而這組證書當中還有兩個證書<C,D>和<D,E>，校驗簽名的時候C，D公司的簽名我都不認識（本地沒有二者的根證書），但是E的簽名我認識并認為可信，因為我安裝了E的根證書。所以這就形成了一個“擔保鏈”：E擔保D擔保C擔保B，出于對E的信任最終也信任了B，這組證書叫做“證書鏈”。沒有從根證書發(fā)布機構(gòu)而是從其授權(quán)機構(gòu)申請的證書，都需要通過“證書鏈”的方式發(fā)送給接收者。

至此，https當中的關(guān)鍵概念都幫助大家掃盲了一遍。下面再說https的工作過程應(yīng)該就很好理解了。

HTTPS工作過程

https特殊的工作過程體現(xiàn)在SSL/TLS層上，它建立在HTTP應(yīng)用層協(xié)議之下作為一個安全服務(wù)層，因此對于HTTP本身完全是透明的。因為在處理HTTPS流量時需要額外的安全層操作（加解密、驗證簽名、校驗等），所以tcp連接選擇建立在服務(wù)器的443端口上，與http的80端口作以區(qū)分。

SSL是安全套接層（Secure Sockets Layer），由網(wǎng)景公司于1994年提出，隨后SSL3.0由IETF進行了標準化，發(fā)布了TLS（Transport Layer Security），二者差異很小，以下用SSL代指安全層。

對于SSL來說兩部分協(xié)議比較重要，一部分是“SSL握手協(xié)議”，一部分是“SSL記錄協(xié)議”。

SSL握手協(xié)議：

Note：上述消息5中，發(fā)送的是一個隨機的384位預(yù)設(shè)主密鑰，而真正的通信對稱密鑰是雙方用主密鑰與上面的兩個隨機數(shù)推導(dǎo)出來的。

經(jīng)過握手以后，雙方就可以進行安全通信了，通信過程需要經(jīng)過SSL記錄協(xié)議來完成：

SSL記錄協(xié)議：

SSL記錄協(xié)議

總結(jié)

對于https來說，其實就是靈活地將密碼學(xué)當中的諸多原理“拼裝”形成的一個安全方案。報文加密可以解決保密問題，數(shù)據(jù)校驗和可以解決完整性問題，數(shù)字簽名可以解決身份認證與不可否認問題。

https握手過程 1.確認具體算法 2.服務(wù)端（用證書）發(fā)送自己的公鑰 3.客戶端用<u>服務(wù)端公鑰</u>加密<u>對稱算法密鑰</u>發(fā)送給服務(wù)端 4.二者用對稱密鑰通信

其中，非對稱加密只在握手過程中只進行了一次，其余所有傳輸都用對稱加密。這個方案兼顧防止對稱密鑰泄露，同時避免了非對稱加密中認證和算法本身的額外性能開銷。

證書相當于告知一個公鑰，但是帶著一個ca組織的簽名，如果客戶端機器上安裝了對應(yīng)組織的根證書，那么這個證書上所有信息（最重要）相當于可信任，防止“中間人攻擊”。

以上就是SSL的基本工作過程，本文省略了很多技術(shù)細節(jié)，強調(diào)安全傳輸?shù)恼w思路，希望能對大家理解https與網(wǎng)絡(luò)安全相關(guān)知識有一些幫助。