HTTPS和HTTP的區別

HTTP和HTTPS的基本概念

　　HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

　　HTTPS：HTTPS (基於安全套接字層的超文本傳輸協議 或者是 HTTP over SSL) 是一個 Netscape 開發的 Web 協議。

是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，你也能夠說：HTTPS = HTTP + SSL，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

 

　　HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

　　HTTPS 在 HTTP 應用層的基礎上使用安全套接字層做爲子層。

關於SSL/TLS 

1、做用

不使用SSL/TLS的HTTP通訊，就是不加密的通訊。全部信息明文傳播，帶來了三大風險。

（1） 竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。

（2） 篡改風險（tampering）：第三方能夠修改通訊內容。

（3） 冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

SSL/TLS協議是爲了解決這三大風險而設計的，但願達到：

（1） 全部信息都是加密傳播，第三方沒法竊聽。

（2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

（3） 配備身份證書，防止身份被冒充。

　　互聯網是開放環境，通訊雙方都是未知身份，這爲協議的設計帶來了很大的難度。並且，協議還必須可以經受全部匪夷所思的攻擊，這使得SSL/TLS協議變得異常複雜。

2、歷史

互聯網加密通訊協議的歷史，幾乎與互聯網同樣長。

　　1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，可是未發佈。

　　1995年，NetScape公司發佈SSL 2.0版，很快發現有嚴重漏洞。

　　1996年，SSL 3.0版問世，獲得大規模應用。

　　1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS 1.0版。

　　2006年和2008年，TLS進行了兩次升級，分別爲TLS 1.1版和TLS 1.2版。最新的變更是2011年TLS 1.2的修訂版。

　　目前，應用最普遍的是TLS 1.0，接下來是SSL 3.0。可是，主流瀏覽器都已經實現了TLS 1.2的支持。TLS 1.0一般被標示爲SSL 3.1，TLS 1.1爲SSL 3.2，TLS 1.2爲SSL 3.3。

3、基本的運行過程

　　SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

可是，這裏有兩個問題。

（1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

（2）公鑰加密計算量太大，如何減小耗用的時間？

　　解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。因爲"對話密鑰"是對稱加密，因此運算速度很是快，而服務器公鑰只用於加密"對話密鑰"自己，這樣就減小了加密運算的消耗時間。

所以，SSL/TLS協議的基本過程是這樣的：

（1） 客戶端向服務器端索要並驗證公鑰。

（2） 雙方協商生成"對話密鑰"。

（3） 雙方採用"對話密鑰"進行加密通訊。

上面過程的前兩步，又稱爲"握手階段"（handshake）。

4、握手階段的詳細過程

"握手階段"涉及四次通訊，咱們一個個來看。須要注意的是，"握手階段"的全部通訊都是明文的。

4.1 客戶端發出請求（ClientHello）

　　首先，客戶端（一般是瀏覽器）先向服務器發出加密通訊的請求，這被叫作ClientHello請求。

在這一步，客戶端主要向服務器提供如下信息。

（1） 支持的協議版本，好比TLS 1.0版。

（2） 一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。

（3） 支持的加密方法，好比RSA公鑰加密。

（4） 支持的壓縮方法。

　　這裏須要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，不然會分不清應該向客戶端提供哪個網站的數字證書。這就是爲何一般一臺服務器只能有一張數字證書的緣由。

　　對於虛擬主機的用戶來講，這固然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，容許客戶端向服務器提供它所請求的域名。

4.2 服務器迴應（SeverHello）

服務器收到客戶端請求後，向客戶端發出迴應，這叫作SeverHello。服務器的迴應包含如下內容。

（1） 確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。

（2） 一個服務器生成的隨機數，稍後用於生成"對話密鑰"。

（3） 確認使用的加密方法，好比RSA公鑰加密。

（4） 服務器證書。

　　除了上面這些信息，若是服務器須要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。好比，金融機構每每只容許認證客戶連入本身的網絡，就會向正式客戶提供USB密鑰，裏面就包含了一張客戶端證書。

4.3 客戶端迴應

　　客戶端收到服務器迴應之後，首先驗證服務器證書。若是證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已通過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。

