HTTP和HTTPS協議

介紹

http[1]是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫，是一種應用層協議，可用於將超文本服務器中文本、圖片、音視頻等內容傳輸到客戶端瀏覽器。

構建與互聯網之上的萬維網，其主要組成部分就是http協議。目前使用的最廣泛的http協議版本是http1.1。

最初的HTTP協議是萬維網1991年誕生時，蒂姆·伯納斯·李爵士（Sir Tim Berners-Lee）在European Organization for Nuclear Research使用的協議。之后萬維網協會（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作，並最終發布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了我們今天普遍使用的HTTP協議的一個版本——HTTP1.1。

在TCP/IP參考模型中和OSI參考模型中，http協議處於應用層的位置，http規定了客戶端和Web服務端的通信協議，而html則規定了傳輸的內容的格式、類型。https是在http的基礎上，增加了TLS/SSL協議，為通信內容進行加密操作。

http通信過程

http協議默認使用TCP的80端口進行通信。通過在瀏覽器中輸入網站地址，URL (Uniform Resource Locator，統一資源定位符)[2]，發起http請求。

URL由三部分組成：資源類型、存放資源的主機域名、資源文件名。URL的一般語法格式為：

protocol:// hostname[:port]/path/[;parameters][?query]#fragment

其中帶方括號[]的為可選項。

使用http協議，則url可以表示為

http://www.xxx.com/index.html?type=main。

在一次完整的http通信中，會經過如下幾個過程[3]：

1. 瀏覽器向服務器發起tcp鏈接。通過url中的hostname[:port]信息，同響應的web服務器建立tcp通信連接。在此之前，還可能需要使用DNS協議，完成hostname到ip地址的轉換。http是比tcp/ip更高層次的協議，只有當tcp連接建立之后才能進行http通信。http通信協議一般使用tcp的80端口，https一般使用tcp的443端口。
2. 瀏覽器向服務器發送請求命令。tcp連接建立后，瀏覽器會向服務器發送請求命令，末尾追加一個換行符\n，例如GET /index.html  HTTP/1.1。常見的http請求方法有GET和POST。
3. 瀏覽器向服務器發送請求頭。瀏覽器發送完請求命令后，還要以請求頭的方式向服務器發送一些輔助信息，這些信息以“鍵:值”的形式構成了請求頭，每一個鍵值對通過換行符\n分隔，請求頭發送完后后，再發送一個空白行表示請求頭發送完畢。
4. 瀏覽器向服務器發送請求體。當瀏覽器進行POST操作時，發送完請求命令和請求頭之后，還會以content-type請求頭描述的形式發送請求體內容。請求體的長度在請求頭content-length中有表明，服務器可通過此值獲取全部請求體。
5. 服務器發送應答狀態。服務器接收到瀏覽器發送的請求命令和請求頭后，進行http協議判斷，請求內容查詢，請求頭邏輯判斷等操作，向瀏覽器發送應答狀態，末尾追加\n換行符，例如HTTP/1.1 200 OK。
6. 服務器發送應答頭。服務器關於某一次瀏覽器請求的應答，還包含一些關於本次應答的而外信息，此信息以應答頭的方式發送給瀏覽器。應答頭的格式同請求頭的格式相同，應答頭發送完畢后，再發送一個空白行表示應答頭發送完畢。
7. 服務器發送應答數據。服務器發送完應答頭后，會根據應答頭中描述的content-type和content-length描述的形式，發送應答數據。
8. 服務器關閉tcp連接。一般情況下，服務器傳輸完數據后，便會主動關閉tcp連接。如果請求頭中包含“connection:keep-alive”信息，服務器則會在數據發送完畢后，仍保持tcp的打開狀態，使得后續的http請求節省了tcp連接建立的時間，同時也節省了網絡帶寬。

請求體和應答數據，都是二進制數據。通過content-type指定其格式內容以及編碼。

關於http的具體信息可參考HTTP 教程中的內容。

http的缺點

http的簡答方便，在網絡應用中廣發使用，同時http還是存在着缺點的[4]。

