- HTTPS原理
- HTTPS域名配置與證書申請
- nodejs配置證書啟動HTTPS服務
- HTTPS服務可能需要解決的問題與潛在的安全問題
一、HTTPS原理
HTTPS有被稱為HTTP安全協議，在HTTP協議的基礎上增加一層安全層，也就是在HTTP應用層與TCP傳輸層之間增加一層加密與認證流程，確保通訊的安全。這一層協議也通常被稱為SSL（Secure Sockets Layer安全套接層），或者也可以說是其后繼者TLS（Transport Layer Security傳輸層安全），這兩者總體上的加密邏輯差一步，具體的安全加密細節不是這篇博客討論的主要內容。所以后面如果出現SSL或者TLS的話將他統一視作安全層即可。
1.1HTTPS的加密過程
從上面這個HTTPS加密流程中可以看到一些關鍵字：證書、證書公鑰、證書私鑰、（會話）密鑰、加密、解密。這些關鍵字都指向一個問題——加密策略。這些關鍵字反映出了一系列的加密技術：對稱加密、非對稱加密、混合加密、會話密鑰、數字證書、數字簽名。下面就先來一個個了解它們，然后再詳細的解析整個加密流程。
1.1.1密碼：使用加密算法實現加密編碼，是偷窺者無法識別加密后的數據內容。
密碼學是一套編碼方案，一種特殊的報文編碼方式和一種稍后使用的相應解碼方式的結合體。加密之前的原始報文叫做明文（plaintext或cleartext）,使用了密碼之后的報文被稱為密文。
在數千年前尤利烏斯·凱撒就是用三字符循環移位密碼，報文中的每個字符都由字母表中的三個位置之后的字符來取代，用現代字母表中的“A"就應該由“D"取代，”B"就應該由“D”取代，以此類推，也就是rot3（三位循環移位）。假設報文內容“meet me at the pier at midnight”，編碼為密文就應該是“phhw ph dw wkh slhu dw plgqljkw”。
這是幾千年前的密文編碼技術，全部依靠手動編碼解碼，在現代計算機算法中非常容易實現，但也就非常容易被破解，后來再簡單的循環移位基礎上增加了旋轉、替代字符、改變字符順序、將報文切片，使代碼破解難度更加困難，但是隨着技術的發展很多編碼和解碼算法都相對透明了，這類密碼技術還是非常容易被破解。再后來在這些技術的基礎增加了密鑰值。
密鑰值就是指在對數據進行加密編碼時，加密和解密都需要使用這個密碼作為算法的參數，數據在使用密鑰計算加密后，同樣需要使用一個密鑰作為參數解密。在這一基礎上發展出了對稱密鑰加密和非對密鑰稱加密。
1.1.2對稱密鑰加密：編碼器與解碼器都是用同一個密鑰進行加密和解密，流行的對稱密鑰加密算法包括：DES、Triple-DES、RC2、RC4。
對稱密鑰加密對於密鑰的機密性就顯得非常重要了，如果發生密鑰泄密就是災難性的事件，除了人為或者技術漏洞導致的泄密以外，對稱密鑰加密技術在現代計算機技術高度發達的今天來說，還將面對暴力的枚舉攻擊。
枚舉攻擊就是使用計算機將可能的密鑰一個個代入解碼器，直到計算出真正的密鑰值。48位的密鑰只有256個可能的密鑰值，這對於現代計算機來說枚舉攻擊簡直輕而易舉，40位密鑰可以有240（約一萬億個密鑰）個可能，如果要使用枚舉攻擊破解這個位數的密鑰就要付出一些代價了，也就是說對稱密鑰加密技術密鑰位數越大相對越安全，而這也僅僅是相對而言，這還需要考慮加密數據的標的物價值。
1.1.3非對稱密鑰加密：編碼器與解碼器使用不同的密鑰進行加密和解密，非對稱加密又稱為公開密鑰加密技術。非對稱密鑰加密在對數據加密和解密時應用了兩個密鑰，也就常說的公鑰和私鑰，公鑰是對外公開的，提供給會話方加密要發送給自己的數據，當接收到公鑰加密的數據后使用私鑰解密。在完成一個雙向通訊的過程中，需要兩個非對稱密鑰協同完成。比較經典的非對稱密鑰加密技術有：RSA。
注意：一個非對稱密鑰包含一個公鑰和一個私鑰。
向對於對稱密鑰加密，非對稱密鑰加密解決了密鑰交換問題，在對稱密鑰加密中存在一個問題就是雙方如何溝通密鑰問題，誰來保證密鑰的私密性不被破壞這些都是巨大的挑戰，而采用非對稱加密卻完美的解決了這個問題。但是非對稱加密的計算量非常大，對於系統性能是巨大的挑戰，我們知道在web應用中網絡資源實非常珍貴的，如果一個連接響應時間過長可能出現中斷連接的可能，即便我們可以通過修改連接最大時間值也不是明智的選着。因為這樣同樣伴隨着巨大的系統資源開銷，所以HTTPS並沒有完全使用對稱加密，而只是在SSL握手過程中采用非對稱加密技術，而在實際的會話時使用的是對稱加密技術，相關內容在后面的內容中詳細解析。
1.1.4數字簽名：數字簽名在HTTPS中准確來說應該是報文數字簽名，單純的數字簽名就是通過算法基於數據本身獲取數據的一部分作為數據摘要，可以作為數據的唯一性的身份證明標識。
數字簽名技術是基於數據生成一個唯一值，當數據發生改變時，這個值就必然發生改變，而且在HTTPS中簽名函數還是用了私鑰作為簽名函數的參數，所以如果要偽造簽名就必須擁有私鑰才能完成。接收方使用公鑰和簽名反函數基於數據同樣可以計算出這個簽名，如果計算出的簽名一致就可以確定數據沒有發生改變，並且也可以確定對方的身份是正確的。
第一步：A使用私鑰A基於明文報文計算出報文摘要（簽名）。
第二步：B收到並解析出報文明文和A的簽名。
第三步：B使用簽名反函數和公鑰A基於明文報文計算報文摘要，並與簽名對比，如果摘要相同則說明報文內容沒有發生改變，並且數據是來源A。反之則不是安全數據，彈出警告並中斷會話。
數字簽名起到了對報文安全的驗證效果，確保數據發送方的身份和數據是否安全。
1.1.5數字證書：數字證書中包含一組信息，所有這些信息都由一個官方的“證書頒發機構”以數字簽名的方式簽發。基本的數字證書通常包含以下內容。
對象的名稱：個人用戶、服務器、組織。
過期時間：證書的有效期。
證書發布者：由誰為證書擔保。
證書數字簽名：來自頒發者對證書的數字簽名。
除了基本信息和典型格式中的內容以外，一般還會包括發布者的唯一ID和對象的唯一ID。
數字證書是用來證明連接的是安全可靠的主機，通過證書內容驗證主機的安全性是否是可信任的主機，除了驗證主機的可靠性還需要驗證證書是否可靠，數字證書從內容上來說並不是多么復雜的內容，一般普通主機都可生成對應格式的內容，但從web事務來說瀏覽器如何確定證書說明的主機就是可靠的呢？所以這就需要第三方權威的證書機構來頒發，瀏覽器會通過向第三方證書驗證來確定證書的真偽，但這類驗證也只是定期更新各個權威機構的證書序列號，通過驗證證書序列號是否有效的普通驗證手短。
除了確定證書序列號是有效的以外，瀏覽器還會根據證書頒發機構的公開密鑰采用證書簽名反函數計算出證書摘要（證書的數字簽名），與證書中的數字簽名對比來驗證證書的真偽。（這與前面的報文數字簽名技術原理一致，權威的數字證書頒發機構回對瀏覽器公開機構的公開密鑰）
1.1.6HTTPS的安全傳輸握手過程（SSL）:
前面已經對HTTPS的加密技術進行了逐個的解析：對稱加密、非對稱加密、數字簽名、數字證書，接下來再來了解以下HTTPS的安全傳輸握手過程，在了解SSL之前有必要先了解整個HTTPS會話流程。
HTTPS會話流程解析：
1、客戶端首先打開一條到Web服務器端口443（HTTPS默認端口）的連接，建立TCP連接。
2、建立連接后，客戶端與服務器就初識化SSL層，對加密參數進行溝通，並交換密鑰。（這個步驟比較復雜，其中包括證書驗證、協商加密算法、生成使用對稱加密技術的報文密鑰、采用非對稱加密交換報文密鑰、報文數字簽名，后面回對SSL握手進行詳細的解析）
3、SSL握手完成以后，客戶端將請求報文發送給安全層（SSL）。
4、SSL層使用報文密鑰報文加密后，交由TCP連接發送給服務器。
5、服務器收到請求后，使用報文密鑰解密請求報文，解析請求報文。
6、服務器取出請求對應的數據資源，交由SSL層使用報文密鑰加密響應報文，通過TCP連接發送給客戶端，在加密之前還會生成一個報文簽名然后交給SSL統一打包。
7、客戶端收到響應報文后，使用報文密鑰解密響應報文，拿到報文后使用數字簽名反函數並以服務器公鑰作為參數計算出報文的數字簽名，然后與服務器發送過來的數字簽名進行對比驗證，驗證通過后將數據交由程序處理，如果驗證不通過彈出警告並進入HTTPS會話關閉流程。
8、SSL關閉通知、TCP關閉連接。
1.1.7SSL握手詳解：
SSL握手是HTTPS協議的核心部分，它負責驗證網絡連接的雙方身份，並在客戶端生成報文密鑰再用服務的公鑰加密傳送給服務，在這個過程中采用的是非對稱加密。雖然SSL支持雙向認證，但一般web項目只對服務器進行認證，並不使用客戶端證書對用戶進行認證，一些安全性要求較高的系統會要求使用客戶端證書認證（網銀U盾）。
SSL握手流程解析：
1.當客戶端發起HTTPS請求時，向服務器發送一個隨機值和客戶端支持的加密算法集。
2.服務器收到請求后，挑選雙方都持支的加密算法，並和服務器證書以及服務器端生成的隨機值一起響應給客戶端。
3.客戶端收到響應后，對證書進行驗證：證書日期檢查、證書頒發者可信度、簽名檢測（簽名反函數）、站點身份檢查（檢查證書的內容與實際請求的站點是否一致）。如果發現任意環節出現數據不匹配的情況，就會報錯誤提示並結束會話。如果一切檢測通過，就使用本地和服務器生成的隨機值基於服務器確認的雙方都支持的加密算法生成報文密鑰。然后使用從服務器證書中解析出來的服務器公鑰加密報文密鑰和HTTPS的請求信息發送給服務器，這個環節使用的是非對稱加密。
4.服務器收到加密報文后使用服務器私鑰解密報文，解密報文取出報文密鑰和請求內容，然后把客戶端請求的數據通過報文密鑰加密，並且同時產生一個報文數字簽名發送回客戶端。（響應請求資源環節使用對稱加密）
5.客戶端收到資源響應報文后使用報文密鑰解密，使用簽名反函數對報文簽名進行檢測，檢測通過后才會解析報文攜帶的資源數據並刷新頁面，如果檢測不通過同樣會報錯誤提示並結束會話。
二、HTTPS域名配置與證書申請
證書提供商比較多，比如全球知名安全證書提供商賽門鐵克（symantec），其他還有阿里雲、騰訊雲、西部數據、亞馬遜、沃通。至於怎么選擇不是這里要討論的，如果只是做測試的話建議找一個免費的就好，接下來看看如何配置證書。
首先准備一個域名，配置域名解析我就不在這里講了。接下來我用騰訊雲的SSL免費證書配置為例：
第一步：申請證書，域名和郵箱必填，然后選擇下一步。
第二步：域名身份認證，選擇手動DNS驗證，然后確認申請。
第三步：確認申請后，會進入證書基本信息頁面，將證書信息中的DNS域名解析配置到域名解析中。
第四步：手動到域名控制台配置證書解析，將證書的DNS驗證信息添加到對應的域名解析中，就可以了。
第五步：然后回到證書信息詳情頁查詢解析是否成功。
第六步：如果證書驗證解析成功了，就等着證書頒發機構給你頒發證書了，這可能需要等一些時間，有些朋友說有的機構需要等一個星期，但我只用了不到一分鍾就可以了。
第七步：下載證書，別問我下載干嘛，你說干嘛，當然是用來搭建HTTPS服務了。
下載證書后，后面的內容就是下一節的了，配置HTTPS服務。
三、nodejs配置證書啟動HTTPS服務
下載的證書包含多種服務的配置：Apache、IIS、Nginx、Tomcat，各自根據自己的服務搭建，這里因為我是用的時win環境，也懶得安裝其他服務了，就直接使用IIS服務的配置。
這里我先將證書所有內容解壓到了SSL路徑下，下面最簡單的配置代碼index.js，然后使用node啟動index.js
1 //index.js 2 let https = require("https"); 3 let fs = require("fs"); 4 let options = { 5 pfx: fs.readFileSync("./SSL/IIS/xxxx.com.pfx"), 6 passphrase: 這里將ISS下的keystorePass.tex中的密鑰復制到這里，注意時字符串類型 7 } 8 https.createServer(options,function (request,response) { 9 response.writeHead(200); 10 response.write("<html><meta charset=\"UTF-8\"><title>HTTPS安全服務測試</title><head><body></head><h1>HTTPS安全服務已啟動！</h1></body></html>") 11 response.end(); 12 }).listen(12306);
當服務器正常啟動后，在瀏覽器使用訪問：https://你的域名:12306
當你看到地址欄前面的鎖時，就表示你請求的網站是HTTPS安全協議，其實配置起來與http沒啥區別，就是在createServer方法中多了一個options的參數，這個參數可以從代碼中看到就是用來解析SSL證書的，其他的HTTP怎么來，HTTPS還是一樣的操作。關於HTTPS的其他服務的配置在網上也有比較多的教程，我暫時就不一個個的演示了，最近計划自己弄一個博客網站，如果到時候有時間的話，可能會在我自己的博客網站中補充。
四、HTTPS服務可能需要解決的問題與潛在的安全問題
1.在使用HTTPS服務的時候，在一些大型項目中可能出現多個服務器處理請求，而一個站點又只有一個證書，這種情況可以在開始處理安全事務之前重定向到一個主機上。
2.HTTPS絕對安全嗎？答案是不可能保證絕對安全！但相對HTTP請求來說要安全很多，那HTTPS不安全的可能因素有哪些呢？
- 中間人攻擊：從前面的https的請求解析中可以了解到https的請求本質上是由http層傳送給SSL層，在這之間本質上還是明文。而這個環節最容易被攻擊的就是SSL握手的第一個環節，當請求發送出去后還沒到達SSL層的時候就被攔截，這時候攻擊者如果將請求主機修改成了另一個也具有SSL證書的服務器地址，這時候攻擊者就可以偽裝成你實際請求的站點，實現這類攻擊的方式可以通過劫持DNS服務器來實現。
- 枚舉攻擊：除了中間人攻擊對於HTTPS的加密算法進行暴力破解枚舉攻擊依然是可以實現的，只是就目前來說這種攻擊是非常不划算的方式，假設攻擊者要投入10萬元成功攻擊破解獲取數據缺只價值1萬元，這種攻擊顯然即便可行也不會有人采用，但如果數據標的物價值遠遠超過10萬呢？所以說加密其本質也是一種博弈。
3.HTTPS的性能相對HTTP來說要差一些，據卡內基梅隆大學的一份研究量化了“S”的代價，HTTPS加載時間增加了50%，增加10%~20%的耗電，還會影響緩存以及現有的安全措施。
4.增加開發成本，假設一個頁面的數據來源多個網站或者項目呢？這時候需要解決的問題就會比較復雜，這個問題好像跟第一個問題有點類似，可以肯定這會帶來開發成本的提高。
5.搜索引擎對於HTTPS的協議抓取不夠友好，會影響到站點的搜索排名。