若是證書沒有問題，客戶端就會從證書中取出服務器的公鑰。而後，向服務器發送下面三項信息。

（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。

（2） 編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供服務器校驗。

　　上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它之後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

至於爲何必定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：

　　"無論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。

　　對於RSA密鑰交換算法來講，pre-master-key自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。

　　pre master的存在在於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret做爲密鑰就不合適了，所以必須引入新的隨機因素，那麼客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是是三個僞隨機就十分接近隨機了，每增長一個自由度，隨機性增長的可不是一。"

　　此外，若是前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。

4.4 服務器的最後迴應

服務器收到客戶端的第三個隨機數pre-master key以後，計算生成本次會話所用的"會話密鑰"。而後，向客戶端最後發送下面信息。

（1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。

（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的hash值，用來供客戶端校驗。

至此，整個握手階段所有結束。接下來，客戶端與服務器進入加密通訊，就徹底是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。

爲何須要HTTPS？

　　超文本傳輸協議 (HTTP) 是一個用來經過互聯網傳輸和接收信息的協議。HTTP 使用請求/響應的過程，所以信息可在服務器間快速、輕鬆並且精確的進行傳輸。當你訪問 Web 頁面的時候你就是在使用 HTTP 協議，但 HTTP 是不安全的，能夠輕鬆對竊聽你跟 Web 服務器之間的數據傳輸。在不少狀況下，客戶和服務器之間傳輸的是敏感歇息，須要防止未經受權的訪問。爲了知足這個要求，網景公司(Netscape)推出了HTTPS，也就是基於安全套接字層的 HTTP 協議。

 

HTTP與HTTPS有什麼區別？

　　HTTP協議傳輸的數據都是未加密的，也就是明文的，所以使用HTTP協議傳輸隱私信息很是不安全，爲了保證這些隱私數據能加密傳輸，因而網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。

HTTPS加密、加密、及驗證過程，以下圖所示：

簡單來講，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。

HTTP和HTTPS的相同點

　　大多數狀況下，HTTP 和 HTTPS 是相同的，由於都是採用同一個基礎的協議，做爲 HTTP 或 HTTPS 客戶端——瀏覽器，設立一個鏈接到 Web 服務器指定的端口。當服務器接收到請求，它會返回一個狀態碼以及消息，這個迴應多是請求信息、或者指示某個錯誤發送的錯誤信息。系統使用統一資源定位器 URI 模式，所以資源能夠被惟一指定。而 HTTPS 和 HTTP 惟一不一樣的只是一個協議頭(https)的說明，其餘都是同樣的。

HTTP和HTTPS的不一樣之處

1. HTTP 的 URL 以 http:// 開頭，而 HTTPS 的 URL 以 https:// 開頭
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 標準端口是 80 ，而 HTTPS 的標準端口是 443
4. 在 OSI 網絡模型中，HTTP 工做於應用層，而 HTTPS 工做在傳輸層
5. HTTP 無需加密，而 HTTPS 對傳輸的數據進行加密
6. HTTP 無需證書，而 HTTPS 須要認證證書

HTTPS如何工做？

　　使用 HTTPS 鏈接時，服務器要求有公鑰和簽名的證書。

　　當使用 HTTPS 鏈接，服務器響應初始鏈接，並提供它所支持的加密方法。做爲迴應，客戶端選擇一個鏈接方法，而且客戶端和服務器端交換證書驗證彼此身份。完成以後，在確保使用相同密鑰的狀況下傳輸加密信息，而後關閉鏈接。爲了提供 HTTPS 鏈接支持，服務器必須有一個公鑰證書，該證書包含通過證書機構認證的密鑰信息，大部分證書都是經過第三方機構受權的，以保證證書是安全的。

換句話說，HTTPS 跟 HTTP 同樣，只不過增長了 SSL。

HTTP 包含以下動做：

1. 瀏覽器打開一個 TCP 鏈接
2. 瀏覽器發送 HTTP 請求到服務器端
3. 服務器發送 HTTP 迴應信息到瀏覽器
4. TCP 鏈接關閉

SSL 包含以下動做：

