通俗的理解HTTPS以及SSL中的證書驗證
阿新 • • 發佈:2019-01-27
時間進入到2017年,細心的人在瀏覽器位址列中會發現,經常瀏覽的網站都是https打頭,最左邊也有綠色的安全鎖。其實全站https時代已經來臨。2014年百度完成了全網https的切換,2015年淘寶、天貓頁面全部https訪問,蘋果公司要求2016年底iOS APP實現https資訊傳輸。眾多大廠都不遺餘力地推進全面https,提升安全性,這對普通的使用者和移動應用開發者有何影響,需要理解和注意什麼,本篇來做簡單的介紹,瞭解https帶來的安全性和其中的證書驗證。一、HTTPS的安全性體現在哪HTTP(超文字傳輸協議,Hyper Text Transfer Protocol)是我們瀏覽網站資訊傳輸最廣泛的一種協議。HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)相比HTTP增加了一個S,就是安全的(Secure),這個安全體現在什麼地方呢?http中的資訊是明文傳輸的,也就是說很容易被監聽、截獲和篡改;具體來說在http中常用的post和get方法,也是我們在網站上註冊、登入帳號時要使用的請求方法,在網站頁面不做保護處理的情況下,帳號密碼這些資訊都將明文的在網路中傳輸;對於我們瀏覽的頁面內容,也都以字串的形式被輕鬆的看到。使用Fiddler軟體,將自己手機連線代理,看看哪些網站或應用還在用http,還在傳輸著什麼。HTTPS則是在原有的應用層協議HTTP之下,傳輸層TCP之上,增加了安全套接字層(SSL),來實現資訊的安全傳輸,提供了:(1)資料加密: 傳輸的資料是經過加密的(2)身份認證: 通過證書確認網站的真實性,在啟用雙向認證時,可確認使用者的合法性(3)內容完整性: 防止內容在傳輸過程中被篡改二、HTTPS安全性的基礎 HTTPS的安全性離不開SSL協議,理解SSL協議的實現離不開數字證書和非對稱加密。這裡不會詳細介紹SSL協議的實現過程,而是讓人能簡單理解SSL如何利用數字證書,實現其資料加密和身份認證的功能。對稱加密加密者和解密者共享金鑰,加密者用共享金鑰將明文變為密文,解密者用共享金鑰將密文變為明文;一般相比非對稱加密效率更高,但要求雙方提前共享金鑰。常見的有AES,DES等。非對稱加密加解密需要金鑰對實現,金鑰對包括公鑰(Public Key)和私鑰(Private Key),將明文用公鑰加密,私鑰解密,或者用私鑰加密,公鑰解密。常見的有RSA ,ECC等。注意一般將公鑰對外發布,大家都能獲得,但私鑰只有網站擁有者或特定的使用者擁有;而且效率相比對稱加密低,運算量大,時間更長。數字摘要 是將任意長度的輸入資料,經過單項雜湊後,產生固定長度的輸出資料。這麼做的一個好處是能將大量的輸入資訊轉換成較小的固定長度的資訊。另外單項雜湊保證了無法通過輸出的摘要資料還原原始的輸入資料;而且不同的輸入幾乎不可能產生相同的數字摘要。常見的摘要演算法如SHA,MD5等。注意的是網上常說的用MD5加密,那一般是不能解密的,因此不能算一種正常的加解密方法。數字簽名:類似於手寫簽名,證明是經過你本人確認的,無法抵賴。具體就是利用私鑰對原始資訊的數字摘要進行加密形成數字簽名,與原始資訊一起傳送給別人。對於接收資訊的人,由於公鑰能公開獲取到,因此對收到的數字簽名用公鑰解密,再和收到的原始資訊的數字摘要進行比對,就能確認是不是私鑰的擁有者傳送的內容,而且能確認中間有沒有被人修改。前面提到非對稱加密的運算量大,時間長,因此數字簽名都是對大量傳輸的資訊產生數字摘要後進行加密。數字證書 是一串身份資訊按照指定的格式排列後,包含證書頒發機構進行數字簽名的資料。常見的數字證書格式X.509 V3,儲存到檔案上一般一種為不含私鑰的DER格式,以cer或者crt為檔案字尾名,另一種為包含私鑰的PKCS格式,以pfx或者p12為字尾。數字證書中包括(不是全部):(1)數字證書持有者身份資訊 網站就包括所對應的URL或IP(2)該證書擁有者對應的該證書公鑰(3)證書頒發者資訊(4)證書頒發者用私鑰對證書持有者身份資訊和公鑰的簽名 使用的摘要和簽名演算法證書的驗證:1.兩級證書:直接由權威或可信任(自己可設定是否信任)機構頒發給使用者的證書因此有權威機構一個證書(根證書),頒發給使用者的一個證書驗證過程是使用頒發者的公鑰,採用要驗證的證書(後面稱使用者證書)中說明的簽名演算法,解密簽名,對比根據使用者證書上的持有者資訊等計算出的數字摘要,看是否一致。換種描述的說法:(1)使用者證書裡有:a.使用者資訊UInfob.簽名用到的摘要演算法H,和加解密演算法Sc.用頒發者私鑰簽名的使用者資訊摘要S(H(UInfo)) (就是使用者資訊數字摘要H(UInfo),按一定格式編碼後,私鑰加密後獲得S(H(UInfo)) )d.頒發者資訊(2)驗證使用者證書a.根據使用者證書裡的頒發者資訊找到頒發者證書,獲取頒發者公鑰;b.再用使用者證書裡說明的加解密演算法S解密簽名S(H(UInfo)) ,得到H(UInfo)'c.根據使用者證書中的摘要演算法H,自己重新計算使用者資訊摘要,得到H(UInfo)d.對比兩次的計算結果H(UInfo)'和H(UInfo),如果相同則驗證通過。(3)頒發者證書的驗證需要在電腦預置或自己安裝根證書,也就是頒發者的證書,作為認證的起點。2.證書鏈的驗證首先證書頒發機構(CA)的根證書,可以簽發子CA的證書,CA和子CA都可以稽核註冊者資訊,然後為使用者頒發證書。那麼從CA到子CA,再到使用者證書,構成了證書鏈。他的驗證可以仿照兩級證書的驗證,一步步往上追,直到使用者自己安裝的根證書現在再來看HTTPS中SSL保障安全傳輸的簡單流程:(1)首先使用者在瀏覽器中發起HTTPS連線請求時,先從網站(服務端)獲取了其證書;(2)瀏覽器驗證了網站證書有效性後,再對比證書中的URL或IP資訊和實際訪問的URL或IP是否一致;(3)都正確後再利用證書中的公鑰資訊,建立安全的資訊傳輸通道;(簡單來說,瀏覽器可以用公鑰加密一個共享金鑰給服務端,因為只有服務端有私鑰。詳細的SSL連線建立流程比這裡複雜的多,但基本原理類似)(4)如果客戶端將自己的證書發給網站,網站也可以確認使用者的合法性最後說明下HTTPS帶來的效能和流量的損失。首次訪問網站(服務端),建立SSL連結,客戶端需要獲取服務端的證書鏈,驗證證書的有效性。這裡證書鏈一般情況下就至少兩個證書1K多的資料量,而如果沒設定HTTP長連線,那麼會導致每次訪問請求都會產生握手連線過程,都會大的流淚消耗。好訊息是目前一般的Android網路開發庫,採用HTTP1.1,預設開啟了Keep-Alive設定,但是要注意平衡好超時時長。