之前一直對HTTPS有些理解囹圄，最近有時間，就花了2天時間深挖一下。

在學(xué)習(xí)某種技術(shù)方案的時候，我一般會對比著另外一種技術(shù)方案，這次沒有例外HTTPS VS HTTP。這兩種都是協(xié)議，而且在計算機(jī)七層協(xié)議中，算是應(yīng)用層協(xié)議，算是頂層協(xié)議了。什么是應(yīng)用層協(xié)議呢？舉個簡單的例子，張三寫了一串?dāng)?shù)字20190719 1730 1108 3014，他把這段數(shù)字的解碼格式告訴李四：前8位數(shù)字表示日期，第9到12位表示時間，13到16表示房號，17到20表示座位號。然后李四就根據(jù)這個解碼方式得到“在2019年7月19日13：30 到11樓08房找3014號桌的人”。只有知道這套協(xié)議的人才能正式解碼數(shù)字的意思，那么王五就拿到這段數(shù)據(jù)肯定會一臉蒙圈。那么協(xié)議就是張三跟李四說的那套解碼格式。當(dāng)然你會問，為什么需要這種協(xié)議，直接說人話不就好了么？那其實(shí)你有沒有發(fā)現(xiàn)那串?dāng)?shù)字遠(yuǎn)比它代表的完整的意思的字?jǐn)?shù)要少許多。
那應(yīng)用層協(xié)議中的應(yīng)用層是什么意思？那就要先說說傳輸層協(xié)議了。傳輸層協(xié)議的主要代表是TCP/UDP。至于TCP和UDP兩者的區(qū)別我就不說了。傳輸層協(xié)議負(fù)責(zé)數(shù)據(jù)的收/發(fā),計算機(jī)會將用戶數(shù)據(jù)全部塞到傳輸協(xié)議中，傳輸層把數(shù)據(jù)打包好，轉(zhuǎn)成0-1信號，在光纖中瘋狂跑起來，到達(dá)目標(biāo)設(shè)備的時候，傳輸層會根據(jù)協(xié)議，將用戶數(shù)據(jù)又卸下來，然后繼續(xù)瘋狂地收發(fā)。這些用戶數(shù)據(jù)就是來自應(yīng)用層，傳輸層和應(yīng)用層是分開獨(dú)立的，一個只負(fù)責(zé)搬運(yùn)數(shù)據(jù)，一個只負(fù)責(zé)打包數(shù)據(jù)，那么在我們的大部分見解中TCP負(fù)責(zé)幫運(yùn)HTTP或HTTPS數(shù)據(jù)，不過到了HTTP3的時候，好像搬運(yùn)工是UDP。如果大家有做過物聯(lián)網(wǎng)項目，就會對這個概念更加清晰了。不過以上描述忽略了很多細(xì)節(jié)，協(xié)議不會就是一種這么簡單的限定，它還有數(shù)據(jù)校驗，數(shù)據(jù)拼接等等的作用。
Http和Https都是應(yīng)用層協(xié)議，他們之間的區(qū)別前者不加密數(shù)據(jù)，而后者加密了。就是如果使用Http的話，張三的那串?dāng)?shù)據(jù)20190719 1730 1108 3014就會按著他原始的數(shù)據(jù)被打包起來。但是在Https的話，它可能打包成了DRW354T68E23472，就是一串被經(jīng)過加密后得到的數(shù)據(jù)，而且這數(shù)據(jù)讓普通人無法掌握到規(guī)律，只有拿到密鑰的人才能把它轉(zhuǎn)譯得到原始數(shù)據(jù)。而在這段加密解密的過程中SSL(TSL)協(xié)議扮演著很重要的角色。

SSL

既然知道Https = Http + SSL，那么我們著重研究SSL就好了。SSL協(xié)議過程使用了兩種類別的加密算法：對稱加密與非對稱加密。使用對稱加密算法來加密用戶數(shù)據(jù)，使用非對稱加密算法來加密對稱加密的密鑰。那么為什么要用兩種，兩種不同算法在這里扮演什么角色呢？

-對稱加密

對稱加密，即是使用相同的密鑰來加密和解密數(shù)據(jù)，關(guān)鍵的點(diǎn)是相同的密鑰。如果加密和解密的雙方都知道密鑰，那就很容易達(dá)成這件事情，不過對于互聯(lián)網(wǎng)來說，你張三（服務(wù)端）可能只有一個，但李四（前端）確有千千萬萬，你怎么確保張三一定隱秘地把密鑰（K）分發(fā)給這些形形色色的李四人物呢？那你就要看非對稱加密了。

-非對稱加密

非對稱加密，即是加密和解密方無需使用相同的密鑰，在該算法體系中，將這些不相同的密鑰稱為：私鑰與公鑰。那么私鑰，是不能公開的，公鑰你可以廣而告知，也就是張三（服務(wù)端）自己保留私鑰（S），千千萬萬個李四（前端）能拿到公鑰（P）。公鑰加密的東西只有私鑰能解開，私鑰加密的東西公鑰也能解開，但是公鑰加密的東西，公鑰不可能解開，就是這么神奇。那么張三就可以把公鑰P給到李四，然后張三在通過私鑰S去加密 對稱加密所需的密鑰K，然后把加密數(shù)據(jù)傳個李四，李四再拿公鑰P解密得到 對稱加密密鑰K。至此，張三和李四都拿到了K，就可以加密傳輸用戶數(shù)據(jù)了。那么現(xiàn)在來了兩個問題：

