前言：由于微信小程序要求必須通過 HTTPS 完成與服務端通信，若開發(fā)者選擇自行搭建 HTTPS 服務，那需要自行 SSL 證書申請、部署糕再，完成 https 服務搭建。故借此學習了一下HTTPS協(xié)議玉转。
什么是HTTPS突想？
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），即安全套接字層超文本傳輸協(xié)議究抓，是以安全為目標的HTTP通道猾担，簡單講是HTTP的安全版。即HTTP下加入SSL層刺下，HTTPS的安全基礎是SSL绑嘹，因此加密的詳細內(nèi)容就需要SSL。 它是一個URI scheme（抽象標識符體系）橘茉，句法類同http:體系工腋。用于安全的HTTP數(shù)據(jù)傳輸姨丈。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）擅腰。這個系統(tǒng)的最初研發(fā)由網(wǎng)景公司(Netscape)進行蟋恬，并內(nèi)置于其瀏覽器Netscape Navigator中，提供了身份驗證與加密通訊方法√韫模現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊筋现，例如交易支付方面。
HTTPS和HTTP的區(qū)別
超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務器之間傳遞信息箱歧。HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密一膨，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務器之間的傳輸報文呀邢，就可以直接讀懂其中的信息，因此HTTP協(xié)議不適合傳輸一些敏感信息豹绪，比如信用卡號价淌、密碼等。
為了解決HTTP協(xié)議的這一缺陷瞒津，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS蝉衣。為了數(shù)據(jù)傳輸?shù)陌踩琀TTPS在HTTP的基礎上加入了SSL協(xié)議巷蚪，SSL依靠證書來驗證服務器的身份病毡，并為瀏覽器和服務器之間的通信加密。
HTTPS和HTTP的區(qū)別主要為以下四點：
一屁柏、https協(xié)議需要到ca申請證書啦膜，一般免費證書很少，需要交費淌喻。
二僧家、http是超文本傳輸協(xié)議，信息是明文傳輸裸删，https 則是具有安全性的ssl加密傳輸協(xié)議八拱。
三、http和https使用的是完全不同的連接方式涯塔，用的端口也不一樣肌稻，前者是80，后者是443伤塌。
四灯萍、http的連接很簡單，是無狀態(tài)的每聪；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸旦棉、身份認證的網(wǎng)絡協(xié)議齿风，比http協(xié)議安全。
什么是SSL/TLS绑洛？
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全(Transport Layer Security救斑，TLS)是為網(wǎng)絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層對網(wǎng)絡連接進行加密真屯。
SSL (Secure Socket Layer)為Netscape所研發(fā)脸候，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術绑蔫，可確保數(shù)據(jù)在網(wǎng)絡上之傳輸過程中不會被截取及竊聽运沦。目前一般通用之規(guī)格為40 bit之安全標準，美國則已推出128 bit之更高安全標準配深，但限制出境携添。只要3.0版本以上之I.E.或Netscape瀏覽器即可支持SSL。
當前版本為3.0篓叶。它已被廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數(shù)據(jù)傳輸烈掠。
SSL協(xié)議位于TCP/IP協(xié)議與各種應用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持缸托。SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上左敌，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮俐镐、加密等基本功能的支持矫限。SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前京革，通訊雙方進行身份認證奇唤、協(xié)商加密算法、交換加密密鑰等匹摇。
一咬扇、作用
不使用SSL/TLS的HTTP通信，就是不加密的通信廊勃。所有信息明文傳播懈贺，帶來了三大風險。
（1） 竊聽風險（eavesdropping）：第三方可以獲知通信內(nèi)容坡垫。
（2） 篡改風險（tampering）：第三方可以修改通信內(nèi)容梭灿。
（3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協(xié)議是為了解決這三大風險而設計的冰悠，希望達到：
（1） 所有信息都是加密傳播堡妒，第三方無法竊聽。
（2） 具有校驗機制溉卓，一旦被篡改皮迟，通信雙方會立刻發(fā)現(xiàn)搬泥。
（3） 配備身份證書，防止身份被冒充伏尼。
二忿檩、歷史
1994年，NetScape公司設計了SSL協(xié)議（Secure Sockets Layer）的1.0版爆阶，但是未發(fā)布燥透。
1995年，NetScape公司發(fā)布SSL 2.0版辨图，很快發(fā)現(xiàn)有嚴重漏洞班套。
1996年，SSL 3.0版問世故河，得到大規(guī)模應用孽尽。
1999年，互聯(lián)網(wǎng)標準化組織ISOC接替NetScape公司忧勿，發(fā)布了SSL的升級版[TLS](http://en.wikipedia.org/wiki/Secure_Sockets_Layer) 1.0版。
2006年和2008年瞻讽，TLS進行了兩次升級鸳吸，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的[修訂版](http://tools.ietf.org/html/rfc6176)速勇。
目前晌砾，應用最廣泛的是TLS 1.0，接下來是SSL 3.0烦磁。但是养匈，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持。
TLS 1.0通常被標示為SSL 3.1都伪，TLS 1.1為SSL 3.2呕乎，TLS 1.2為SSL 3.3。
三陨晶、基本的運行過程
（1） 客戶端向服務器端索要并驗證公鑰猬仁。
（2） 雙方協(xié)商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進行加密通信先誉。
上面過程的前兩步湿刽，又稱為"握手階段"（handshake）。
** 第一步 客戶端發(fā)出請求（ClientHello）**
（1） 支持的協(xié)議版本褐耳，比如TLS 1.0版诈闺。
（2） 一個客戶端生成的隨機數(shù)，稍后用于生成"對話密鑰"铃芦。
（3） 支持的加密方法雅镊，比如RSA公鑰加密襟雷。
（4） 支持的壓縮方法。
** 第二步 服務器回應（SeverHello）**
（1） 確認使用的加密通信協(xié)議版本漓穿，比如TLS 1.0版本嗤军。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信晃危。
（2） 一個服務器生成的隨機數(shù)叙赚，稍后用于生成"對話密鑰"。
（3） 確認使用的加密方法僚饭，比如RSA公鑰加密震叮。
（4） 服務器證書。
** 第三步 客戶端回應**
（1） 一個隨機數(shù)鳍鸵。該隨機數(shù)用服務器公鑰加密苇瓣，防止被竊聽。
（2） 編碼改變通知偿乖，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送击罪。
（3） 客戶端握手結束通知，表示客戶端的握手階段已經(jīng)結束贪薪。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值媳禁，用來供服務器校驗。
** 第四步 服務器的最后回應**
（1）編碼改變通知画切，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送竣稽。
（2）服務器握手結束通知，表示服務器的握手階段已經(jīng)結束霍弹。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值毫别，用來供客戶端校驗。
至此典格，整個握手階段全部結束岛宦。接下來，客戶端與服務器進入加密通信钝计，就完全是使用普通的HTTP協(xié)議恋博，只不過用"會話密鑰"加密內(nèi)容。
HTTPS的普及之路
事實上 HTTPS 1995 年就誕生了私恬，是一個非常古老债沮、成熟的協(xié)議。同時又能很好地防止內(nèi)容劫持本鸣，保護用戶隱私疫衩。但是為什么一直到今天，還有大部分的網(wǎng)站不支持 HTTPS荣德，只使用 HTTP 呢?
影響 HTTPS 普及的主要原因可以概括為兩個字：「慢」和「貴」闷煤。
（1）慢
在未經(jīng)任何優(yōu)化的情況下童芹，HTTPS 會嚴重降低用戶的訪問速度。主要因素包括:
網(wǎng)絡耗時鲤拿。由于協(xié)議的規(guī)定假褪，必須要進行的網(wǎng)絡傳輸。比如 SSL 完全握手近顷，302 跳轉等生音。最壞情況下可能要增加 7 個 RTT。
計算耗時窒升。無論是客戶端還是服務端缀遍，都需要進行對稱加解密，協(xié)議解析饱须，私鑰計算域醇，證書校驗等計算，增加大量的計算時間蓉媳。
（2）貴
HTTPS 的貴譬挚，主要體現(xiàn)在如下三方面：
1、服務器成本酪呻。HTTPS 的私鑰計算會導致服務端性能的急劇下降殴瘦，甚至不到 HTTP 協(xié)議的十分之一，也就是說号杠，如果 HTTP 的性能是 10000cps，HTTPS 的性能可能只有幾百 cps丰歌，會增加數(shù)倍甚至數(shù)十倍的服務器成本姨蟋。
2、證書成本立帖。根據(jù)證書個數(shù)及證書類型眼溶，一年可能需要花費幾百到幾百萬不等的證書成本。
3晓勇、開發(fā)和運維成本堂飞。HTTPS 協(xié)議比較復雜，openssl 的開源實現(xiàn)也經(jīng)常發(fā)生安全BUG绑咱， 包括協(xié)議的配置绰筛，證書的更新，過期監(jiān)控描融，客戶端的兼容等一系列問題都需要具備專業(yè)背景的技術人員跟進處理铝噩。
（完）
其實不僅僅是小程序，蘋果 iOS 平臺窿克，Google Android 在 2017 也逐步強制要求開發(fā)者使用 HTTPS 接入骏庸。在下一章毛甲，我們將學習如何搭建HTTPS服務，敬請期待具被！
參考文獻 ：
