http https ssl/tls三者的區別和聯繫

      一、HTTP的做用  首先，HTTP 是一個專門用來傳輸 Web 內容的網絡協議。咱們常常在訪問網站的時候均可以在瀏覽器地址欄看見HTTP頭協議。如http:// 加粗體的部分就是指HTTP 協議。大部分網站都是經過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各類東東(圖片、CSS 樣式、JS 腳本)。

      二、SSL/TLS   SSL 是英文「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。它是在上世紀90*代中期，由網景公司設計的用於對HTTP協議加密的。由於HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺(嗅探)和篡改。發明 SSL 協議，就是爲了解決這些問*。到了1999*，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那*把 SSL 標準化。標準化以後的名稱改成 TLS(是「Transport Layer Security」的縮寫)，中文叫作「傳輸層安全協議」。不少相關的文章都把這二者並列稱呼(SSL/TLS)，由於這二者能夠視做同一個東西的不一樣階段。SSL 證書就是遵照SSL協議的服務器數字證書，由受信任的證書頒發機構(沃通 CA)驗證服務器身份後頒發 具備網站身份驗證和加密傳輸雙重功能。目前也沃通CA也推出了免費的SSL證書http://freessl.wosign.com

        

 三、HTTPS是什麼  一般所說的 HTTPS 協議就是「HTTP 協議」和「SSL/TLS 協議」的組合，即HTTPS=HTTP+SSL。

      HTTP協議有哪些特色 當前咱們使用的HTTP 協議版本號是 1.1(也就是 HTTP 1.1)。這個 1.1 版本是1995*底開始起草的(技術文檔是 RFC2068)，並在1999*正式發佈(技術文檔是 RFC2616)。在 1.1 以前，還有曾經出現過兩個版本「0.9 和 1.0」，其中的 HTTP 0.9 【沒有】被普遍使用，而 HTTP 1.0 被普遍使用過。據悉，2015IETF 就要發佈HTTP 2.0 的標準。簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議須要依靠 TCP 協議來傳輸數據。在網絡分層模型中，TCP 被稱爲「傳輸層協議」，而 HTTP 被稱爲「應用層協議」。有不少常見的應用層協議是以 TCP 爲基礎的，好比「FTP、SMTP、POP、IMAP」等。TCP 被稱爲「面向鏈接」的傳輸層協議。傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你能夠把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。而且 TCP 協議可以確保，先發送的數據先到達(與之相反，UDP 不保證這點)。HTTP 對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」(又稱「持久鏈接」)。假設有一個網頁，裏面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件。在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼(拿到 HTML 以後，這個 TCP 鏈接就關閉了)。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源(圖片、CSS、JS)。而後針對【每個】外部資源，再分別發起一 個個 TCP 鏈接，把這些文件獲取到本地(一樣的，每抓取一個外部資源後，相應的 TCP 就斷開)相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面。可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着(所謂的「Keep-Alive」)。而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。在 HTTP 1.0 版本，【默認】使用的是「短鏈接」(那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問*不大);到了1995*底開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜(網頁內的圖片、腳本愈來愈多了)。這時候再用短鏈接的方式，效率過低下了(由於創建 TCP 鏈接是有「時間成本」和「CPU 成本」滴)。因此，在 HTTP 1.1 中，【默認】採用的是「Keep-Alive」的方式。

    

    什麼是「對稱加密」和「非對稱加密」

    

   1. 「加密」和「解密」 通俗而言，你能夠把「加密」和「解密」理解爲某種【互逆的】數學運算。就比如「加法和減法」 互爲逆運算、「乘法和除法」互爲逆運算。「加密」的過程，就是把「明文」變成「密文」的過程;反之，「解密」的過程，就是把「密文」變爲「明文」。在這兩 個過程當中，都須要一個關鍵的東西——叫作「密鑰」——來參與數學運算。

   2. 什麼是「對稱加密」 所謂的「對稱加密技術」，意思就是說：「加密」和「解密」使用【相同的】密鑰。這個比較好理 解。就比如你用 7zip 或 WinRAR 建立一個帶密碼(口令)的加密壓縮包。當你下次要把這個壓縮文件解開的時候，你須要輸入【一樣的】密碼。在這個例子中，密碼/口令就如同剛纔說的「密 鑰」。

   3. 什麼是「非對稱加密」 所謂的「非對稱加密技術」，意思就是說：「加密」和「解密」使用【不一樣的】密鑰。這玩意兒比較難理解，也比較難想到。當*「非對稱加密」的發明，還被譽爲「密碼學」歷史上的一次革命。具體相關「非對稱加密」後面再詳細介紹。

   4.「對稱加密」和「非對稱加密」的優缺點 從功能角度而言「非對稱加密」能幹的事情比「對稱加密」要多。這是「非對稱加密」的優勢。可是「非對稱加密」的實現，一般須要涉及到「複雜數學問*」。因此，「非對稱加密」的性能一般要差不少(相對於「對稱加密」而言)。這二者的優缺點，也影響到了 SSL 協議的設計。

   HTTPS 協議的需求 由於是先有 HTTP 再有 HTTPS。因此，HTTPS 的設計者確定要*慮到對原有 HTTP 的兼容性。這裏所說的兼容性包括不少方面。好比已有的 Web 應用要儘量無縫地遷移到 HTTPS;好比對瀏覽器廠商而言，改動要儘量小;...... 基於「兼容性」方面的*慮，很容易得出以下幾個結論： 1. HTTPS 仍是要基於TCP 來傳輸 (若是改成 UDP 做傳輸層，不管是 Web 服務端仍是瀏覽器客戶端，都要大改，動靜太大了)2. 單獨使用一個新的協議，把 HTTP 協議包裹起來 (所謂的「HTTP over SSL」，其實是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本原封不動)  打個比方：若是原來的 HTTP 是塑料水管，容易被戳破;那麼現在新設計的 HTTPS 就像是在原有的塑料水管以外，再包一層金屬水管。一來，原有的塑料水管照樣運行;二來，用金屬加固了以後，不容易被戳破。 【可擴展性】 前面說了，HTTPS 至關因而「HTTP over SSL」。若是 SSL 這個協議在「可擴展性」方面的設計足夠牛逼，那麼它除了能跟 HTTP 搭配，還可以跟其它的應用層協議搭配。如今看來，當初設計 SSL 的人確實比較牛。現在的 SSL/TLS 能夠跟不少經常使用的應用層協議(好比：FTP、SMTP、POP、Telnet)搭配，來強化這些應用層協議的安全性。接着剛纔打的比方：若是把 SSL/TLS 視做一根用來加固的金屬管，它不只能夠用來加固輸水的管道，還能夠用來加固輸煤氣的管道。 【保密性】 HTTPS 須要作到足夠好的保密性。說到保密性，首先要可以對抗嗅探(行話叫 Sniffer)。所謂的「嗅探」，通俗而言就是監視你的網絡傳輸流量。若是你使用明文的 HTTP 上網，那麼監視者經過嗅探，就知道你在訪問哪些網站的哪些頁面。嗅探是最低級的攻擊手法。除了嗅探，HTTPS 還須要能對抗其它一些稍微高級的攻擊手法——好比「重放攻擊」。【完整性】 除了「保密性」，還有一個一樣重要的目標是「確保完整性」。在發明 HTTPS 以前，因爲 HTTP 是明文的，不但容易被嗅探，還容易被篡改。舉個例子：好比天朝的網絡運營商(ISP)都比較流氓，常常有網友抱怨說訪問某網站(原本是 沒有廣告的)，居然會跳出不少中國*信的廣告。爲啥會這樣捏?由於你的網絡流量須要通過 ISP 的線路才能到達公網。若是你使用的是明文的 HTTP，ISP 很容易就能夠在你訪問的頁面中植入廣告。因此，當初設計 HTTPS 的時候，還有一個需求是「確保 HTTP 協議的內容不被篡改」。【真實性】 在談到 HTTPS 的需求時，「真實性」常常被忽略。其實「真實性」的重要程度不亞於前面的「保密性」和「完整性」。舉個例子：你由於使用網銀，須要訪問該網銀的 Web 站點。那麼，你如何確保你訪問的網站確實是你想訪問的網站。有些天真的同窗會說：經過看網址裏面的域名，來確保。爲啥說這樣的同窗是「天真的」?由於 DNS 系統自己是不可靠的(尤爲是在設計 SSL 的那個*代，連 DNSSEC 都還沒發明)。因爲 DNS 的不可靠(存在「域名欺騙」和「域名劫持」)，你看到的網址裏面的域名【未必】是真實滴!因此，HTTPS 協議必須有某種機制來確保「真實性」的需求。【性能】 引入 HTTPS 以後，【不能】致使性能變得太差。不然的話，誰還願意用?爲了確保性能，SSL 的設計者至少要*慮以下幾點： 如何選擇加密算法(「對稱」or「非對稱」)? 如何兼顧 HTTP 採用的「短鏈接」TCP 方式?  (SSL 是在1995*以前開始設計的，那時候的 HTTP 版本仍是 1.0，默認使用的是「短鏈接」的 TCP 方式——默認不啓用 Keep-Alive)  設計 HTTPS 協議的主要難點 設計 HTTPS 這個協議，有好幾個難點。我的認爲最大的難點在於「密鑰交換」。在傳統的密碼學場景中，假如張三要跟李四創建一個加密通信的渠道，雙方事先要約定好使用哪 種加密算法?同時也要約定好使用的密鑰是啥?在這個場景中，加密算法的【類型】讓旁人知道，沒太大關係。可是密鑰【千萬不能】讓旁人知道。一旦旁人知道了 密鑰，天然就能夠破解通信的密文，獲得明文。當你訪問某個公網的網站，你的瀏覽器和網站的服務器之間，若是要創建加密通信，必然要商量好 雙方使用啥算法，啥密鑰。——在網絡通信術語中，這個過程稱之爲「握手/handshake」。在握手階段，由於加密方式尚未協商好，因此握手階段的通 訊一定是明文!既然是明文，天然有可能被第三方偷窺到。而後，還要*慮到雙方之間隔着一個互聯網，什麼樣的偷窺均可能發生。所以，在握手的過程當中，如何作 到安全地交換密鑰信息，而不讓周圍的第三方看到。這就是設計 HTTPS 最大的難點。HTTPS和SSL支持使用X.509數字認證，若是須要的話用戶能夠確認發送者是誰。 https協議須要到ca申請證書，通常免費證書不多，須要交費。  http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全  1 . 信任主機的問*. 採用https 的server 必須從CA 申請一個用於證實服務器用途類型的證書.改證書只有用於對應的server 的時候,客戶度纔信任次主機.因此目前全部的銀行系統網站,關鍵部分應用都是https 的.客戶經過信任該證書,從而信任了該主機.其實這樣作效率很低,可是銀行更側重安全. 這一點對咱們沒有任何意義,咱們的server ,採用的證書無論本身issue 仍是從公衆的地方issue, 客戶端都是本身人,因此咱們也就確定信任該server. 1. 通常意義上的https, 就是 server 有一個證書.  i. 具體講,是客戶端產生一個對稱的密鑰,經過server 的證書來交換密鑰. 通常意義上的握手過程. ii. 加下來全部的信息往來就都是加密的. 第三方即便截獲,也沒有任何意義.由於他沒有密鑰. 固然竄改也就沒有什麼意義了. 2. 少量對客戶端有要求的狀況下,會要求客戶端也必須有一個證書.  a) 這裏客戶端證書,其實就相似表示我的信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應爲我的證書通常來講上別人沒法模擬的,全部這樣可以更深的確認本身的身份. b) 目前少數我的銀行的專業版是這種作法,具體證書多是拿U盤做爲一個備份的載體.  a) 原本簡單的http協議,一個get一個response. 因爲https 要還密鑰和確認加密算法的須要.單握手就須要6/7 個往返.  i. 任何應用中,過多的round trip 確定影響性能. i. 儘管對稱加密/解密效率比較高,但是仍然要消耗過多的CPU,爲此有專門的SSL 芯片. 若是CPU 信能比較低的話,確定會下降性能,從而不能serve 更多的請求.