對於IP協議,並不陌生。TP協議是TCP/IP協議簇中的核心協議,也是TCP/IP的載體。全部的TCP,UDP,ICMP及IGMP數據都以IP數據報格式傳輸。IP提供不可靠的,無鏈接的數據傳送服務。IP協議的做用是把各類數據報傳送給對方。要保證確實傳送到對方那裏,須要知足兩個重要條件:IP地址和MAC地址。
IP地址指明瞭節點被分配到的地址,MAC地址是指網卡所屬的固定地址.git
解決辦法:
通訊的加密:http協議經過和SSL或TLS的組合使用,加密http的通訊內容。
內容的加密:對http報文裏所含的內容進行加密,客戶端須要對http報文進行加密處理後再發送請求。算法
其實任何人均可以發起請求,而服務器只要接收到請求,無論對方是誰都會返回一個響應。(限於:發送端的IP地址和端口號沒有被服務器設定限制訪問的前提下)
證書:第三方,能夠證實服務器和客戶端實際存在。只要能確認通訊方(服務器或客戶端)持有的證書,就能夠判斷通訊方的真實意圖。瀏覽器
中間人攻擊。使用MD5和SHA-1等散列值校驗的方法,以及用來確認文件的數字簽名方法。緩存
HTTPS並不是是應用層的一種新協議,只是HTTP通訊接口部分使用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協議替代而已。
而SSL是採用一種公鑰加密的加密處理方式。安全
(1) 瀏覽器發送一個鏈接請求給服務器;服務器將本身的證書(包含服務器公鑰S_PuKey)、對稱加密算法種類及其餘相關信息返回客戶端;服務器
(2) 客戶端瀏覽器檢查服務器傳送到CA證書是否由本身信賴的CA中心簽發。如果,執行4步;不然,給客戶一個警告信息:詢問是否繼續訪問。網絡
(3) 客戶端瀏覽器比較證書裏的信息,如證書有效期、服務器域名和公鑰S_PK,與服務器傳回的信息是否一致,若是一致,則瀏覽器完成對服務器的身份認證。函數
(4) 服務器要求客戶端發送客戶端證書(包含客戶端公鑰C_PuKey)、支持的對稱加密方案及其餘相關信息。收到後,服務器進行相同的身份認證,若沒有經過驗證,則拒絕鏈接;性能
(5) 服務器根據客戶端瀏覽器發送到密碼種類,選擇一種加密程度最高的方案,用客戶端公鑰C_PuKey加密後通知到瀏覽器;網站
(6) 客戶端經過私鑰C_PrKey解密後,得知服務器選擇的加密方案,並選擇一個通話密鑰key,接着用服務器公鑰S_PuKey加密後發送給服務器;
(7) 服務器接收到的瀏覽器傳送到消息,用私鑰S_PrKey解密,得到通話密鑰key。
(8) 接下來的數據傳輸都使用該對稱密鑰key進行加密。
上面所述的是雙向認證 SSL 協議的具體通信過程,服務器和用戶雙方必須都有證書。因而可知,SSL協議是經過非對稱密鑰機制保證雙方身份認證,並完成創建鏈接,在實際數據通訊時經過對稱密鑰機制保障數據安全性
HTTP 自己是明文傳輸的,沒有通過任何安全處理。例如用戶在百度搜索了一個關鍵字,好比「蘋果手機」,中間者徹底可以查看到這個信息,而且有可能打電話過來騷擾用戶。也有一些用戶投訴使用百度時,發現首頁或者結果頁面浮了一個很長很大的廣告,這也確定是中間者往頁面插的廣告內容。若是劫持技術比較低劣的話,用戶甚至沒法訪問百度。
這裏提到的中間者主要指一些網絡節點,是用戶數據在瀏覽器和百度服務器中間傳輸必需要通過的節點。好比 WIFI 熱點,路由器,防火牆,反向代理,緩存服務器等。
在 HTTP 協議下,中間者能夠隨意嗅探用戶搜索內容,竊取隱私甚至篡改網頁。不過 HTTPS 是這些劫持行爲的剋星,可以徹底有效地防護。
整體來講,HTTPS 協議提供了三個強大的功能來對抗上述的劫持行爲:
1, 內容加密。瀏覽器到百度服務器的內容都是以加密形式傳輸,中間者沒法直接查看原始內容。
2, 身份認證。保證用戶訪問的是百度服務,即便被 DNS 劫持到了第三方站點,也會提醒用戶沒有訪問百度服務,有可能被劫持
3, 數據完整性。防止內容被第三方冒充或者篡改。
那 HTTPS 是如何作到上述三點的呢?下面從原理角度介紹一下。
對稱內容加密強度很是高,通常破解不了。但存在一個很大的問題就是沒法安全地生成和保管密鑰。假如客戶端軟件和服務器之間每次會話都使用固定的,相同的密鑰加密和解密,確定存在很大的安全隱患。若是有人從客戶端端獲取到了對稱密鑰,整個內容就不存在安全性了,並且管理海量的客戶端密鑰也是一件很複雜的事情。
非對稱加密主要用於密鑰交換(也叫密鑰協商),可以很好地解決這個問題。瀏覽器和服務器每次新建會話時都使用非對稱密鑰交換算法協商出對稱密鑰,使用這些對稱密鑰完成應用數據的加解密和驗證,整個會話過程當中的密鑰只在內存中生成和保存,並且每一個會話的對稱密鑰都不相同(除非會話複用),中間者沒法竊取。
非對稱密鑰交換很安全,但同時也是 HTTPS 性能和速度嚴重下降的「罪魁禍首」。想要知道 HTTPS 爲何影響速度,爲何消耗資源,就必定要理解非對稱密鑰交換的整個過程。
非對稱加密相比對稱加密更加安全,但也存在兩個明顯缺點:
1, CPU 計算資源消耗很是大。一次徹底 TLS 握手,密鑰交換時的非對稱解密計算量佔整個握手過程的 90% 以上。而對稱加密的計算量只至關於非對稱加密的 0.1%,若是應用層數據也使用非對稱加解密,性能開銷太大,沒法承受。
2, 非對稱加密算法對加密內容的長度有限制,不能超過公鑰長度。好比如今經常使用的公鑰長度是 2048 位,意味着待加密內容不能超過 256 個字節。
因此公鑰加密目前只能用來做密鑰交換或者內容簽名,不適合用來作應用層傳輸內容的加解密。
非對稱密鑰交換算法是整個 HTTPS 得以安全的基石,充分理解非對稱密鑰交換算法是理解 HTTPS 協議和功能的關鍵。
數字證書有兩個做用:
1, 身份受權。確保瀏覽器訪問的網站是通過 CA 驗證的可信任的網站。
2, 分發公鑰。每一個數字證書都包含了註冊者生成的公鑰。在 SSL 握手時會經過 certificate 消息傳輸給客戶端。好比前文提到的 RSA 證書公鑰加密及 ECDHE 的簽名都是使用的這個公鑰。
申請者拿到 CA 的證書並部署在網站服務器端,那瀏覽器發起握手接收到證書後,如何確認這個證書就是 CA 簽發的呢?怎樣避免第三方僞造這個證書?
答案就是數字簽名(digital signature)。數字簽名是證書的防僞標籤,目前使用最普遍的 SHA-RSA 數字簽名的製做和驗證過程以下:
1, 數字簽名的簽發。首先是使用哈希函數對待簽名內容進行安全哈希,生成消息摘要,而後使用 CA 本身的私鑰對消息摘要進行加密。
2, 數字簽名的校驗。使用 CA 的公鑰解密簽名,而後使用相同的簽名函數對待簽名證書內容進行簽名並和服務端數字簽名裏的簽名內容進行比較,若是相同就認爲校驗成功。
這部份內容比較好理解,跟平時的 md5 簽名相似,只不過安全要求要高不少。openssl 如今使用的完整性校驗算法有兩種:MD5 或者 SHA。因爲 MD5 在實際應用中存在衝突的可能性比較大,因此儘可能別採用 MD5 來驗證內容一致性。SHA 也不能使用 SHA0 和 SHA1,中國山東大學的王小云教授在 2005 年就宣佈破解了 SHA-1 完整版算法。
當使用SSL時,處理速度會變慢。HTTPS比http要慢2到100倍。
所以:請求非敏感信息則使用HTTP通訊,只有在包含我的信息等敏感數據時候,才使用HTTPS加密通訊。