HTTPS

HTTPS

細心的朋友們可能注意到，愈來愈多的綠色https連接出如今各類網站上，博客園https、開源中國https、百度https、淘寶https等。愈來愈多的瀏覽器地址欄裏多了個帶綠色小鎖的圖標，域名的前綴也由原來的http自動跳轉爲https 開頭，那麼這些網站爲何要從http變成https呢?

HTTP是幹什麼的，它還有哪些不足？
　　HTTP 是一個網絡傳輸協議，是專門用來幫你傳輸 Web 內容 的。大部分網站都是經過 HTTP協議來傳輸 Web 頁面、以及 Web 頁面上包含的各類東西（圖片、CSS 樣式、JS 腳本）。
　　下面說下HTTP的不足：
    　　一、通訊使用明文（不加密），致使內容可能被竊聽（緣由：TCP/IP是可能被竊聽的網絡）
    　　二、部炎症通訊方的身份，所以有可能遭遇假裝
    　　三、沒法證實報文的完整性，因此有可能報文已遭到修改
     更多關於HTTP的知識請戳：http://www.cnblogs.com/foodoir/p/5905946.html
　　由於HTTP中沒有加密機制，後面出現了SSL和TLS的組合使用來加密HTTP這種組合方式，使用的HTTP被成爲HTTPS。

那麼什麼是SSL和TLS組合呢？

　　SSL/TLS全稱「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。由網景公司在上世紀90年代中期設計的。
　　發明這個的緣由是：由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。能夠把這二者並列稱呼（SSL/TLS），由於這二者實際上是同一個東西的不一樣階段（簡單一句話：就是對信息加密傳輸防止被竊取或篡改  。之前叫SSL  後來被標準化後更名爲TLS）。

Http加密方式

一、通訊加密
　　HTTP協議中沒有加密機制，可是能夠經過和SSL（Secure Socket Layer，安全套階層）或 TLS（Transport Layer Security，安全傳輸層協議）的組合使用，加密HTTP的通訊內容，與SSL組合使用的HTTP被稱爲HTTPS，也就是 HTTP Security 或 HTTP over SSL.這個加密只是加密通訊的通道。（注意，這裏說道SSL，那麼要和SSH區分開來，SSH只是加密的shell，最初是用來替代telnet的。經過Telnet 這又聯繫到 FTP ， SFTP ，FTP 就是文件傳輸協議，可是爲了文件的安全和高效因此使用SSH，那就使用 SFTP；他們的端口分別是：Telnet 23 ， FTP 21 ， SFTP 22）
HTTPS並不是應用層的一種新協議。只是HTTP通訊接口部分用SSL和TLS協議替代。一般，HTTP直接和TCP通訊，當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊，簡言之，HTTPS其實就是身披SSL協議這層外殼的HTTP。
　　HTTPS採用對稱和非對稱混合加密機制，首先使用採用非對稱加密，等到驗證經過以後就採用對稱加密，緣由就是對稱加密的效率要高。一開始使用非對稱加密是由於服務器沒法保證密鑰安全送達客戶端，因此採用加密密鑰公開的方式，可是解密密鑰私有。等到這種通訊創建好以後，服務端就能夠安全的把對稱加密的密鑰發送給客戶端了，這樣就能夠採用對稱加密了。可是這裏又有個問題，那就是服務端又如何保證他發送的加密密鑰安全抵達客戶端呢？因此就有了數字證書（CA，Certificate Authority），權威可信機構頒發，通常瀏覽器內嵌這些機構的經常使用公開密鑰，服務端會把證書發送給瀏覽器，而後瀏覽器對證書的數字簽名解密，一旦解密成功，就說明網站是可信的，這樣就能夠保證兩者都是鏈接可信的。

　　補充：
　　　　對稱加密 和 非對稱加密是幹什麼的？
　　　　　　加密：就是把「明文」變成「密文」
　　　　　　解密：就是把「密文」變爲「明文」
　　　　在這兩個過程當中，都須要一個關鍵的東西——叫作「密鑰」
　　　　對稱加密：「加密」和「解密」使用【相同的】密鑰。
　　　　非對稱加密技術：「加密」和「解密」使用【不一樣的】密鑰。