1. 驗證服務器端
2. 容許客戶端和服務器端選擇加密算法和密碼，確保雙方都支持
3. 驗證客戶端(可選)
4. 使用公鑰加密技術來生成共享加密數據
5. 建立一個加密的 SSL 鏈接
6. 基於該 SSL 鏈接傳遞 HTTP 請求

何時該使用HTTPS？

銀行網站、支付網關、購物網站、登陸頁、電子郵件以及一些企業部門的網站應該使用 HTTPS，例如：

• PayPal: https://www.paypal.com
• Google AdSense: https://www.google.com/adsense/

若是某個網站要求你填寫信用卡信息，首先你要檢查該網頁是否使用 HTTPS 加密鏈接，若是沒有，那麼請不要輸入任何敏感信息如信用卡號。

 

瀏覽器集成

　　多數瀏覽器在收到一個無效證書的時候都會顯示警告信息，而一些老的瀏覽器會彈出對話框讓用戶選擇是否繼續瀏覽。新的瀏覽器通常在整個窗口顯示橫幅的警告信息，同時在地址欄上顯示該網站的安全信息。若是網站中包含加密和非加密的混合內容，多數瀏覽器會提示警告信息。

=======================================================

　　在URL前加https://前綴代表是用SSL加密的。你的電腦與服務器之間收發的信息傳輸將更加安全。 Web服務器啓用SSL須要得到一個服務器證書並將該證書與要使用SSL的服務器綁定。 HTTP和HTTPS使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。

　　HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議要比HTTP協議安全。

　　HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議，它是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來講它是HTTP的安全版。

　　它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操做，並返回網絡上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）做爲HTTP應用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通訊。）SSL使用40 位關鍵字做爲RC4流加密算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，若是須要的話用戶能夠確認發送者是誰。
HTTPS和HTTP的區別：
1.HTTPS協議須要到ca申請證書，通常免費證書不多，須要交費。
2.HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS 則是具備安全性的ssl加密傳輸協議
3.HTTP和HTTPS使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
4.HTTP的鏈接很簡單,是無狀態的
5.HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比HTTP協議安全
HTTPS解決的問題：
　　1 . 信任主機的問題. 採用HTTPS 的server 必須從CA 申請一個用於證實服務器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度纔信任次主機. 因此目前全部的銀行系統網站,關鍵部分應用都是HTTPS 的. 客戶經過信任該證書,從而信任了該主機. 其實這樣作效率很低,可是銀行更側重安全. 這一點對咱們沒有任何意義,咱們的server ,採用的證書無論本身issue 仍是從公衆的地方issue, 客戶端都是本身人,因此咱們也就確定信任該server.
　　2 . 通信過程當中的數據的泄密和被竄改

　　1. 通常意義上的HTTPS, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點同樣.
b) 服務端和客戶端之間的全部通信,都是加密的.
i. 具體講,是客戶端產生一個對稱的密鑰,經過server 的證書來交換密鑰. 通常意義上的握手過程.
ii. 加下來全部的信息往來就都是加密的. 第三方即便截獲,也沒有任何意義.由於他沒有密鑰. 固然竄改也就沒有什麼意義了.
　　2. 少量對客戶端有要求的狀況下,會要求客戶端也必須有一個證書.
a) 這裏客戶端證書,其實就相似表示我的信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應爲我的證書通常來講上別人沒法模擬的,全部這樣可以更深的確認本身的身份.
b) 目前少數我的銀行的專業版是這種作法,具體證書多是拿U盤做爲一個備份的載體.
HTTPS 必定是繁瑣的.
a) 原本簡單的HTTP協議,一個get一個response. 因爲https 要還密鑰和確認加密算法的須要.單握手就須要6/7 個往返.
i. 任何應用中,過多的round trip 確定影響性能.
b) 接下來纔是具體的HTTP協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容作加密/解密.
i. 儘管對稱加密/解密效率比較高,但是仍然要消耗過多的CPU,爲此有專門的SSL 芯片. 若是CPU 信能比較低的話,確定會下降性能,從而不能serve 更多的請求.
ii. 加密後數據量的影響. 因此，纔會出現那麼多的安全認證提示.

 

參考文章：

http://blog.csdn.net/whatday/article/details/38147103

http://www.mahaixiang.cn/internet/1233.html

http://blog.csdn.net/he90227/article/details/52034629