前言
關於HTTPS的連線過程,也是老生常談的話題了。
其中涉及到的數字證書、電子簽名、SSL/TLS、對稱加密、非對稱加密
的問題總是讓人摸不清頭腦,不知道怎麼回答。
今天就和大家再熟悉熟悉這其中千絲萬縷的關係。
確實不安全!(HTTP協議傳輸)
傳統的HTTP
傳輸協議,是一種明文傳輸協議。也就是通訊過程中都沒有對資料進行加密,很容易洩漏資料。
比如洩漏了重要的使用者資訊、被偽造資料傳送、都會造成不小的問題。
所以有的朋友就想到可以自己對資料進行加密,但是這種自己加密資料的方法也存在了很多問題
,比如:
不夠安全
。雖然資料加了密看似安全了,但是加密的金鑰怎麼管理呢?這是個大問題,儲存在客戶端?引入外掛?感覺都不是什麼比較好的辦法,都還是有可能被破解。相容問題
。自己對資料加密,那麼就要涉及到對加密演算法的管理了,而加密演算法是在不斷髮展的,而這就要求客戶端和伺服器端要對加密保持更新相容,而且不能實時進行更新,需要線下更新程式碼邏輯。所以這也是一個比較麻煩的問題。效能問題
。通過程式碼去加密解密這個過程也是比較耗時的,會影響到效能。
所以,在原有的HTTP協議基礎之下就增加了一種協議——SSL/TLS
協議,形成新的較安全的網路協議——HTTPS
。
對資料進行加密~(HTTPS傳輸資料)
在之前的網路資料傳輸過程中我說過,對資料進行解析的一系列應用層的工作都是交給了瀏覽器和作業系統的TCP協議棧。
所以HTTPS
的加密解密工作自然也就是交給了瀏覽器,這樣就不存在上述的效能問題了。
具體怎麼做的呢?用到了對稱加密演算法
:
- 客戶端用對稱金鑰對資料進行加密。
- 伺服器端用對稱金鑰對資料進行解密。
有人就會問了,這不還是和剛才說到的一樣嗎?這個金鑰怎麼管理呢?
這就需要在正式傳輸資料之前 想辦法 把這個對稱金鑰告訴對方了。
而這個辦法就是——非對稱加密
。
怎麼告訴對方這個對稱金鑰?(非對稱加密)
大家都知道非對稱加密是分私鑰和公鑰
,也就是你通過公鑰加密資料,然後我用私鑰來解密。
私鑰只有自己有,所以只有自己能解開這個資料,即使中間人拿到資料,也破解不了。
放到實際客戶端伺服器通訊中,就是伺服器端將公鑰發給客戶端,然後客戶端拿這個公鑰對 對稱金鑰
進行加密,併發給伺服器端,只有客戶端有私鑰可以解這個含有對稱加密的密文。用張圖表示:
但是,公鑰是明文傳輸的呀,那麼中間人就可以利用這個公鑰偽造資料了:
所以怎麼解決呢?就需要這個訊息證明他是來自真正的伺服器端,拿到真正的公鑰,而不是偽造的,這就需要電子簽名
了。
我要證明我是我!(電子簽名)
電子簽名
其實也是一種非對稱加密
的用法。
它的使用方法是:
A使用私鑰對資料的雜湊值
進行加密,這個加密後的密文就叫做簽名
,然後將這個密文和資料本身傳輸給B。
B拿到後,簽名用公鑰
解密出來,然後和傳過來資料的雜湊值做比較,如果一樣,就說明這個簽名確實是A籤的,而且只有A才可以籤,因為只有A有私鑰
。
反應實際情況就是:
伺服器端將資料,也就是我們要傳的資料(公鑰),用另外的私鑰簽名
資料的雜湊值,然後和資料(公鑰)
一起傳過去。
然後客戶端用另外的公鑰對簽名解密,如果解密資料和資料(公鑰)的雜湊值一致,就能證明來源正確
,不是被偽造的。
但是,這個用作簽名的另外的私鑰和另外的公鑰
怎麼來的呢?這就需要強大的CA
來驗證了。
強大的後臺機構~(數字證書)
證書頒發機構(CA, Certificate Authority)即頒發數字證書的機構。是負責發放和管理數字證書的權威機構,並作為電子商務交易中受信任的第三方,承擔公鑰體系中公鑰的合法性檢驗的責任。
實際情況中,伺服器會拿自己的公鑰以及伺服器的一些資訊傳給CA
,然後CA
會返回給伺服器一個數字證書
,這個證書裡面包括:
- 伺服器的公鑰
- 簽名演算法
- 伺服器的資訊,包括主機名等。
- CA自己的私鑰對這個證書的簽名
然後伺服器將這個證書在連線階段傳給客戶端
,客戶端怎麼驗證呢?
細心的小夥伴肯定知道,每個客戶端,不管是電腦、手機都有自帶的系統根證書
,其中就會包括伺服器數字證書的簽發機構
。所以系統的根證書會用他們的公鑰
幫我們對數字證書的簽名進行解密,然後和證書裡面的資料雜湊值進行對比,如果一樣,則代表來源
是正確的,資料
是沒有被修改的。
當然中間人也是可以通過CA申請證書的,但是證書中會有伺服器的主機名,這個主機名(域名、IP)
就可以驗證你的來源是來源自哪個主機。
擴充套件一下:
其實在伺服器證書和根證書中間還有一層結構:叫中級證書
,我們可以任意點開一個網頁,點選左上角的?按鈕就可以看到證書詳情:
可以看到一般完整的SSL/TLS
證書有三層結構:
第一層:根證書
。也就是客戶端自帶的那些。第二層:中級證書
。一般根證書是不會直接頒發伺服器證書的,因為這種行為比較危險,如果發現錯誤頒發就很麻煩,需要涉及到跟證書的修改。所以一般會引用中間證書,根證書對中間證書進行簽名,然後中間證書再對伺服器證書進行簽名,一層套一層。第三層:伺服器證書
。也就是跟我們伺服器相關的這個證書了。
再來個圖總結下:
兢兢業業的好夥伴❤️(SSL/TLS)
以上說的所有的工作都是HTTPS裡面的S
幫我們做的,也就是SSL/TLS
協議。
SSL:(Secure Socket Layer,安全套接字層),位於可靠的面向連線的網路層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性,以實現客戶端和伺服器之間的安全通訊。
這個過程其實就是在傳統的傳輸層——HTTP層,拿到資料後交給SSL層,然後進行認證、加密等操作。
而TLS是SSL的升級版,主要目標是使SSL更安全,並使協議的規範更精確和完善。
今天要說的就這麼多了。
其實只說了HTTPS連線過程中的一個步驟,即數字證書的傳送。
完整的連線過程下週再說吧,來不起了哈哈。下週會出一個網路問題全解的文章,期待一下~
參考
https://wetest.qq.com/lab/view/110.html
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
https://www.zhihu.com/question/52790301
拜拜
感謝大家的閱讀,有一起學習的小夥伴可以關注下我的公眾號——碼上積木❤️❤️
每日一個知識點,積少成多,建立知識體系架構。
這裡有一群很好的Android小夥伴,歡迎大家加入~