1. 通信使用明文（不加密），內容可能會被竊聽。由於http協議的所有內容，都是以明文的方式進行傳輸的，不僅可以被惡意竊聽，並且可以竊聽到傳輸內容的具體含義，如果傳輸內容進行了加密，則只能被惡意竊聽，但需要經過復雜的手段才能獲得傳輸的具體內容。
2. 不驗證通信方的身份，因此有可能遭遇偽裝、冒充。
3. 無法證明報文的完整性，所以有可能已遭篡改。
4. 這些問題不僅在HTTP上出現，其他未加密的協議中也會存在這類問題。

為了解決http的以上問題，瀏覽器可以使用https對http的所有內容進行加密，保證了

1. 所有數據都是經過加密后進行傳輸，無法被第三方竊聽到傳輸的真正內容；
2. 由於配備了身份證書，防止了客戶端或服務端的身份被冒充；
3. 由於傳輸內容校驗機制的存在，可發現傳輸的內容被篡改。

https

https並非是應用層的一種新協議，它只是在http通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議代替而已。

瀏覽器使用http時，直接同tcp通信；當瀏覽器使用https時，瀏覽器會先同TLS/SSL進行通信，然后TLS/SSL再同tcp進行通信。

在使用TLS/SSL后，http便擁有了加密功能。TLS/SSL是獨立於http的協議，所以其也可以同應用層的其他協議配合使用。

TLS/SSL[5] 

SSL由從前的網景公司開發，有1,2,3三個版本，但現在只使用版本3。

TLS是SSL的標准化后的產物，有1.0 1.1 1.2三個版本。主流瀏覽器都已經實現了TLS 1.2的支持。

TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。SSL是TLS舊的稱呼。

由於習慣問題，雖然現在都是使用TLS，但一直統稱為TLS/SSL。

加解密基礎知識

對傳輸內容進行加密，是增加http通信安全的第一步。

可以采用對稱加密（DES，AES），也可以采用非對稱加密（RSA，DSA）。此外還有數字簽名技術（MD5，SHA）。

對稱加密相比非對稱加密，速度更快，需要的計算量更少。

https通信流程

