1. 如何實現https加密傳輸
1、生成證書請求文件CSR
用戶進行https證書申請的第一步就是要生成CSR證書請求文件,系統會產生2個密鑰,一個是公鑰就是這個CSR文件,另外一個是私鑰,存放在伺服器上。要生成CSR文件,站長可以參考WEB SERVER的文檔,一般APACHE等,使用OPENSSL命令行來生成KEY+CSR2個文件,Tomcat,JBoss,Resin等使用KEYTOOL來生成JKS和CSR文件,IIS通過向導建立一個掛起的請求和一個CSR文件。
溫馨提醒:如果是在沃通申請https證書,其數字證書商店(https://buy.wosign.com)已經支持CSR文件由系統自動生成,用戶無需事先在Web伺服器上生成CSR文件。請參考:SSL證書請求文件(CSR)生成指南網頁鏈接
2、將CSR提交給CA機構認證
CA機構一般有2種認證方式:
(1)域名認證,一般通過對管理員郵箱認證的方式,這種方式認證速度快,但是簽發的證書中沒有企業的名稱,只顯示網站域名,也就是我們經常說的域名型https證書。
(2)企業文檔認證,需要提供企業的營業執照。國外https證書申請CA認證一般一小時之內,緊急時5分鍾。
同時認證以上2種方式的證書,叫EV https證書,EV https證書可以使瀏覽器地址欄變成綠色,所以認證也最嚴格。EV https證書多應用於金融、電商、證券等對信息安全保護要求較高的領域。
3、獲取https證書並安裝
在收到CA機構簽發的https證書後,將https證書部署到伺服器上,一般APACHE文件直接將KEY+CER復制到文件上,然後修改HTTPD.CONF文件;TOMCAT等需要將CA簽發的證書CER文件導入JKS文件後,復制到伺服器,然後修改SERVER.XML;IIS需要處理掛起的請求,將CER文件導入。
2. HTTPS 到底加密了些什麼內容
https其實是有兩部分組成:http + SSL / TLS,也就是在http上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密,所以傳輸的數據都是加密後的數據。具體是如何進行加密,解密,驗證的,且看下圖。
1. 客戶端發起https請求
客戶端發起https請求就是指用戶在瀏覽器里輸入一個https網址,然後連接到server的443埠。
2. 伺服器端的配置
採用https協議的伺服器必須要有一套SSL數字證書,需要向CA組織(如WoSign沃通CA)申請。這套SSL證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解,可以想像成一把鑰匙和一個鎖頭,只是全世界只有你一個人有這把鑰匙,你可以把鎖頭給別人,別人可以用這個鎖把重要的東西鎖起來,然後發給你,因為只有你一個人有這把鑰匙,所以只有你才能看到被這把鎖鎖起來的東西。
3. 傳送證書
這個證書其實就是公鑰,只是包含了很多信息,如證書的頒發機構,證書過期時間等等。
4. 客戶端解析證書
這部分工作是有客戶端的TLS來完成的,首先會驗證公鑰是否有效,比如頒發機構,過期時間等等,如果發現異常,則會彈出一個警告框,提示證書存在問題。如果證書沒有問題,那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的,把隨機值用鎖頭鎖起來,這樣除非有鑰匙,不然看不到被鎖住的內容。
5. 傳送加密信息
這部分傳送的是用SSL證書加密後的隨機值,目的就是讓服務端得到這個隨機值,以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。
6. 服務段解密信息
服務端用私鑰解密後,得到了客戶端傳過來的隨機值(私鑰),然後把內容通過該值進行對稱加密。所謂對稱加密就是,將信息和私鑰通過某種演算法混合在一起,這樣除非知道私鑰,不然無法獲取內容,而正好客戶端和服務端都知道這個私鑰,所以只要加密演算法夠彪悍,私鑰夠復雜,數據就夠安全。
7. 傳輸加密後的信息
這部分信息是服務段用私鑰加密後的信息,可以在客戶端被還原。
8. 客戶端解密信息
客戶端用之前生成的私鑰解密服務段傳過來的信息,於是獲取了解密後的內容。整個過程第三方即使監聽到了數據,也束手無策。
3. HTTPS 加密演算法過程
1、HTTP 協議(HyperText Transfer Protocol,超文本傳輸協議):是客戶端瀏覽器或其他程序與Web伺服器之間的應用層通信協議 。
2、HTTPS 協議(HyperText Transfer Protocol over Secure Socket Layer):可以理解為HTTP+SSL/TLS, 即 HTTP 下加入 SSL 層,HTTPS 的安全基礎是 SSL,因此加密的詳細內容就需要 SSL,用於安全的 HTTP 數據傳輸。
3、SSL(Secure Socket Layer,安全套接字層):1994年為 Netscape 所研發,SSL 協議位於 TCP/IP 協議與各種應用層協議之間,為數據通訊提供安全支持。
4、TLS(Transport Layer Security,傳輸層安全):其前身是 SSL,它最初的幾個版本(SSL 1.0、SSL 2.0、SSL 3.0)。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS。
1、對稱加密
有流式、分組兩種,加密和解密都是使用的同一個密鑰。
例如:DES、AES-GCM、ChaCha20-Poly1305等
2、非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的,分別稱為:公鑰、私鑰,公鑰和演算法都是公開的,私鑰是保密的。非對稱加密演算法性能較低,但是安全性超強,由於其加密特性,非對稱加密演算法能加密的數據長度也是有限的。
例如:RSA、DSA、ECDSA、 DH、ECDHE
3、哈希演算法
將任意長度的信息轉換為較短的固定長度的值,通常其長度要比信息小得多,且演算法不可逆。
例如:MD5、SHA-1、SHA-2、SHA-256 等
4、數字簽名
簽名就是在信息的後面再加上一段內容(信息經過hash後的值),可以證明信息沒有被修改過。hash值一般都會加密後(也就是簽名)再和信息一起發送,以保證這個hash值不被修改。
C++音視頻開發學習資料 :點擊 音視頻開發(資料文檔+視頻教程+面試題)(FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP)
HTTP協議在瀏覽器/伺服器間進行數據的傳輸是明文的,不做任何的加密,通俗來說,就是「裸奔」,這樣會產生什麼樣的問題那,我們來舉一個例子:
在這里插入圖片描述
上述我們通過兩個人物模仿了伺服器和客戶端的交互,我們可以看出,小明和小花之間進行數據通信的時候採用的是明文傳輸的、那麼此時很有可能被中間人獲取信息、並進行數據篡改,這種行為就叫 中間人攻擊。
所以 HTTP 傳輸面臨的風險有:
(1) 竊聽風險:黑客可以獲知通信內容。
(2) 篡改風險:黑客可以修改通信內容。
(3) 冒充風險:黑客可以冒充他人身份參與通信。
哈哈、此時你是不是不能很愉快的上網沖浪了呀,別擔心,我們此時可以對明文進行加密:
這樣是不是比原來安全多了呀!但是這樣就足夠安全了嗎?顯然不是的,如果小明和小花在第一次聊天的時候,信息被中間人截取到了,那麼中間人是不是也就有密鑰了,同樣可以對數據進行加解密和修改了那
這可怎麼辦那? 加密的數據還是不安全的啊? 別急,上面我們採用的是對稱加密(換句話說就是我們發送的密鑰技能加密、也能解密,那麼中間人只要拿到密鑰消息對他而言就是透明的了),我們還可以採用非對稱加密方式進行加密數據(非對稱加密一般都會有一個私鑰和公鑰組成。可以通過公鑰加密,私鑰解密,也可以通過私鑰加密,公鑰解密兩種方式) ,對密鑰的傳送在格外加一層保護,當小明和小花在建立通信的時候,小花會把公鑰KEY發送給小明,當小明拿到公鑰KEY 後,會自己生成一個 密鑰 KEY2 , 並用 KEY 對KEY2 進行加密(此時小明用的是公鑰加密)
在通信過程中,即使中間人一開始就獲取到了公鑰KEY ,但是他不知道私鑰,就對數據無法進行解密,仍舊是沒辦法獲取KEY2。這樣加密後,數據是不是就安全多了呀。這種情況下就可以和妹子愉快的進行聊天了嗎?別急、所謂道高一尺魔高一丈,常言道:流氓不可怕,就怕流氓有文化。這種狀態下我們的數據,相當來說是比較安全的,但是如果此時中間人獲取公鑰後,發送給小明一個偽公鑰,又會產生什麼問題那?
好吧,說到這里,大家是不是快恨死這個中間人了啊,哈哈~~~還有據俗話別忘記了,魔高一尺道高一丈,對於這種情況。我們可以藉助與第三方證書平台,證書平台具備產生證書的功能,伺服器(小花)可以去證書機構申請證書,證書機構通過小花提供的信息(網址、機構、法人等、公鑰),生成公鑰和私鑰(證書機構的),通過私鑰進行數據的非對稱加密生成證書、將證書頒發給小花。那麼此時小花就可以在進行數據交互的時候,傳遞證書了。
小明只需要知道證書的發證機構、就可以很方便的獲取到證書的公鑰、從而對證書進行校驗並獲取公鑰、然後進行後續的操作。
那麼此時小夥伴是不是又有疑問了,如果 中間人 獲取到證書、並偽造證書給小明、怎麼破???
不錯不錯、如果大家有這個想法的話,說明大家都在認真思考了。那麼我們假設中間人獲取到了證書、中間人也可以在證書機構獲取公鑰,並通過證書機構公鑰獲取 伺服器發送的公鑰,中間人此時也可以自己生成公鑰,並向證書機構申請證書、並發送偽證書給小明,但是因為證書是經過簽名認證的,包含(網址、機構、法人等、公鑰)等信息,小明在拿到偽證書後,通過證書公鑰很容易就發現證書是不合法的(網址、法人的信息可定不符,否則申請不到證書的)。
上述我們分享的內容就是HTTPS的主體思想,HTTPS增加了SSL安全層,上述介紹的所有認證流程都是在SSL安全層完成驗證的。今天我就分享HTTPS的實現原理就說這么多了。 ﹏
HTTPS 缺點:
(1)SSL 證書費用很高,以及其在伺服器上的部署、更新維護非常繁瑣。
(2)HTTPS 降低用戶訪問速度(多次握手)。
(3)網站改用HTTPS 以後,由HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時(多數網站採用302跳轉)。
(4)HTTPS 涉及到的安全演算法會消耗 CPU 資源,需要增加大量機器(https訪問過程需要加解密)。