保護隱私(privacy)：所有資訊都是加密傳播，第三方無法竊聽資料。如果使用http明文傳輸資料的話，很可能被第三方劫持資料，那麼所輸入的密碼或者其他個人資料都被暴露在他人面前，後果可想而知。參考當你開啟瀏覽器，訪問某個**，如果**旁有個小鎖，代表訪問的**是安全的，反之不安全。當我們沒有看到那個小鎖的小圖示的時候，需要提高警惕，不要隨意輸入個人重要的資料。所有的銀行和支付相關的**都是100%使用https的。
資料完整性(integraty)：一旦第三方篡改了資料，接收方會知道資料經過篡改，這樣便保證了資料在傳輸過程中不被篡改
身份認證(identification)：第三方不可能冒充身份參與通訊，因為伺服器配備了由證書頒發機構（certificate authority，簡稱ca）頒發的安全證書，可以證實伺服器的身份資訊，防止第三方冒充身份。（也有少數情況下，通訊需要客戶端提供證書，例如銀行系統，需要使用者在登入的時候，插入銀行提供給使用者的usb，就是需要客戶端提供證書，用來驗證客戶的身份資訊。）
2023年公布 ssl1.0/2/0/3.0那麼一些還在使用tls 1.0和1.1的**就得被迫公升級到tls 1.2或者tls 1.3。2023年 tls 1.0/1.1/1.2
2023年各大瀏覽器才開始支援tls1.2
2023年3月發布了tls 1.3
要關閉瀏覽器對tls 1.0和1.1的支援，可以在internet選項中修改
需要理解ssl/tls的工作原理，我們需要掌握加密演算法。加密演算法有兩種：對稱加密和非對稱加密：
ssl/tls是利用了對稱加密和非對稱加密的特點。先來看下整個ssl/tls的握手過程，之後我們再分步驟詳細解讀，每一步都幹了些什麼。
當tcp建立連線之後，tls握手的第一步由客戶端發起，傳送clienthello的訊息到伺服器。clienthello訊息包含：
延伸閱讀：加密套件名如：「tls_ecdhe_rsa_with_aes_256_gcm_sha256」，這麼長的名字看著有點暈吧，不用怕，其實它的命名非常規範，格式很固定。基本的形式是「金鑰交換演算法-服務身份驗證演算法-對稱加密演算法-握手校驗演算法」。握手過程中，證書簽名使用的rsa演算法，如果證書驗證正確，再使用ecdhe演算法進行金鑰交換，握手後的通訊使用的是aes256的對稱演算法分組模式是gcm。驗證證書簽名合法性使用sha256作雜湊演算法檢驗。相關的演算法的用處將在後文中詳解。然後伺服器端在收到這個clienthello，從中選擇伺服器支援的版本和套件，傳送serverhello訊息：
隨後伺服器傳送伺服器的安全證書(含公鑰)。客戶端收到serverhello後，會對收到的證書進行驗證。如果需要客戶端也提供證書的話，還會發出客戶端證書請求(client certificate request)，只有少數金融機構才需要客戶端也提供客戶端證書。
此後客戶端傳送server hello done訊息表示hello階段完成。
我們來看一下為什麼可以通過ca(certificate authority，證書頒發機構)簽發的證書來確認**的身份？當我們安裝作業系統或者瀏覽器的時候，會安裝一組可信任的ca（根證書ca包括globalsign、geotrust、verisign等）列表。根ca如globalsign就在我們的可信任的ca列表裡，你的瀏覽器或者作業系統含有globalsign的公鑰。
先來看一下google的證書，當你訪問google的時候，google會發給你它的證書。證書中包含頒發機構的簽名以及伺服器的公鑰。
瀏覽器首先用雜湊函式對明文資訊的摘要做雜湊得到乙個雜湊值（用到的就是證書中的簽名雜湊演算法sha256），然後用根ca的公鑰對根證書的簽名作解密得到另乙個雜湊值（用到的演算法就是rsa非對稱演算法），如果兩個雜湊值相等則說明證書沒有被篡改過。當然還需校驗證書中伺服器名稱是否合法以及驗證證書是否過期.
這樣就免受中間人攻擊了，因為假如有中間人修改了證書的內容（如將證書中的公鑰替換成自己的公鑰），那麼將獲得不同的雜湊值，從而兩個雜湊值不匹配導致驗證失敗。如果要繞過這個機制，中間人必須要也替換簽名，使簽名也相匹配。而做到這一點就需要破解到了根證書的金鑰（而這是不可能的，中間人必然會失敗）。瀏覽器會出現以下畫面，告訴你正在遭受中間人攻擊，因為證書被篡改了：
那聰明的你肯定也想到了，如果你開發了乙個系統還在測試階段，還沒有正式申請一張證書，那麼你可以為伺服器自簽名一張證書，然後將證書匯入客戶端的ca信任列表中。
信任鏈機制可以看到證書路徑是globalsign root ca-r2 -> gts ca 1o1->*.google.com。因為我們的瀏覽器信任globalsign root ca，根據信任鏈機制，你相信了根ca頒發的證書，也要相信它簽名的子ca頒發的證書，也要相信子ca簽名的子子ca的證書…而我們通過一級級的校驗，如果從根證書到最下層的證書都沒有被篡改過，我們就相信最下層的這個伺服器證書是合法的。所以在這個機制中，你就需要無條件的相信根證書的頒發機構。
如果通過驗證，客戶端生成乙個隨機數pre-master，用於金鑰交換過程。
因為只有伺服器有私鑰，可以針對客戶端發出的加密過的資訊進行解密得到pre-master，這樣就保證了只有伺服器和客戶端知道pre-master。伺服器端也可以用server-random + client-random + pre-master一起計算出對稱金鑰master secret。
現在客戶端和伺服器均有金鑰master secret了，後面就可以用它來進行加密和解密了。
為什麼不能只用乙個pre-master作為之後加密的對稱金鑰？雖然只有伺服器有私鑰，能夠解密pre-master呀，但僅用它作為master secret是不夠安全的，這是因為要以防客戶端的pre-master並不是隨機數的情況。加上另外兩個隨機數client-random以及server-random（而這兩個隨機數和時間有相關性），這樣就能保證最後生成的master secret一定是隨機數。綜上，整個握手過程主要是通過一系列步驟通過
非對稱加密的演算法交換得到了master secret，這個步驟通常需要幾百毫秒，但是就是這一頓猛操作之後使得只有伺服器和客戶端知道master secret。之後的通訊又利用了高效的對稱演算法對所有資訊進行加密和解密，雖然加密和解密也需要耗時耗流量，不過資訊是完全不可能被別人篡改和破解的，這一點損耗還是值得的。 回顧 HTTPS工作原理的簡單理解
http協議都是明文的，是沒有加密的，風險比較大。現在大部分應用都是用https協議的 之前是基於ssl協議對http進行加密，後來又公升級到了tsl協議來加密。1 瀏覽器把自己支援的加密規則傳送給 2 從這套加密規則裡選出來一套加密演算法和hash演算法，然後把自己的身份資訊用證書的方式發回給瀏覽...
HTTPS的工作原理
1.瀏覽器將自己支援的一套加密規則傳送給 2.從中選出一組加密演算法與hash演算法，並將自己的身份資訊以證書的形式發回給瀏覽器。證書裡面包含了 位址，加密公鑰，以及證書的頒發機構等資訊。3.獲得 證書之後瀏覽器要做以下工作 a 驗證證書的合法性 頒發證書的機構是否合法，證書中包含的 位址是否與正在...
https的工作原理
https在傳輸資料之前需要客戶端與服務端之間進行一次握手，在握手的過程中將確立雙方加密傳輸資料的密碼資訊。握手的過程具體如下 a 瀏覽器將自己支援的一套加密規則發給服務端。b 從中選出一組加密演算法，並將自己的身份資訊以證書的形式發回給瀏覽器，證書裡面包含了 位址，加密公鑰以及證書的頒發機構等。c...