1. 當瀏覽器向服務器請求一個安全的網頁(通常是 https://) 時，服務器就把它的數字證書和公匙發送給瀏覽器。
2. 瀏覽器檢查證書是不是由可以信賴的機構頒發的，檢查證書的數字簽名是不是正確，確認證書有效和此證書是此屬於指定網站的。 
3. 瀏覽器使用證書中提供的公鑰加密一個隨機生成對稱密鑰，並用此對稱密鑰對http協議請求內容進行加密，加密后的信息一起發送到服務器。
4. 服務器用自己的私匙解密瀏覽器發送過來的對稱鑰匙，然后用這把對稱加密的鑰匙解密加密過的http協議請求內容。 
5. 服務器用對稱鑰匙對http協議響應內容進行加密，並發送給瀏覽器，瀏覽器通過對稱密鑰解密加密信息，獲得http協議的響應內容。  

https通信過程中使用到了對稱加密、非對稱加密和數字簽名技術。

其中非對稱加密，在目前已有算力的情況下是無法破解的。原理是，兩個大素數相乘十分容易，但想要對其乘積進行因式分解卻極其困難。這兩個大素數，就是非對稱加密中的公鑰、私鑰。

在未使用數字證書保證服務端的公鑰正確性時，依然存在中間人攻擊的可能性，只要中間人作為客戶端同實際服務端進行通信，作為服務端同實際客戶端進行通信即可。客戶端沒有任何方法判斷服務端發送過來的公鑰是否為真正的公鑰。於是在https通信中，使用到了數字證書，用於保證客戶端可以獲得正確的服務端公鑰。

數字證書[6]

數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。數字證書還有一個重要的特征就是只在特定的時間段內有效。

數字證書是一種權威性的電子文檔，可以由權威公正的第三方機構，即CA（例如中國各地方的CA公司）中心簽發的證書，也可以由企業級CA系統進行簽發。

頒發過程

數字證書頒發過程一般為：

1. 用戶首先產生自己的密鑰對，並將公共密鑰及部分個人身份信息傳送給認證中心。
2. 認證中心在核實身份后，將執行一些必要的步驟，以確信請求確實由用戶發送而來。
3. 認證中心將發給用戶一個數字證書，該證書內包含用戶的個人信息、公鑰信息，以及使用認證中心公鑰計算獲得的用戶的個人信息和公鑰的數字摘要的數字簽名，認證中心的信息。

數字證書原理[7]

客戶端獲得了數字證書，通過使用認證中心的公鑰對證書中用戶的跟人信息以及公鑰信息的數字摘要進行解密，獲得數字簽名，同證書中的數字簽名進行對比，即可驗證此證書的正確性。

通過證書認證鏈，可以獲得指定認證中心的公鑰。

證書中有頒發者的信息，以及其認證中心的信息，通過此種方式，可以獲得一個認證中心的認證鏈。

在認證鏈的最頂端是根認證中心，根認證中心的數字證書一般都是已經內置在操作系統或者瀏覽器中了，表示對此證書的絕對信任。

通過根證書可以驗證其子認證中心的證書的正確性，從而獲得子認證中心的公鑰，以此類推，直到獲得指定認證中心的公鑰。

數字簽名

將指定報文按雙方約定的HASH算法計算得到一個固定位數的報文摘要。在數學上保證：只要改動報文中任何一位，重新計算出的報文摘要值就會與原先的值不相符。這樣就保證了報文的不可更改性。

將該報文摘要值用發送者的私人密鑰加密，然后連同原報文一起發送給接收者，而“加密”后的報文即稱數字簽名。

接收方收到數字簽名后，用同樣的HASH算法對原報文計算出報文摘要值，然后與用發送者的公開密鑰對數字簽名進行解密得到的報文摘要值相比較。

如相等則說明報文確實來自所稱的發送者。

由於RSA加解密非常耗時，被加密的報文越大，耗得時間越多，因此對報文摘要進行加密，仍然能夠起到同樣的作用。這就是為什么多了個報文摘要。

相關文件后綴

* 證書：.crt .cer .pem
* 私鑰：.key
* 證書請求：.csr

把證書和私有key 放到同一個文件里邊，這時候擴展名通常叫.pem。Java的keystore是自有格式。在生成私鑰公鑰后，如果需要申請證書，需要生成csr文件。

https實踐

通過以上內容，能夠初步了解https以及數字證書的工作原理。

在https通信中，比原有的http通信，多了三個元素：公鑰、私鑰、證書。其中證書包含公鑰內容。

tomcat啟用https

1、首先使用jdk自帶的keytool工具生成證書。[8]

在windows的powershell或者linux的shell中，鍵入一下命令（keystore是證書保存位置）

keytool -genkeypair -alias "tomcat" -keyalg "RSA" -keystore "D:\tomcat.keystore" 

根據提示輸入必要的信息。　　

密鑰庫口令:123456（這個密碼非常重要）
名字與姓氏:192.168.0.110（以后訪問的域名或IP地址，非常重要，證書和域名或IP綁定）
組織單位名稱:anything（隨便填）
組織名稱:anything（隨便填）
城市:anything（隨便填）
省市自治區:anything（隨便填）
國家地區代碼:anything（隨便填）

最后“是否正確？”中鍵入“y”和回車。此時證書已生成。

2、應用證書到tomcat

修改tomcat中的conf/server.xml文件。

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="D:/tomcat.keystore" keystorePass="123456" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

3、測試tomcat的https

啟動tomcat，在瀏覽器中輸入https協議格式的url地址。

　　

 

 

[1]. http://baike.baidu.com/item/http

[2]. http://baike.baidu.com/link?url=GMLo1XhB34TUkdKPEXewjpBYsECNMqp4o0jYqTNZuTYYTJDoDVIomoWdDRlavPCaWpOH8cBDMy7vdpZELSMrrOxnRhfNt4kuoiSWYRYMUgO

[3]. http://blog.csdn.net/u013087513/article/details/49465597

[4]. http://book.51cto.com/art/201404/436093.htm

[5]. http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

[6]. http://baike.baidu.com/item/%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6

[7]. http://www.2cto.com/article/201203/122095.html

[8]. http://blog.csdn.net/xiaojunhu/article/details/8263687

[9]. http://blog.sina.com.cn/s/blog_503506460100mdvt.html