HTTPS流程簡單介紹

        假如我們現在要登陸一個網站，輸入使用者名稱和密碼併傳送給伺服器，驗證通過之後才能登陸。很顯然，使用者名稱和密碼在傳輸過程中不能被別人知道，要不就洩密了。所以，我們給在每一次和伺服器建立連線的最開始，自己先隨機定一個加密密碼，稱之為金鑰，並把這個金鑰給伺服器，這樣伺服器和我們自己都知道了這個金鑰，接下來，我們用這個金鑰加密使用者名稱和密碼，這樣，別人攔截到這個加密後的使用者名稱和密碼，他也看不懂，但是由於伺服器也有金鑰，因此伺服器是可以解開這個資訊的。

        有一個問題：這樣做雖然能保證壞人看不懂這個密碼，但是，如果他偽裝成我們，把這個加密後的使用者名稱和密碼提供給伺服器，伺服器以為這就是我們自己，然後用我們的金鑰解密，解密之後的資訊依然是正確的，登陸驗證還是會過，壞人依舊可以拿到我們的資料。要解開這個問題，有種方法，就是保證伺服器能夠識別出每個人的身份，不會用我們的金鑰去解壞人提供的使用者名稱和密碼。但是這種方法無法實現，因為網路傳輸的模型是固定的，就像寫信，無論怎麼驗證身份，給使用者發“令牌”，壞人總可以攔截到最開始的那塊“令牌”。

        因此這個方法不能考慮，我們換一種思維，就是讓伺服器不怕壞人偽裝，即便伺服器被騙了，給了壞人想要的資料，壞人也看不懂。想要實現這個方法並不難，只要讓伺服器把傳回來的資料，也用剛才我們隨機定的金鑰加密就可以了。這樣壞人雖然拿到了資料，可以他沒有金鑰，也沒辦法解密，依然看不懂這些伺服器發回來的資訊。

        但是，如果壞人拿到了我們的金鑰，就可以解開這些資訊了。而壞人如何拿到我們的金鑰呢？由於我們是在和伺服器通訊的一開始，把金鑰傳給伺服器的，如果壞人從這一步下手，就可以攔截到我們的金鑰。

        因此，我們要把最開始傳給伺服器的金鑰也加密，讓壞人攔截到也看不懂，只有伺服器能解開。如果解碼方式由我們來定，我們就必須得把解碼方式告訴伺服器，要不雖然壞人解不了，但伺服器也解不了。可是如果我們要把解碼方式傳給伺服器，那就又留給壞人攔截的機會了。因此解碼方式不能由我們來定，而要由伺服器來定，而且伺服器不能把解碼方式告訴任何人，包括我們自己，因為伺服器根本不能讓解碼方式出現在任何傳輸路線上，這樣又會給壞人“劫道”的機會。

       但是伺服器還是得告訴我們加密方式，要不然我們隨意加密，伺服器通過私有的解碼方式也沒法解。這時，就需要一種演算法，讓解碼方式和加密方式是獨立的，即便知道加密方式，也無法推匯出解碼方式。但是加密方式加密的資料，卻只能用解碼方式來解（https使用的的rsa演算法，解碼方式也可以用來加密，這時候用加密方式就可以解密！），無法通過逆向操作加密方式來解密。這樣伺服器就可以把加密方式告訴我們，不怕壞人攔截。

       這就是非對稱加密。伺服器有一個自己的解碼方式，稱之為私鑰，伺服器不會將私鑰告訴任何人，不會讓私鑰出現在任何可能被“攔截”的路上。而傳給我們的加密方式，稱之為公鑰（私鑰加密公鑰解，公鑰加密私鑰解）。在我們和伺服器建立通訊的最開始，伺服器把公鑰給我們；然後我們再隨機生成一個金鑰，這個金鑰是用來對稱加密的（也就是說，用這個金鑰加密的資料用這個金鑰就可以解）；之後，我們用公鑰把隨機金鑰加密，傳給伺服器，伺服器通過私鑰來解密，得到我們的隨機金鑰並儲存。再之後的通訊資料，都用隨機金鑰來加密。

        這樣一來，壞人攔截到我們傳給伺服器的隨機金鑰，由於攔截到的隨機金鑰是加密的，壞人根本不能用；他想解密得到真正的隨機金鑰，也無法做到---因為解密需要私鑰，而私鑰在伺服器嚴密看管，除了伺服器沒人知道  。因此壞人無法得到真正的隨機金鑰，這樣即使攔截到使用者名稱和密碼，壞人不僅看不懂；而且冒充我們的身份把使用者名稱和密碼發給伺服器之後，騙過了伺服器得到使用者資料，這些使用者資料由於壞人沒有隨機金鑰也沒法看懂。

       但是還有一個問題，就是我們第一次跟伺服器發請求的時候，如果壞人攔截到了，並冒充伺服器，用他自己的私鑰發給我們，我們就會誤認為壞人是真正的伺服器，從而用壞人的公鑰來加密我們生成的隨機金鑰，壞人再攔截一次，攔截到我們傳送的加密後的隨機金鑰，就能破解，因為我們是用壞人的私鑰加密的，壞人用自己的公鑰即可解密。

       因此，我們必須要保證第一次收到的私鑰必須是伺服器本人的私鑰。所以我們就要求，伺服器要發來一個證明“傳送者是本人”的證書，證書裡包含公鑰。我們收到證書後，再去驗證證書的合法性。

       但是這又帶來一個問題，那就是怎麼驗證證書呢？如果壞人攔截到證書，把證書裡面的公鑰替換成自己的公鑰，我們能麼驗證出來這是一個非法證書呢？有個解決辦法，那就時把證書裡面的資訊都加密了。那下面的問題就是，用什麼樣的金鑰加密呢？對稱型別的金鑰肯定不行，因為對稱加密的金鑰必須用非對稱加密的方式來傳輸，但是現在我們還不知道非對稱加密的公鑰；那用伺服器的公鑰加密？不可能，因為我們不可能會知道私鑰；那用伺服器的私鑰加密？可以，我們用伺服器的公鑰就可以解。但是我們現在需要的就是公鑰啊！我們現在請求的就是公鑰，包含公鑰資訊的證書還必須用公鑰解，那是一個無法跳出的迴圈啊！

       因此伺服器加密的證書，根本就不能讓伺服器自己加密；實際上，伺服器的證書，是向合法的CA（Certification Authority,證書頒發機構）買來的，買的時候，先告訴CA自己的公鑰，以及其他的基本資訊，如姓名、公司、地址、證書有效期等。CA把這些資訊連同CA自己的證書，用CA自己的私鑰加密，然後發給買證書的公司。

       而和我們通訊的伺服器，它的證書就是從CA那裡買來的。一般瀏覽器內建了幾個擁有根證書的權威CA的公鑰，當瀏覽器收到伺服器發來的證書後，瀏覽器會根據證書上寫的CA，來找到自己內建CA對應的公鑰，用這個公鑰就可以解開證書的資訊（因為證書是用CA的私鑰加密的）。而壞人如果攔截到伺服器發來的證書後，由於這個證書瀏覽器會用對應的CA的公鑰解碼，這就要求壞人要修改證書資訊，必須修改完了再用CA私鑰加密，但是CA的私鑰又不可能得到，因此壞人就無法修改證書資訊，這樣瀏覽器得到的一定是原本的證書，因此公鑰也就是真正伺服器來的公鑰，而不是壞人的公鑰，因此之後的通訊，壞人無法破解。