二、內容加密
　　將內容進行加密傳輸，通常只是加密報文主體，報文手部是不加密，這樣依然會帶來被竊取、篡改的問題。固然，這個也是咱們程序中常常須要使用的。

下面請看以下所示的圖：

如圖，咱們來分析HTTPS加密的過程：
1. 客戶端發起HTTPS請求
　　用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。

2. 服務端的配置
　　採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。若是對公鑰和私鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是全世界只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書
　　這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。

4. 客戶端解析證書
　　這部分工做是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨即值。而後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。

5. 傳送加密信息
　　這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

6. 服務段解密信息
　　服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

7. 傳輸加密後的信息
　　這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原

8. 客戶端解密信息
　　客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據，也一籌莫展。

使用HTTPS的優點
【兼容性：】
　　1. HTTPS 仍是要基於 TCP 來傳輸（若是改成 UDP 做傳輸層，不管是 Web 服務端仍是瀏覽器客戶端，都要大改，動靜太大了）

　　2. 單獨使用一個新的協議，把 HTTP 協議包裹起來（所謂的「HTTP over SSL」，其實是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動）打個比方：若是原來的 HTTP 是塑料水管，容易被戳破；那麼現在新設計的 HTTPS 就像是在原有的塑料水管以外，再包一層金屬水管。一來，原有的塑料水管照樣運行；二來，用金屬加固了以後，不容易被戳破。

【可擴展性：】
　　HTTPS 至關因而「HTTP over SSL」。SSL/TLS除了能跟 HTTP 搭配，還可以跟其它的應用層協議搭配。  能夠跟不少經常使用的應用層協議（好比：FTP、SMTP、POP、Telnet）搭配，來強化這些應用層協議的安全性。接着剛纔打的比方：若是把 SSL/TLS 視做一根用來加固的金屬管，它不只能夠用來加固輸水的管道，還能夠用來加固輸煤氣的管道。

【保密性：】
　　HTTPS 須要作到足夠好的保密性。可以對抗嗅探（行話叫 Sniffer）。所謂的「嗅探」，通俗而言就是監視你的網絡傳輸流量。若是你使用明文的 HTTP 上網，就知道你在訪問哪些網站的哪些頁面。
　　HTTPS 還要能對抗其它一些稍微高級的攻擊手法——好比「重放攻擊」

【完整性(防篡改)：】
　　在發明 HTTPS 以前，因爲 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

【真實性(防假冒)：】
　　舉個例子：
　　你由於使用網銀，須要訪問該網銀的 Web 站點。那麼，你如何確保你訪問的網站確實是你想訪問的網站？（這話有點繞口令）
　　有些天真的同窗會說：經過看網址裏面的域名，來確保。爲啥說這樣的同窗是「天真的」？由於 DNS 系統自己是不可靠的（尤爲是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明）。因爲 DNS 的不可靠（存在「域名欺騙」和「域名劫持」），你看到的網址裏面的域名【未必】是真實的！因此，HTTPS 協議必須有某種機制來確保「真實性」的需求。

比較HTTP和HTTPS的區別：

一、HTTPS比HTTP要慢到2到100倍，緣由就是 加密解密耗時，另外SSL通訊部分也會消耗時間。

二、HTTP網絡傳輸不安全。

三、HTTPS自己並不是協議，而是標準的HTTP協議架在SSL/TLS協議之上的一種結構。（所謂的HTTPS其實就是身披SSL協議這層外殼的HTTP）。

相關博文：
　　HTTP協議：http://www.cnblogs.com/foodoir/p/5905946.html

　　Javascript中的Cookie：http://www.cnblogs.com/foodoir/p/5914631.html

　　HTTP首部：http://www.cnblogs.com/foodoir/p/5922480.html