本來的主題是介紹一下我之前做的搜尋與推薦的業務，但9月份開始我主要開始承擔一些醫那塊的業務測試，就想做點別的分享，但換成醫的業務介紹，想了想我目前對醫的瞭解程度，實在沒勇氣拿出來分享，所以就換了這個主題。
這個主題其實也是早有預謀，一個初衷是想對某一個通用性的技術，說白了就是跑到哪裡都能用上的技術，利用1個小時左右的時間裡能夠和大家一起對它進行探討學習。
針對通用性，我舉個例子，目前我們說到要做效能，就需要用到什麼平臺？在座的很多大佬應該都用過，王明啊王鑫啊進標啊，有幾個人可能還參與到研發過程。是莫扎特，但是大家對這個平臺瞭解多少，有沒有從頭到尾梳理過莫扎特的原始碼，如果沒有，那其實就只是使用平安健康公司的一個平臺完成一個日常工作任務，如果沒有莫扎特平臺，或者我說直白點你假使有一天想換個公司，你還能完成壓測任務嗎？這個我相信大家都有過思考。。。。。。。。
那你在當前公司裡能用上，甚至跑到哪都能用上的技能就具有通用性。
這裡我解釋下就是，這麼說不是為了鼓勵大家離職啊，只是解釋了一下通用性這個詞。
然後，我之前想再研究下這個https的原因，就是在國際化部門的時候，想對一個https介面做壓測，但是當時國際化那一套莫扎特不支援，所以用的JMeter，這個工具大家應該也都用過或者至少聽過，這就涉及到證書的配置，當時就深入了一下https。
所以本次分享可能會給我們帶來以下收穫：
理解HTTPS原理的概念
什麼是對稱加密和非對稱加密？
什麼是數字簽名？怎麼生成？怎麼校驗？
啥時候是對稱加密？啥時候是非對稱加密？啥時候進行演算法加密？什麼演算法？
第三方機構包含哪些？
HTTPS 是什麼？具體流程
HTTPS和HTTP的區別
現在網站為什麼不都用HTTPS？
對稱加密、非對稱加密的概念
HTTPS的加密機制
不止瞭解它是什麼，更要了解為什麼是它，那樣才能深刻！同時也能感受到人類的智慧是很偉大的！
廢話我就不多說了，我們開始今天的分享。雖然大家都很忙，但誠懇希望大家也能既來之則安之，能夠稍微浪費點腦細胞，我們一起感受下什麼叫從入門到放棄。
HTTPS就是在傳統HTTP協議上引入了一個加密層，
為什麼需要加密？
有部比較老的電視劇，講的是清末宮廷內鬥的故事。有個場景就是有人想要謀反幹掉慈禧，恭親王奕訢得到密報，上了一份摺子，為了掩人耳目呢，上面看似都是些拉家常的話，但是隻要套上一張挖了洞的紙，就能看到真正要說的話：
慈禧先發制人悄無聲息的把這些人一鍋端。今天從歷史角度看這些人到底算忠還是奸暫且不說，從這個上面可以引出來我們今天主題涉及到的一些概念：
奏書全文： 密文（加密後的內容）
當心肅順，端華，戴恆： 明文（解密後的內容）
挖了洞的紙： 金鑰（解密的工具）
如果不加密，可能會導致機密洩露，打草驚蛇，對方提前行動，來不及應對。加密的重要性對於古代尚且如此，對於今天日漸恐怖的網際網路來說，更是不可或缺。
目前，加密有好多種方式，上文中提到的奏摺加密，今天就叫做對稱加密。
金鑰像一把鑰匙一樣，可以鎖上門，也可以開啟門。
但是這樣安全嗎？
首先我們知道你向伺服器傳送請求，整個傳輸過程是可以在很多階段被劫持的，只要有一次被劫持，金鑰就被拿到，來往所有的請求，在劫持者那邊都是沒穿衣服的裸奔狀態。
那有辦法解決這個問題嗎？
瀏覽器和伺服器各自生成兩個金鑰，一個叫公鑰，一個叫私鑰，傳輸內容可以用公鑰加密，但必須要私鑰解密。這種方式叫做非對稱加密。
怎麼樣實現公鑰加密，私鑰解密？
這是一個比較深入而且難啃的技術，暫且不在我們今天討論範圍之內。我們只需要瞭解有這個加解密方式，有興趣的話後面可以再一起深入探討。
伺服器公鑰A，私鑰A，瀏覽器公鑰B，私鑰B
兩方資料傳輸，資料都透過自己的公鑰加密，對方用私鑰解密。
這樣看上去是可行的。但是HTTPS沒用！為什麼？最大原因是這種非對稱加密非常耗時，比起對稱加密效率低很多。那我們能否結合一下兩者，保證資料安全的情況下，保證下效能呢？
非對稱加密+對稱加密
1.某網站擁有用於非對稱加密的公鑰A、私鑰A’。
2.瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
3.瀏覽器隨機生成一個用於對稱加密的金鑰X，用公鑰A加密後傳給伺服器。
4.伺服器拿到後用私鑰A’解密得到金鑰X。
5.這樣雙方就都擁有金鑰X了，且別人無法知道它。之後雙方所有資料都透過金鑰X加密解密即可。
完美！HTTPS基本就是採用了此方案。但是矛與盾永遠同時在升級。
如果在資料傳輸過程中，中間人劫持到了資料，此時他的確無法得到瀏覽器生成的金鑰X，這個金鑰本身被公鑰A加密了，只有伺服器才有私鑰A’解開它，然而中間人卻完全不需要拿到私鑰A’就能幹壞事了。請看：
某網站有用於非對稱加密的公鑰A、私鑰A’。
瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
中間人劫持到公鑰A，儲存下來，把資料包中的公鑰A替換成自己偽造的公鑰B（它當然也擁有公鑰B對應的私鑰B’）。
瀏覽器生成一個用於對稱加密的金鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密後傳給伺服器。
中間人劫持後用私鑰B’解密得到金鑰X，再用公鑰A加密後傳給伺服器。
伺服器拿到後用私鑰A’解密得到金鑰X。
攻擊者狸貓換太子，抓住了瀏覽器無法知道伺服器傳給它的公鑰已經被調包的漏洞，從瀏覽器手裡成功騙取到了瀏覽器的金鑰X。
怎樣才能防止單純的瀏覽器被騙呢？
可能有人會想到，傳輸公鑰的時候，也進行非對稱加密，但這是套娃，最上面一層的非對稱加密使用的公鑰，永遠都需要明文傳輸。
一般劇情發展到這邊，就需要有個中間商站出來賺取差價，這個中間商叫做CA（Certificate Authority，證書授權）機構，它是當今網際網路世界正常運作的前提。網站需要使用HTTPS，可以向CA機構申領一份數字證書。其中含有證書持有者資訊，公鑰資訊，hash演算法等。
伺服器把證書傳給瀏覽器，瀏覽器從中獲取伺服器公鑰。
CA機構頒發的數字證書有自己的一套防偽技術。
來源：https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/
數字簽名的製作過程：
CA機構擁有非對稱加密的私鑰和公鑰。
CA機構對證書明文資料用私鑰加密，得到數字簽名。
（其中有一步是對資料進行hash，這麼做一個是效能問題，hash演算法可以將任意長度的二進位制值引用為較短的且固定長度的二進位制值，所以處理速度會更快。另一個也有安全原因，這個相對較深，感興趣可以參考
https://crypto.stackexchange.com/questions/12768/why-hash-the-message-before-signing-it-with-rsa/12780#12780）
明文和數字簽名共同組成數字證書，頒發給網站。
瀏覽器拿到伺服器傳來的數字證書後，需要驗證它是不是真的（有沒有被篡改、掉包），過程如下：
拿到證書裡的明文資料和數字簽名後，
用CA機構的公鑰對S解密（由於是瀏覽器信任的機構，所以瀏覽器保有它的公鑰。詳情見下文），得到S’。
用證書裡指明的hash演算法對明文D進行hash得到D’。
顯然透過以上步驟，Data’應當等於S‘，除非明文或簽名被篡改。所以此時比較S’是否等於T’，等於則表明證書可信。
這種方式還可能被篡改嗎？
要篡改必須拿到CA機構的金鑰，不可能。
可能整個證書被調包嗎？
攻擊者是否可以模擬之前獲取瀏覽器金鑰X的方式獲取到伺服器傳給瀏覽器的證書，再換成自己的證書B傳給瀏覽器，瀏覽器拿到B裡的公鑰，用此公鑰加密瀏覽器金鑰X後發出去呢？證書裡關於網站的資訊有很多，瀏覽器拿到證書後解密，