HTTPS 加密了什麼內容？
都說HTTPS安全，看了很多解釋，卻不知道HTTPS加密了哪些內容。有人能用通俗易於理解的話解釋一下嗎？
我不解的是：
1、好比說郵箱，登錄時進行HTTPS加密了，即使提交時保護了賬戶信息，但之後的請求，郵件伺服器返回的網頁源代碼，信件內容不是都在上面嗎？這些信息同時被加密了嗎？
2、我訪問了某https網站 ，運營商/HK/GFW能查或不能查到我的哪些信息？比如訪問請求，提交表單的內容等等……
3、HK劫持到SESSIONID就能輕易的繞過登錄，用HTTPS能否起到保護作用？
我司運維總監 王繼波 的一篇文章《扒一扒HTTPS網站的內幕》
寫得很全面，可以了解一下，也可以看看我司官博，還有其他網站安全相關內容：
扒一扒HTTPS網站的內幕
今年6月，維基媒體基金會發布公告，旗下所有網站將默認開啟HTTPS，這些網站中最為人所知的當然是全球最大的在線百科-維基百科。而更早時候的3月，百度已經發布公告，百度全站默認開啟HTTPS。淘寶也默默做了全站HTTPS。
網站實現HTTPS，在國外已經非常普及，也是必然的趨勢。Google、Facebook、Twitter等巨頭公司早已經實現全站HTTPS，而且為鼓勵全球網站的HTTPS實現，Google甚至調整了搜索引擎演算法，讓採用HTTPS的網站在搜索中排名更靠前。但是在國內，HTTPS網站進展並不好，大部分的電商網站也僅僅是對賬戶登錄和交易做HTTPS，比如京東；很多網站甚至連登錄頁面也沒有實現HTTPS…這裡面有很多的原因，比如現有架構改動的代價過大、CDN實現困難、對用戶隱私和安全的不重視等。
還有個重要原因是擔心網站實現HTTPS後，網站的用戶體驗和性能下降明顯。事實上，通過合理部署和優化，HTTPS網站的訪問速度和性能基本不會受到影響。
一、什麼是HTTPS網站？
在介紹HTTPS網站前，首先簡單介紹什麼是HTTPS。
HTTPS可以理解為HTTP+TLS，HTTP是互聯網中使用最為廣泛的協議，目前不部分的WEB應用和網站都是使用HTTP協議傳輸。主流版本是HTTP1.1，HTTP2.0還未正式普及，2.0由Google的SPDY協議演化而來，在性能上有明顯的提升。
TLS是傳輸層加密協議，是HTTPS安全的核心，其前身是SSL，主流版本有SSL3.0、TLS1.0、TLS1.1、TLS1.2。SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到。
那網站為什麼要實現HTTPS？
一言概之，為保護用戶隱私和網路安全。通過數據加密、校驗數據完整性和身份認證三種機制來保障安全。
由於本文的重點是HTTPS網站的性能加速，對於HTTPS通信過程和加解密演算法就不展開介紹了。
感興趣的同學可以Google之，基礎都是一樣的。
二、HTTPS網站的直觀了解
推薦一個在線版全球知名的HTTPS網站檢測工具-SSL Labs。Qualys SSL Labs同時也是很具有影響力的SSL安全和性能研究機構。在線檢測地址為：SSL Server Test (Powered by Qualys SSL Labs)。
SSL Labs會對HTTPS網站的證書鏈、安全性、性能、協議細節進行全面檢測，檢測完畢後會進行打分，同時給出一份詳細的檢測報告和改進建議。
三、提高HTTPS網站性能和訪問速度
如果你認為網站加上TLS證書，就是HTTPS網站了，那你就跟12306犯了同樣的錯誤……
首先，網站在加上TLS證書時，為什麼會變慢？這主要又兩方面造成：
1. HTTPS比HTTP在通信時會產生更多的通信過程，隨之RTT時間就會增加；
2. HTTPS通信過程的非對稱和對稱加解密計算會產生更多的伺服器性能和時間上的消耗。
但是，每個HTTPS網站其實都有著巨大的優化空間。下面我們結合WildDog網站，來看看QPS值從30000到80000，載入時延從800ms到300ms，這中間的每個優化點是怎樣的。
- HSTS
HTTPS網站通常的做法是對HTTP的訪問在伺服器端做302跳轉，跳轉到HTTPS。但這個302跳轉存在兩個問題：
1. 使用不安全的HTTP協議進行通信；
2. 增加一個Round-Trip Time。
而HSTS是HTTP Strict Transport Security的縮寫，伺服器端配置支持HSTS後，會在給瀏覽器返回的HTTP Header中攜帶HSTS欄位，瀏覽器在獲取到該信息後，在接下來的一段時間內，對該網站的所有HTTP訪問，瀏覽器都將請求在內部做307跳轉到HTTPS，而無需任何網路過程。
- Session Resume
Session Resume即會話復用，這提升HTTPS網站性能最基礎也是最有效的方法。
在HTTPS握手階段，對伺服器性能消耗最為嚴重的是非對稱密鑰交換計算，而Session Resume通過對已經建立TLS會話的合理復用，節省非對稱密鑰交換計算次數，可大幅提高伺服器的TLS性能。
TLS協議提供兩種實現機制Session Resume，分別是Session cache和Session ticket。
Session Cache
Session Cache的原理是使用Session ID查詢伺服器上的session cache，如果命中，則直接使用緩存信息。但Session Cache有個明顯的缺點，它不支持分散式緩存，只支持單機進程間的共享緩存。這對於多個接入節點的架構很難適用。
Session ticket
Session ticket的原理是伺服器降session信息加密成ticket發送給瀏覽器，瀏覽器後續進行TLS握手時，會發送ticket，如果伺服器能夠解密和處理該ticket，則可以復用session。
Session ticket可以很好的解決分散式問題，但Session ticket的支持率還不是很高，而且需要考慮伺服器上key的安全性方案。
- OCSP Stapling
在HTTPS通信過程時，瀏覽器會去驗證伺服器端下發的證書鏈是否已經被撤銷。驗證的方法有兩種：CRL和OCSP。
CRL是證書撤銷列表，CA機構會維護並定期更新CRL列表，但這個機制存在不足：
1.CRL列表只會越來越大；
2.如果瀏覽器更新不及時，會造成誤判。
OCSP是實時證書在線驗證協議，是對CRL機制的彌補，通過OCSP瀏覽器可以實時的向CA機構驗證證書。但OCSP同樣存在不足：
1. 對CA機構要求過高，要求實時全球高可用；
2. 客戶端的訪問隱私會在CA機構被泄露；
3. 增加瀏覽器的握手時延。
而OCSP Stapling是對OCSP缺陷的彌補，伺服器可事先模擬瀏覽器對證書鏈進行驗證，並將帶有CA機構簽名的OCSP響應保存到本地，然後在握手階段，將OCSP響應和證書鏈一起下發給瀏覽器，省去瀏覽器的在線驗證過程。
- SPDY和HTTP2.0
SPDY 是 Google 推出的優化 HTTP 傳輸效率的協議，採用多路復用方式，能將多個 HTTP 請求在同一個連接上一起發出去，對HTTP通信效率提升明顯。HTTP2.0是 IETF 2015 年 2 月份通過的 HTTP 下一代協議，它以 SPDY 為原型。SPDY 和 HTTP2 目前的實現默認使用 HTTPS 協議。
Nginx stable版本當前只能支持到SPDY3.1，但最新發布的1.9.5版本通過打patch的方式，可以支持HTTP2.0，這絕對是不一樣的奇妙體驗。不過不建議直接在線上環境部署，等到2015年年底吧，Nginx會發布Stable版本支持HTTP2.0.
- TCP優化
因為TCP是HTTPS的承載，TCP的性能提升，上層業務都可以受益。
慢啟動是TCP規範中很重要的演算法，其目的是為避免網路擁塞。通過客戶端和伺服器之間的數據交換，從一個很保守的初始擁塞窗口值，收斂到雙方都認可的可用帶寬。當客戶端和伺服器收斂到一定帶寬時，如果一段時間內，雙方沒有收發數據包，伺服器端的擁塞窗口會被重置為初始擁塞窗口值。這對於連接中的突發數據傳輸性能影響是很嚴重的。
在沒有充足的理由時，伺服器端需要禁用空閑後的慢啟動機制。
另外，當前瀏覽器和伺服器之間的可用帶寬已經相對較大，所以我們還應該將初始的擁塞窗口值擴大，新的RFC中的建議是10，Google是16。
- TLS Record Size
伺服器在建立TLS連接時，會為每個連接分配Buffer，這個Buffer叫TLS Record Size。這個Size是可調。
Size值如果過小，頭部負載比重就會過大，最高可達6%。
Size值如果過大，那單個Record在TCP層會被分成多個包發送。瀏覽器必須等待這些全部達到後，才能解密，一旦出現丟包、擁塞、重傳、甚至重新建立的情況，時延就會被相應增加。
那TLS Record Size值如何選擇呢？有兩個參數可參考。
首先，TLS Record Size要大於證書鏈和OCSP Stapling響應大小，證書鏈不會分成多個record；
其次，要小於初始擁塞窗口值，保證伺服器在通信之初可以發送足夠數據而不需要等待瀏覽器確認
一般來說，從根CA機構申請的證書為2-3KB左右，級數越多，證書鏈越大，ocsp響應為2KB左右，所以TLS Record Size是需要根據你的實際情況設置，Google的值5KB。WildDog當前的值是6KB。
- 證書鏈完整且不冗餘
瀏覽器在驗證伺服器下發的證書鏈時，不僅僅驗證網站證書。如果是多級證書，網站證書和根證書之間所有的中間證書都需要被驗證。一旦出現證書鏈出現不完整，瀏覽器就會暫停握手過程，自行到網際網路進行驗證，這個時間基本是不可估算的。
至於怎麼查看，通過openssl命令查看，也可以通過SSL Labs幫你在線檢測。
- 移動設備上的ChaCha20-Poly1305
去年的時候，谷歌已經在Android的Chrome瀏覽器上增加支持一個新的TLS加密套件，這個加密套件就是ChaCha20-Poly1305。它的設計者是伊利諾伊大學的教授和研究員Dan BernsteinChaCha20被用來加密，Poly1305被用來消息認證，兩個操作都需要運行於TLS上。
當前流行的加密套件AES-GCM在TLS 1.2支持，它是不安全RC4和AES-CBC加密套件的替代品。但是，在不支持硬體AES的設備上會引起性能問題，如大部分的智能手機、平板電腦、可穿戴設備。
ChaCha20-Poly1305正式為解決這個問題而生。以下是Google的相關測試數據，在使用Snapdragon S4 Pro處理器的Nexus 4或其他手機中，AES-GSM的加密吞吐量是41.5MB/s，而ChaCha20-Poly1305是130.9MB/s。在使用OMAP 4460的老的Galaxy Nexus手機上，AES-GSM的吞吐量是24.1MB/s，而ChaCha20-Poly1305是75.3MB/s。
當前，OpenSSL 1.0.2的分支上已經開始支持ChaCha20-Poly1305，而對ChaCha20-Poly1305支持最好的當屬BoringSSL。通過重新對Nginx的SSL庫編譯，可以支持到ChaCha20-Poly1305，不過對於線上環境，建議看明白源碼再使用。
除此之外，還有不少優化的細節，如硬體加速、False Start、禁用TLS壓縮等等，這裡就不扒了。
如果覺得這篇文章有幫助，就請收藏或者分享一下，希望可以幫到更多人。
1、好比說郵箱，登錄時進行HTTPS加密了，即使提交時保護了賬戶信息，但之後的請求，郵件伺服器返回的網頁源代碼，信件內容不是都在上面嗎？這些信息同時被加密了嗎？
1. 如果整個網站都是走HTTPS的，那伺服器返回的內容都是被加密的，你能看到網頁內容是因為瀏覽器已經解密了。
大概過程，（實際過程更複雜）：
1. 你訪問HTTPS網站，網站把公鑰給你。
2. 你驗證公鑰，然後生成一個串隨機AES_128密碼（假如是用AES加密），並把這個密碼用剛才那個公鑰加密，發給服務端。
3. 服務端用私鑰解密你的發送的數據，得到你隨機生成的AES_128密碼，並把網頁內容全部用AES_128加密器起來，發會給你。
4. 瀏覽器用剛剛的AES_128密碼解密 伺服器返回的數據，得到你可讀的內容。
5. 之後你發出的請求數據，也是用AES_128密碼來加密。
瀏覽器返回的網站內容都是用對稱加密（比如AES128）加密起來的，而這個密碼又是你臨時生成了，所以第三方無法知道你訪問的內容是什麼。
2、我訪問了某https網站 ，運營商/HK/GFW能查或不能查到我的哪些信息？比如訪問請求，提交表單的內容等等……
3、HK劫持到SESSIONID就能輕易的繞過登錄，用HTTPS能否起到保護作用？
同理，這兩個問題也就迎刃而解,運營商/HK/GFW 只能知道你訪問的哪個ip或者域名。
@陳肖恩 說的1、3沒錯，第2點我再補充一下。首先HTTPS就是用來防止中間人攻擊的，既能夠防止監聽通信內容的中間人，也能防止主動修改通信的中間人。所以說除非攻擊者（也就是中間人）能夠發現HTTPS相關的漏洞，否則不可能查到信息。再說保護了什麼，除了你要訪問的域名不被保護，剩下的全部加密。比如你訪問 https://www.baidu.com/，並全程在https頁面，你的運營商等人只能知道你在上百度，但不知道你搜索的關鍵詞等。
至於那種只在登錄使用HTTPS，這樣僅保護了密碼，之後的訪問是完全不安全的。
所有信息中，只有IP和埠不加密，其他REQUEST信息都加密（COOKIE URI）。
仔細想想，一個IP的一個埠 只允許一個證書，也就是說，伺服器無法在一個埠上區分多個證書，說明在傳送CRT之前，訪問的域名是不知道的。也就是說訪問的域名是加密的~ 推測。
補充:
如果支持SNI服務，那麼會在建立SSL連接之前，將主機頭信息 發送到伺服器。 這樣可以實現交換公鑰之前，根據域名決定發送哪個公鑰。
這樣就可以支持一個IP同埠 使用多個SSL證書。
首先HTTPS現在實際上是基於SSLTLS建構的通道再疊加HTTP的通信，在這個通道協議保護下，S/C之間的通信在不可信網路中能夠保密地傳送不被窺探（除了部分極端方法，如中間人攻擊）
1.那是你客戶端接收到的信息，已經解密了，當然部分超垃圾的郵箱只有登錄階段有使用https，之後界面頁面沒使用，等於白費。
2.除了使用中間人攻擊，否則基本不會。
3.SSLTLS保護整個上層應用協議的通信包，Cookie是HTTP包的一部分，可以保護。
什麼意思
HTTPS是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTPS，但HTTPS存在不同於HTTP的默認埠及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
因此，使用HTTPS代替HTTP是必然的，互聯網只有在安全的傳輸過程中才能保障數據的安全性，而HTTP已經不安全了，在此提醒大家，安裝SSL證書一定要選擇可信的CA機構或者可信的SSL證書代理機構，愛名網是一家代理SSL證書種類多，服務好，性價比高的國內代理機構，擁有豐富的ssl證書鑒證及技術服務經驗。只有選擇正規的服務商，才能保障服務的完整性，也能提升網站的可信度。
@劉澤華 你前後說的不一致：
1.伺服器無法在一個埠上區分多個證書。
2.兩個域名解析到一個IP，在同一個埠開啟兩個域名的https服務，web軟體會報錯的
這是兩個說法嘛。
我認為第一個說法，實測後才曉得。
第二個說法，肯定不對，我們網站就是多個域名解析到一個IP，在同一個埠（其實https只有在443埠上才最兼容各種環境的）開啟多個域名的https服務，就沒有問題，只不過證書是同一個，是泛域名的證書。
推薦閱讀：