注：本文參考自網絡上的多篇HTTPS相關文章，本人根據自己的理解，進行一些修改，綜合。
1. 必要的加密解密基礎知識
1）對稱加密算法：就是加密和解密使用同一個密鑰的加密算法。因為加密方和解密方使用的密鑰相同，所以稱為稱為對稱加密，也稱為單鑰加密方法。
優點是：加密和解密運算速度快，所以對稱加密算法通常在消息發送方需要加密大量數據時使用；
缺點是：安全性差，如果一方的密鑰遭泄露，那么整個通信就會被破解。另外加密之前雙方需要同步密鑰;
常用對稱加密算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等;
2）非對稱加密算法：而非對稱加密算法需要兩個密鑰來進行加密和解密，這兩個秘鑰是公開密鑰(public key，簡稱公鑰)和私有密鑰(private key，簡稱私鑰)。
公鑰和私鑰是一對：公鑰用來加密，私鑰解密，而且公鑰是公開的，私鑰是自己保存的，不需要像對稱加密那樣在通信之前要先同步秘鑰。
有點是：安全性更好，私鑰是自己保存的，不需要像對稱加密那樣在通信之前要先同步秘鑰。
缺點是：加密和解密花費時間長、速度慢，只適合對少量數據進行加密。
常用的非對稱加密算法有：RSA、Elgamal、Rabin、D-H、ECC等；
3）HASH算法：也稱為消息摘要算法。將任意長度的二進制值映射為較短的固定長度的二進制值，該二進制值稱為哈希值。
常用於檢驗數據的完整性，檢驗數據沒有被篡改過。常見的又 MD5(MD系列)，SHA-1(SHA系列)
HTTPS 使用到了上面全部三種加密算法。
2. HTTPS 的作用
HTTPS簡單而言，即使建立在SSL/TLS協議之上的HTTP。不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。
（1） 竊聽風險（eavesdropping）：第三方可以獲知通信內容。
（2） 篡改風險（tampering）：第三方可以修改通信內容。
（3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協議是為了解決這三大風險而設計的，希望達到：
（1） 所有信息都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
互聯網是開放環境，通信雙方都是未知身份，這為協議的設計帶來了很大的難度。而且，協議還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協議變得異常復雜。
3. HTTPS 的歷史
互聯網加密通信協議的歷史，幾乎與互聯網一樣長。
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。
4. 基本的運行過程
HTTPS 的基本運行過程：
1）利用對稱加密算法來加密網頁內容，那么如何保證對稱加密算法的秘鑰的安全呢？
2）使用非對稱加密算法來獲得對稱加密算法的秘鑰，從而保證了對稱加密算法的秘鑰的安全，也就保證了對稱加密算法的安全。
這里這樣安排使用的原理是，利用了對稱加密算法和非對稱加密算法優點，而避免了它們的缺點。利用了對稱加密算法速度快，而非對稱加密算法安全的優點；同時巧妙的避免了對稱加密算法的不安全性，以及需要同步密鑰的缺點，也避免了非對稱加密算法的速度慢的缺點。實在是巧妙了。
這里有兩個問題：
（1）如何保證非對稱加密算法公鑰不被篡改？
解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
（2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由於"對話密鑰"是對稱加密算法，所以運算速度非常快，而服務器公鑰只用於加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。（也就是網頁內容的加密使用的是對稱加密算法）
因此，SSL/TLS協議的基本過程是這樣的：
（1） 客戶端向服務器端索要並驗證非對稱加密算法的公鑰。
（2） 雙方協商生成對稱加密算法的"對話密鑰"。
（3） 雙方采用對稱加密算法和它的"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）。
5. 握手階段的詳細過程
"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。
1) 客戶端發出請求（ClientHello）
首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求。
在這一步，客戶端主要向服務器提供以下信息。
（1） 瀏覽器支持的SSL/TLS協議版本，比如TLS 1.0版。
（2） 一個瀏覽器客戶端生成的隨機數，稍后用於生成對稱加密算法的"對話密鑰"。
（3） 瀏覽器支持的各種加密方法，對稱的，非對稱的，HASH算法。比如RSA非對稱加密算法，DES對稱加密算法，SHA-1 hash算法。
（4） 瀏覽器支持的壓縮方法。
這里需要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什么通常一台服務器只能有一張數字證書的原因。
對於虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
2) 服務器回應（SeverHello）
服務器收到客戶端請求后，向客戶端發出回應，這叫做SeverHello。服務器的回應包含以下內容。
（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
（2） 一個服務器生成的隨機數，稍后用於生成對稱加密算法的"對話密鑰"。
（3） 確認使用的各種加密方法，比如確認算法使用：RSA非對稱加密算法，DES對稱加密算法，SHA-1 hash算法
（4） 服務器證書。
除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
3） 客戶端回應
客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。
如果證書沒有問題，客戶端就會從證書中取出服務器的非對稱加密算法的公鑰。然后，向服務器發送下面三項信息。
（1） 一個隨機數。該隨機數用服務器發來的公鑰進行的使用非對稱加密算法加密，防止被竊聽。
（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送(比如確認使用：RSA非對稱，DES對稱，SHA-1 hash算法)。
（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以后，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的對稱加密算法，各自生成本次會話所用的同一把"會話密鑰"。也就是說瀏覽器和服務器各自使用同一個對稱加密算法，對三個相同的隨機數進行加密，獲得了，用來加密網頁內容的 對稱加密算法的秘鑰。(注意：這里瀏覽器的三個隨機數都是明文的，但是服務端獲得的"pre-master key"是密文的，所以服務器需要使用非對稱加密算法的私鑰，來先解密獲得"pre-master key"的明文，在來生成對稱加密算法的秘鑰。這樣的目的是為了防止："pre-master key"被竊聽，因為發送明文會被竊聽，但是發生的是非對稱加密算法的加密過后的密文，因為竊聽者不知道私鑰，所以即使竊聽了，也無法解密出其對應的明文。從而保證了最后生成的：用於加密網頁內容的對稱加密算法的秘鑰的安全性！！！)
至於為什么一定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的 可不是一。"
這里：其實如果 pre-master-key 和 瀏覽器生成的隨機數都可能被猜出來，那么最后生成的對稱加密算法的秘鑰就是不安全的。因為三個隨機數都可能被竊聽到了。
此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
4) 服務器的最后回應
服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的對稱加密算法的"會話密鑰"。然后，向客戶端最后發送下面信息。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的對稱加密算法和密鑰進行加密。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。
至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。
參考鏈接
- MicroSoft TechNet, SSL/TLS in Detail
- Jeff Moser, The First Few Milliseconds of an HTTPS Connection
- Wikipedia, Transport Layer Security
- StackExchange, How does SSL work?
（完）
=======================================
注：
本文主要修改自：SSL/TLS協議運行機制的概述
僅僅按照自己的理解，進行了一些修改，和補充，以利於自己理解。可能會存在自己理解上的錯誤。
另外參考了：HTTPS那些事（一）HTTPS原理
本文如果結合 HTTPS連接的前幾毫秒發生了什么 一起來理解HTTPS，將理解的更加深入。
總結：
1）HTTPS 結合使用了 非對稱加密算法，對稱加密算法，hash算法，分別利用他們的優勢，避免他們的缺點。利用非對稱加密算法獲得對稱加密算法的秘鑰，保證他的安全性；然后實際的網頁內容的加密使用的是對稱加密算法，利用了對稱加密算法速度快的優勢，hash算法主要是防止篡改的發生，是一種校驗機制，最后數字證書，保證了服務器在將非對稱加密算法的公鑰傳給瀏覽器時的安全性(不會被中間人篡改)，同時也標志了服務器的身份。
2）HTTPS的四大金剛：
非對稱加密算法(對稱加密算法的秘鑰) + 對稱加密算法(加密內容) + 數字證書(防止篡改非對稱加密算法的公鑰) + HASH算法(防止篡改消息)== HTTPS
3）HTTPS的本質是什么？
HTTPS的本質就是在HTTP連接發起之前，先使用SSL/TLS協議，協調客戶端和服務端，在兩端各自生產一個對稱加密算法的秘鑰，
然后使用普通的HTTP協議傳輸 經過對稱加密算法加密的網頁內容。因為對稱加密算法的秘鑰是安全的，所以對稱加密算法加密的網頁內容也是安全的。