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

一、首先使用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」和回車。此時證書已生成。

二、應用證書到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" />

三、測試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