• 既然非對稱能加密解密數(shù)據(jù)，為什么在傳輸用戶數(shù)據(jù)的時候不直接使用非對稱加密？
• 萬一張三給李四傳輸公鑰P的時候，王五攔截了，然后把自己的公鑰P1給了李四，那是不是接著王五也可以把對稱加密密鑰K更改為自己的K2，傳給李四。然后李四發(fā)來數(shù)據(jù)的時候，就可以解密李四的數(shù)據(jù)呢？

解答第一個問題：非對稱加密有數(shù)據(jù)長度限制，算法效率比較低，一般不太適合用于普通的網(wǎng)絡(luò)數(shù)據(jù)加密中，大部分用在簽名過程。

解答第二個問題，請客官查看接下來的CA證書。

-第三方CA

既然擔(dān)心公鑰被篡改，那我們就得找JC了，而在互聯(lián)網(wǎng)中充當(dāng)公鑰保駕護(hù)航的第三方機(jī)構(gòu)就是扮演者JC的角色。它的工作內(nèi)容如下：

• 張三（服務(wù)端）請求第三方證書CA機(jī)構(gòu)生成可認(rèn)證的證書，而證書的內(nèi)容包含簽發(fā)者姓名，機(jī)構(gòu)，hash算法，簽名算法和過期時間等。
• CA 也是用非對稱加密的辦法。首先將這些信息，通過has算法得到has值，然后拿自己的私鑰S-CA去加密has值，has算法和張三的公鑰P。最后打包原始內(nèi)容和加密信息得到P-CA數(shù)據(jù)給到張三。
• 張三拿到P-CA數(shù)據(jù)后，把它傳給李四。李四電腦預(yù)裝了CA機(jī)構(gòu)的公鑰（一般系統(tǒng)安裝初期或者安裝瀏覽器的時候會植入到電腦中），則使用這個公鑰去解密P-CA數(shù)據(jù)，得到has算法和has值之后，再拿has算法對P-CA中原始數(shù)據(jù)進(jìn)行運(yùn)算得到has值，最后將運(yùn)算的has值與解密得到的has值對比，如果不匹配，則證明證書非法。否則驗證成功，并且取下公鑰。

設(shè)想，如果王五從中攔截，修改加密內(nèi)容或者自己也向CA機(jī)構(gòu)請求另一個證書在發(fā)給李四，會發(fā)生什么問題？首先修改加密內(nèi)容，導(dǎo)致李四無法用CA的公鑰解密；如果是取代證書的方式，則由于王五向CA機(jī)構(gòu)申請證書的時候產(chǎn)生的公鑰和私鑰對，與張三申請的時候產(chǎn)生的私鑰和密鑰對不一致，導(dǎo)致李四的CA公鑰無法解密王五的CA證書，驗證失敗。

-證書CER

張三向第三方請求證書的時候，其實(shí)就是申請cer文件的過程。就我們iOS開發(fā)者日常接觸最多的就是開發(fā)證書，生產(chǎn)證書，推送證書等等。
如果你記得的話，我們在Mac book中申請證書的時候，首先是打開鑰匙串管理工具，然后點(diǎn)擊從第三方CA機(jī)構(gòu)請求證書，最后生成一個CSR文件，并且會把證書的公鑰和私鑰都保留在了電腦本地（你可以查看要是串工具的keys菜單列，看看有沒有多了一對公鑰/私鑰）。最后上傳到開發(fā)者中心，到處cer文件到本地，安裝到鑰匙串。你會發(fā)現(xiàn)每個cer文件下都會有一個私鑰對應(yīng)著的，明顯的是cer保留著公鑰。
那么在開發(fā)過程中，我們需要那cer文件做代碼簽證，xcode會讀取cer文件，也就是讀取公鑰。XCode在代碼簽證的時候，會拿到這個公鑰和鑰匙串的私鑰去進(jìn)行驗證，如果密碼對不符合，則會簽名失敗。

當(dāng)然我們也看到過p12這樣的文件，其實(shí)你可以理解為私鑰的加密文件。你可以吧p12傳給別人，別人就獲得你的私鑰。這個p12經(jīng)常用到的地方是兩個：

• APNS推送。
• 多開發(fā)者合作。
  第一種其實(shí)就是給提供后臺私鑰，然后后臺通過該私鑰加密數(shù)據(jù)傳給APNS服務(wù)器，APNS通過開發(fā)者平臺的cer文件中的公鑰，解密數(shù)據(jù)，然后傳給蘋果手機(jī)，相反也是可行的。
  第二種 其實(shí)就是到出私鑰給第三人并安裝到鑰匙串，然后第三人再從公司蘋果開發(fā)者平臺下載對應(yīng)的cer文件，也安裝到鑰匙串，這樣xcode就可以把兩者都匹配到一起。