我是這樣理解HTTP和HTTPS區別的

爲什麼要用https?

http協議的缺點

• 通訊使用明文，內容可能被竊聽(重要密碼泄露)
• 不驗證通訊方身份，有可能遭遇假裝(跨站點請求僞造)
• 沒法證實報文的完整性，有可能已遭篡改(運營商劫持)

用https能解決這些問題麼？

https是在http協議基礎上加入加密處理和認證機制以及完整性保護，即http+加密+認證+完整性保護=https
https並不是應用層的一種新協議，只是http通訊接口部分用ssl/tls協議代替而已。一般http直接和tcp通訊，當使用ssl時則演變成先和ssl通訊，再由ssl和tcp通訊。
所謂https，其實就是身披ssl協議這層外殼的http

SSL/TLS是什麼？

SSL 是「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。它是在上世紀90年代中期，由網景公司設計的。
爲啥要發明 SSL 這個協議？由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。
到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。
因此這二者其實就是同一種協議，只不過是在不一樣階段的不一樣稱呼。

SSL協議位於TCP/IP協議與各類應用層協議之間，爲數據通信提供安全支持。SSL協議可分爲兩層：
SSL記錄協議（SSL Record Protocol）：它創建在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。
SSL握手協議（SSL Handshake Protocol）：它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

對稱祕鑰加密和非對稱祕鑰加密

對稱密鑰加密，又稱私鑰加密，即信息的發送方和接收方用同一個密鑰去加密和解密數據。它的最大優點是加/解密速度快，適合於對大數據量進行加密，但密鑰管理困難。
非對稱密鑰加密，又稱公鑰加密，它須要使用一對密鑰來分別完成加密和解密操做，一個公開發布，即公開密鑰，另外一個由用戶本身祕密保存，即私用密鑰。信息發送者用公開密鑰去加密，而信息接收者則用私用密鑰去解密。
從功能角度而言非對稱加密比對稱加密功能強大，但加密和解密速度卻比對稱密鑰加密慢得多。
非對稱密鑰通訊過程

SSL/TLS協議基本原理

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密，可是這裏有兩個問題：
（1）、如何保證公鑰不被篡改？
解決方法：將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。
（2）、公鑰加密計算量太大，如何減小耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。因爲"對話密鑰"是對稱加密，因此運算速度很是快，而服務器公鑰只用於加密"對話密鑰"自己，這樣就減小了加密運算的消耗時間。

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

1. 客戶端向服務器端索要並驗證公鑰。
2. 雙方協商生成「對話密鑰」。
3. 雙方採用「對話密鑰」進行加密通訊。

具體過程可參考下面的栗子
假定客戶端叫作愛麗絲，服務器叫作鮑勃，整個握手過程能夠用下圖說明

第一步，愛麗絲給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法，具體的加密方法可參考SSL證書背後的加密算法。
第二步，鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個服務器生成的隨機數（Server random）。
第三步，愛麗絲確認數字證書有效，而後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。
第四步，鮑勃使用本身的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。
第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

HTTPS工做原理

一、客戶端發起HTTPS請求
用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。
二、服務端的配置
採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請，區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。
三、傳送證書
這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。
四、客戶端解析證書
這部分工做是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。
（1）首先瀏覽器讀取證書中的證書全部者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操做系統中已內置的受信任的證書發佈機構CA，與服務器發來的證書中的頒發者CA比對，用於校驗證書是否爲合法機構頒發
（3）若是找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。
（4）若是找到，那麼瀏覽器就會從操做系統中取出頒發者CA 的公鑰(多數瀏覽器開發商發佈
版本時，會事先在內部植入經常使用認證機關的公開密鑰)，而後對服務器發來的證書裏面的簽名進行解密
（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中籤名作對比
（6）對比結果一致，則證實服務器發來的證書合法，沒有被冒充
（7）此時瀏覽器就能夠讀取證書中的公鑰，用於後續加密了
五、傳送加密信息
這部分傳送的是用證書加密後的隨機值(私鑰)，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。
六、服務端解密信息
服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密
七、傳輸加密後的信息
這部分信息是服務端用私鑰加密後的信息，能夠在客戶端被還原。
八、客戶端解密信息
客戶端用以前生成的私鑰解密服務端傳過來的信息，因而獲取瞭解密後的內容，整個過程第三方即便監聽到了數據，也一籌莫展。
原理以下圖

總結HTTP和HTTPS區別以下

1. https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。
2. http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
3. http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
4. http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

如何配置https

配置https最重要的是配置ssl證書，配置SSL證書能夠參考SSL證書部署指南
這裏咱們以自簽證書來演示

生成自簽證書

生成私鑰文件
sudo openssl genrsa -out server.key 2048
生成自簽證書文件
sudo openssl req -new -x509 -days 1826 -key server.key -out server.crt

修改apache配置

apache2.4
需開啓的模塊
LoadModule ssl_module libexec/apache2/mod_ssl.so
LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so

sudo vim httpd-ssl.conf

<VirtualHost *:443>
    DocumentRoot "/var/www/html"
    ServerName www.domain.com:443
    SSLEngine on
    SSLCertificateFile /usr/local/apache/conf/server.crt #添加證書文件
    SSLCertificateKeyFile /usr/local/apache/conf/server.key #添加私鑰文件
</VirtualHost>

檢測配置文件是否有錯誤
sudo apachectl configtest
重啓apache
sudo apachectl restart

Fiddler/Charles是如何監聽HTTPS?

第一步，Fiddler截獲客戶端發送給服務器的HTTPS請求，Fiddler假裝成客戶端向服務器發送請求進行握手 。
第二步，服務器發回相應，Fiddler獲取到服務器的CA證書， 用根證書（這裏的根證書是CA認證中心給本身頒發的證書）公鑰進行解密， 驗證服務器數據簽名， 獲取到服務器CA證書公鑰。而後Fiddler僞造本身的CA證書（這裏的CA證書，也是根證書，只不過是Fiddler僞造的根證書）， 冒充服務器證書傳遞給客戶端瀏覽器。
第三步，與普經過程中客戶端的操做相同，客戶端根據返回的數據進行證書校驗、生成密碼Pre_master、用Fiddler僞造的證書公鑰加密，並生成HTTPS通訊用的對稱密鑰enc_key。
第四步，客戶端將重要信息傳遞給服務器， 又被Fiddler截獲。Fiddler將截獲的密文用本身僞造證書的私鑰解開， 得到並計算獲得HTTPS通訊用的對稱密鑰enc_key。Fiddler將對稱密鑰用服務器證書公鑰加密傳遞給服務器。
第五步，與普經過程中服務器端的操做相同，服務器用私鑰解開後創建信任，而後再發送加密的握手消息給客戶端。
第六步，Fiddler截獲服務器發送的密文， 用對稱密鑰解開， 再用本身僞造證書的私鑰加密傳給客戶端。
第七步，客戶端拿到加密信息後，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與服務器端就這樣創建了」信任「。

在以後的正常加密通訊過程當中，Fiddler如何在服務器與客戶端之間充當第三者呢？
服務器—>客戶端：Fiddler接收到服務器發送的密文， 用對稱密鑰解開， 得到服務器發送的明文。再次加密， 發送給客戶端。
客戶端—>服務端：客戶端用對稱密鑰加密，被Fiddler截獲後，解密得到明文。再次加密，發送給服務器端。因爲Fiddler一直擁有通訊用對稱密鑰enc_key， 因此在整個HTTPS通訊過程當中信息對其透明。

參考文章

• HTTP,SSL/TLS和HTTPS協議的區別與聯繫
• SSL證書部署指南
• 圖解SSL/TLS協議