一、前言：
先來觀察這兩張圖辽俗，第一張訪問域名http://www.12306.cn飞蛹，谷歌瀏覽器提示不安全鏈接姑尺，第二張是https://kyfw.12306.cn/otn/regist/init，瀏覽器顯示安全并蝗，為什么會這樣子呢祭犯？2017年1月發(fā)布的Chrome 56瀏覽器開始把收集密碼或信用卡數據的HTTP頁面標記為“不安全”，若用戶使用2017年10月推出的Chrome 62借卧，帶有輸入數據的HTTP頁面和所有以無痕模式瀏覽的HTTP頁面都會被標記為“不安全”盹憎，此外，蘋果公司強制所有iOS App在2017年1月1日前使用HTTPS加密铐刘。
二陪每、HTTP和HTTPS發(fā)展歷史
什么是HTTP?
超文本傳輸協(xié)議，是一個基于請求與響應镰吵，無狀態(tài)的檩禾，應用層的協(xié)議，嘲碳溃基于TCP/IP協(xié)議傳輸數據盼产，互聯(lián)網上應用最為廣泛的一種網絡協(xié)議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法勺馆。
發(fā)展歷史：
這個Akamai公司建立的一個官方的演示戏售，使用HTTP/1.1和HTTP/2同時請求379張圖片，觀察請求的時間草穆，明顯看出HTTP/2性能占優(yōu)勢灌灾。
多路復用：通過單一的HTTP/2連接請求發(fā)起多重的請求-響應消息，多個請求stream共享一個TCP連接悲柱，實現(xiàn)多留并行而不是依賴建立多個TCP連接锋喜。
HTTP報文格式
什么是HTTPS？
《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP豌鸡。HTTPS是一種通過計算機網絡進行安全通信的傳輸協(xié)議嘿般，經由HTTP進行通信，利用SSL/TLS建立全信道涯冠，加密數據包炉奴。HTTPS使用的主要目的是提供對網站服務器的身份認證，同時保護交換數據的隱私與完整性功偿。
PS:TLS是傳輸層加密協(xié)議盆佣，前身是SSL協(xié)議往堡，由網景公司1995年發(fā)布，有時候兩者不區(qū)分共耍。
參考連接：
1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/
2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
3.https://tools.ietf.org/html/rfc1945
4.https://http2.github.io/http2-spec/
5.https://www.zhihu.com/question/34074946
三虑灰、HTTP VS HTTPS
HTTP特點：
1.無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力痹兜，比如訪問一個網站需要反復進行登錄操作
2.無連接：HTTP/1.1之前穆咐，由于無狀態(tài)特點，每次請求需要通過TCP三次握手四次揮手字旭，和服務器重新建立連接对湃。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區(qū)別是否已經響應過用戶的請求遗淳，所以每次需要重新響應請求拍柒，需要耗費不必要的時間和流量。
3.基于請求和響應：基本的特性屈暗，由客戶端發(fā)起請求拆讯，服務端響應
4.簡單快速、靈活
5.通信使用明文养叛、請求和響應不會對通信方進行確認种呐、無法保護數據的完整性
下面通過一個簡單的抓包實驗觀察使用HTTP請求傳輸的數據：
結果分析：HTTP協(xié)議傳輸數據以明文形式顯示
針對無狀態(tài)的一些解決策略：
場景：逛電商商場用戶需要使用的時間比較長，需要對用戶一段時間的HTTP通信狀態(tài)進行保存弃甥，比如執(zhí)行一次登陸操作爽室，在30分鐘內所有的請求都不需要再次登陸。
- 1.通過Cookie/Session技術
- 2.HTTP/1.1持久連接（HTTP keep-alive）方法淆攻，只要任意一端沒有明確提出斷開連接阔墩，則保持TCP連接狀態(tài)，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接
HTTPS特點：
基于HTTP協(xié)議瓶珊，通過SSL或TLS提供加密處理數據戈擒、驗證對方身份以及數據完整性保護
通過抓包可以看到數據不是明文傳輸，而且HTTPS有如下特點：
- 1.內容加密：采用混合加密技術艰毒，中間者無法直接查看明文內容
- 2.驗證身份：通過證書認證客戶端訪問的是自己的服務器
- 3.保護數據完整性：防止傳輸的內容被中間人冒充或者篡改
混合加密：結合非對稱加密和對稱加密技術∷汛眩客戶端使用對稱加密生成密鑰對傳輸數據進行加密丑瞧，然后使用非對稱加密的公鑰再對秘鑰進行加密，所以網絡上傳輸的數據是被秘鑰加密的密文和用公鑰加密后的秘密秘鑰蜀肘，因此即使被黑客截取绊汹，由于沒有私鑰，無法獲取到加密明文的秘鑰扮宠，便無法獲取到明文數據西乖。
數字摘要：通過單向hash函數對原文進行哈希狐榔，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同获雕，同樣的明文其摘要必定一致薄腻，并且即使知道了摘要也不能反推出明文。
數字簽名技術：數字簽名建立在公鑰加密體制基礎上届案，是公鑰加密技術的另一類應用庵楷。它把公鑰加密技術和數字摘要結合起來，形成了實用的數字簽名技術楣颠。
- 收方能夠證實發(fā)送方的真實身份尽纽；
- 發(fā)送方事后不能否認所發(fā)送過的報文；
- 收方或非法者不能偽造童漩、篡改報文弄贿。
非對稱加密過程需要用到公鑰進行加密，那么公鑰從何而來矫膨？其實公鑰就被包含在數字證書中差凹，數字證書通常來說是由受信任的數字證書頒發(fā)機構CA，在驗證服務器身份后頒發(fā)豆拨，證書中包含了一個密鑰對（公鑰和私鑰）和所有者識別信息直奋。數字證書被放到服務端，具有服務器身份驗證和數據傳輸加密功能施禾。
四脚线、HTTP通信傳輸
客戶端輸入URL回車，DNS解析域名得到服務器的IP地址弥搞，服務器在80端口監(jiān)聽客戶端請求邮绿，端口通過TCP/IP協(xié)議（可以通過Socket實現(xiàn)）建立連接。HTTP屬于TCP/IP模型中的運用層協(xié)議攀例，所以通信的過程其實是對應數據的入棧和出棧船逮。
報文從運用層傳送到運輸層，運輸層通過TCP三次握手和服務器建立連接粤铭，四次揮手釋放連接挖胃。
為什么需要三次握手呢？
為了防止已失效的連接請求報文段突然又傳送到了服務端梆惯，因而產生錯誤酱鸭。
比如：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了垛吗，以致延誤到連接釋放以后的某個時間才到達server凹髓。本來這是一個早已失效的報文段，但是server收到此失效的連接請求報文段后怯屉，就誤認為是client再次發(fā)出的一個新的連接請求蔚舀，于是就向client發(fā)出確認報文段饵沧，同意建立連接。假設不采用“三次握手”赌躺，那么只要server發(fā)出確認狼牺，新的連接就建立了，由于client并沒有發(fā)出建立連接的請求寿谴，因此不會理睬server的確認锁右，也不會向server發(fā)送數據，但server卻以為新的運輸連接已經建立讶泰，并一直等待client發(fā)來數據咏瑟。所以沒有采用“三次握手”，這種情況下server的很多資源就白白浪費掉了痪署。
為什么需要四次揮手呢码泞？
TCP是全雙工模式，當client發(fā)出FIN報文段時狼犯，只是表示client已經沒有數據要發(fā)送了余寥，client告訴server，它的數據已經全部發(fā)送完畢了悯森；但是宋舷，這個時候client還是可以接受來server的數據；當server返回ACK報文段時瓢姻，表示它已經知道client沒有數據發(fā)送了祝蝠，但是server還是可以發(fā)送數據到client的；當server也發(fā)送了FIN報文段時幻碱，這個時候就表示server也沒有數據要發(fā)送了绎狭，就會告訴client，我也沒有數據要發(fā)送了褥傍，如果收到client確認報文段儡嘶，之后彼此就會愉快的中斷這次TCP連接。
五恍风、HTTPS實現(xiàn)原理
SSL建立連接過程
1.client向server發(fā)送請求https://baidu.com蹦狂，然后連接到server的443端口，發(fā)送的信息主要是隨機值1和客戶端支持的加密算法朋贬。
2.server接收到信息之后給予client響應握手信息鸥咖，包括隨機值2和匹配好的協(xié)商加密算法，這個加密算法一定是client發(fā)送給server加密算法的子集兄世。
3.隨即server給client發(fā)送第二個響應報文是數字證書。服務端必須要有一套數字證書啊研，可以自己制作御滩，也可以向組織申請鸥拧。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問削解，而使用受信任的公司申請的證書則不會彈出提示頁面富弦，這套證書其實就是一對公鑰和私鑰。傳送證書氛驮，這個證書其實就是公鑰腕柜，只是包含了很多信息，如證書的頒發(fā)機構矫废，過期時間盏缤、服務端的公鑰，第三方證書認證機構(CA)的簽名蓖扑，服務端的域名信息等內容唉铜。
4.客戶端解析證書，這部分工作是由客戶端的TLS來完成的律杠，首先會驗證公鑰是否有效潭流，比如頒發(fā)機構，過期時間等等柜去，如果發(fā)現(xiàn)異常灰嫉，則會彈出一個警告框，提示證書存在問題嗓奢。如果證書沒有問題讼撒，那么就生成一個隨即值（預主秘鑰）。
5.客戶端認證證書通過之后蔓罚，接下來是通過隨機值1椿肩、隨機值2和預主秘鑰組裝會話秘鑰。然后通過證書的公鑰加密會話秘鑰豺谈。
6.傳送加密信息郑象，這部分傳送的是用證書加密后的會話秘鑰，目的就是讓服務端使用秘鑰解密得到隨機值1茬末、隨機值2和預主秘鑰厂榛。
7.服務端解密得到隨機值1、隨機值2和預主秘鑰丽惭，然后組裝會話秘鑰击奶，跟客戶端會話秘鑰相同。
8.客戶端通過會話秘鑰加密一條消息發(fā)送給服務端责掏，主要驗證服務端是否正常接受客戶端加密的消息柜砾。
9.同樣服務端也會通過會話秘鑰加密一條消息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連接建立完成了换衬。
問題：
1.怎么保證保證服務器給客戶端下發(fā)的公鑰是真正的公鑰痰驱，而不是中間人偽造的公鑰呢证芭？
2.證書如何安全傳輸，被掉包了怎么辦担映？
數字證書內容
包括了加密后服務器的公鑰废士、權威機構的信息、服務器域名蝇完，還有經過CA私鑰簽名之后的證書內容（經過先通過Hash函數計算得到證書數字摘要官硝，然后用權威機構私鑰加密數字摘要得到數字簽名)，簽名計算方法以及證書對應的域名短蜕。
驗證證書安全性過程
1.當客戶端收到這個證書之后氢架，使用本地配置的權威機構的公鑰對證書進行解密得到服務端的公鑰和證書的數字簽名，數字簽名經過CA公鑰解密得到證書信息摘要忿危。
2.然后證書簽名的方法計算一下當前證書的信息摘要达箍，與收到的信息摘要作對比，如果一樣铺厨，表示證書一定是服務器下發(fā)的缎玫，沒有被中間人篡改過。因為中間人雖然有權威機構的公鑰解滓，能夠解析證書內容并篡改赃磨，但是篡改完成之后中間人需要將證書重新加密，但是中間人沒有權威機構的私鑰洼裤，無法加密邻辉，強行加密只會導致客戶端無法解密，如果中間人強行亂修改證書腮鞍，就會導致證書內容和證書簽名不匹配值骇。
那第三方攻擊者能否讓自己的證書顯示出來的信息也是服務端呢？
（偽裝服務端一樣的配置）顯然這個是不行的移国，因為當第三方攻擊者去CA那邊尋求認證的時候CA會要求其提供例如域名的whois信息吱瘩、域名管理郵箱等證明你是服務端域名的擁有者，而第三方攻擊者是無法提供這些信息所以他就是無法騙CA他擁有屬于服務端的域名迹缀。
六使碾、運用與總結
安全性考慮：
1.HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊祝懂、拒絕服務攻擊票摇、服務器劫持等方面幾乎起不到什么作用
2.SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下砚蓬，中間人攻擊一樣可行
中間人攻擊（MITM攻擊）是指矢门，黑客攔截并篡改網絡中的通信數據。又分為被動MITM和主動MITM忠怖，被動MITM只竊取通信數據而不修改业崖，而主動MITM不但能竊取數據，還會篡改通信數據宪郊。最常見的中間人攻擊常常發(fā)生在公共wifi或者公共路由上峡扩。
成本考慮：
1.SSL證書需要購買申請，功能越強大的證書費用越高
2.SSL證書通常需要綁定IP障本，不能在同一IP上綁定多個域名教届，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩驾霜，而且要求瀏覽器案训、操作系統(tǒng)支持，Windows XP就不支持這個擴展粪糙，考慮到XP的裝機量强霎，這個特性幾乎沒用）。
3.根據ACM CoNEXT數據顯示蓉冈，使用HTTPS協(xié)議會使頁面的加載時間延長近50%城舞，增加10%到20%的耗電。
4.HTTPS連接緩存不如HTTP高效寞酿，流量成本高家夺。
5.HTTPS連接服務器端資源占用高很多，支持訪客多的網站需要投入更大的成本伐弹。
6.HTTPS協(xié)議握手階段比較費時拉馋，對網站的響應速度有影響，影響用戶體驗惨好。比較好的方式是采用分而治之煌茴，類似12306網站的主頁使用HTTP協(xié)議，有關于用戶信息等方面使用HTTPS日川。
————————————————
版權聲明：本文為CSDN博主「會飛的狗~」的原創(chuàng)文章蔓腐，遵循 CC 4.0 BY-SA 版權協(xié)議，轉載請附上原文出處鏈接及本聲明逗鸣。
原文鏈接：https://blog.csdn.net/xiaoming100001/article/details/81109617
