1 TLS協(xié)議簡介
1.1 簡介
TSL是傳輸層安全協(xié)議(Transport Secure Protocol）的簡稱，它的前身是SSL(Secure Sockets Layer)。TLS的設(shè)計目標是為互聯(lián)網(wǎng)通信提供安全保證，防止數(shù)據(jù)被竊聽，篡改。TLS協(xié)議由記錄層(TLS Record Layer)和握手層(TLS Handshake Layer)組成，記錄層處于協(xié)議的最低層，為TLS協(xié)議提供安全可靠的連接。TLS在協(xié)議棧中處于HTTP和TCP協(xié)議之間，但是TLS協(xié)議是獨立于應(yīng)用層協(xié)議的，也就是說高層的應(yīng)用層協(xié)議，如HTTP，F(xiàn)TP等都可以創(chuàng)建在TLS之上，TLS的下層可以是任何可靠傳輸層協(xié)議，如TCP，SPX等。
1.2 TLS的版本演進
TLS目前已發(fā)布的最新版本是TLS1.2，它在RFC5246中定義，其前身SSL1.0，SSL2.0和SSL3.0。SSL由于安全漏洞，已逐漸在被淘汰；TLS1.0和SSL3.0差異很小，幾乎等同，漸漸也不再使用，所以現(xiàn)在的話，只要注意TLS1.1以上的版本。
1.3 TLS握手過程
TLS分為記錄層協(xié)議和握手層協(xié)議：
記錄層協(xié)議(TLS Record Protocol)：
記錄層協(xié)議負責(zé)將要發(fā)出的消息進行分片，壓縮，打上消息認證碼(MAC)并最終交到傳輸層；或?qū)⒔邮盏降臄?shù)據(jù)進行解壓，解密，數(shù)據(jù)校驗，重新 組裝后傳到上一層。
握手層協(xié)議(TLS Handshake Protocol)：
握手層協(xié)議處于記錄層協(xié)議之上，握手層協(xié)議的作用是在真正的應(yīng)用數(shù)據(jù)傳輸之前，使客戶端和服務(wù)器互相進行身份認證，協(xié)商加密算法以及生成加密密鑰。握手層用于協(xié)商出記錄層的參數(shù)。這些參數(shù)將會被記錄層用于雙方的身份認證，實例化協(xié)商的安全參數(shù)，錯誤報告。
TLS在協(xié)議棧中的位置：
TLS的協(xié)議棧位置TLS的握手過程：
1.客戶端發(fā)送ClientHello消息，包含可選密碼組件，一個客戶端生成的隨機數(shù)等，服務(wù)端接收后回一個ServerHello消息給客戶端，確定密碼方案，并生成一個服務(wù)器隨機數(shù)，發(fā)給客戶端。
這一步的數(shù)據(jù)傳輸在TCP上進行，數(shù)據(jù)都是公開的，中間人攻擊者可以很輕松的得到這些數(shù)據(jù)。
2.服務(wù)器發(fā)送證書，服務(wù)器的身份確認成功后；服務(wù)器可能會請求一個客戶端證書，要求客戶端進行身份認證，客戶端給服務(wù)器發(fā)出證書，驗明身份。這一步不是必須的。
3.客戶端向服務(wù)器發(fā)出摘要認證，確認接收的消息的完整性，保證沒有被第三方篡改。
4.雙方交換必需的加密參數(shù)。其中包括一個預(yù)主密鑰，客戶端會用服務(wù)器證書中的公鑰將這個密鑰加密傳給服務(wù)器，服務(wù)器使用私鑰進行解密。
5.客戶端生成一個預(yù)主密鑰，并使用服務(wù)器證書中的公鑰加密，服務(wù)器解密后生成一個主密鑰。雙方使用這個主密鑰(master secret)對應(yīng)用層數(shù)據(jù)進行對稱加密(如AES256)。 主密鑰是客戶端和服務(wù)器共享的。
6.最后，把這些準備好的的安全參數(shù)交給記錄層協(xié)議。
下圖轉(zhuǎn)自維基百科TLS詞條 https://zh.wikipedia.org/wiki/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E5%8D%94%E8%AD%B0：
SSL_handshake_with_two_way_authentication_with_certificates.png會話恢復(fù)過程：
客戶端服務(wù)器出于性能的考慮，可能會恢復(fù)前面的會話，或復(fù)制一個當(dāng)前存在的會話，而不是重新協(xié)商密碼參數(shù)，建立新的會話(4.2部分使用tcpdump跟蹤發(fā)現(xiàn)，這個過程確實是耗時占比很大)。
1.客戶端發(fā)出一個ClientHello消息，這個消息包含要恢復(fù)的會話的Session ID。
2.服務(wù)接到這個SessionID后，檢查它的緩存是否存在該會話ID。如果找到了，服務(wù)器將使用該會話狀態(tài)重建連接，并發(fā)一個ServerHello給客戶端，其中包含一個和ClientHello消息一模一樣的SessionID。
3.此時，協(xié)議規(guī)定，必須要雙方發(fā)出ChangeCipherSpec消息，并接著發(fā)出Finished消息確認握手完成。然后客戶端服務(wù)器就可以傳輸應(yīng)用層數(shù)據(jù)了。
4.如果服務(wù)器沒有在緩存中找到Session ID，那么新的SessionID將會建立，然后又會執(zhí)行一次完全握手。
--------------------------------------------------------------------------------
2 使用nginx搭建https服務(wù)器
2.1 環(huán)境準備
先搭建nginx，nginx的搭建在官網(wǎng)中可以找到 http://nginx.org/en/docs/install.html
注意如果是用源碼編譯，有的較老版本構(gòu)建編譯時需要帶上參數(shù)--with-http_ssl_module，最新的nginx版本是默認有這個編譯參數(shù)的。
配置：
ssl_certificate : 存放服務(wù)器證書的地址，主要用于數(shù)字證書的身份認證。所有連到服務(wù)器的客戶端都能拿到這個證書；
ssl_certificate_key : 是私鑰，只能被服務(wù)器知道。
ssl_protocols， ssl_ciphers選項是可選的。
2.2 詳細操作步驟
下面嘗試在本地搭建一個簡單的https服務(wù)器，在443端口監(jiān)聽。
大致步驟如下：
1.搭建一個nginx服務(wù)器；
2.使用openssl生成服務(wù)器私鑰，客戶端私鑰，服務(wù)器公鑰，客戶端公鑰；
3.生成CA根證書，為服務(wù)器證書和客戶端證書（可選）提供簽名服務(wù)；
4.生成服務(wù)器證書和客戶端證書，并請求CA的簽名；
5.在操作系統(tǒng)上信任我們偽造的服務(wù)器證書，這里沒有為客戶端生成證書；
6.隨便寫一個web服務(wù)，提供一個url返回一段靜態(tài)報文，讓nginx為它做一下代理，然后啟動這個web服務(wù)器；
7.測試。
以下是這些步驟的操作命令：
證書和私鑰生成完畢后，開始配置nginx（http部分從略）；
配置完后，保存，在nginx根目錄下運行命令:
$ ./sbin/nginx -t -c conf/https_server.conf
nginx會測試一下配置文件 conf/https_server.conf
如果輸出下面的東西，表示配置沒什么格式問題了：
啟動nginx:
$ ./sbin/nginx -c conf/https_server.conf
這里我們搭建一個http服務(wù)器，在端口8887上監(jiān)聽，使用nginx代理，在瀏覽器中訪問:
https://localhost/hello
返回:
2.3 信任證書：
瀏覽器中輸入
https://localhost:443
因為我們的根證書是自己簽發(fā)的，簽發(fā)機構(gòu)是偽造的，不在瀏覽器的信任列表中。對于這種情況，不同的瀏覽器對此會有不同的表現(xiàn)，但主流的瀏覽器都會發(fā)出警告。下面提供了一種辦法，使瀏覽器信任證書。注意，這里只是為了測試，正常上網(wǎng)不要忽略瀏覽器的警告，輕易地信任不明來源的證書。
下面是在Mac下的Google Chrome中信任證書的操作步驟：
. 當(dāng)瀏覽器提示連接不安全時，在瀏覽器的抓包工具中點到如下的界面：
圖4. 點按鈕：View Certificate
. 拖動證書的icon，拉到本地桌面上并雙擊它：
圖5：訪問https://www.baidu.com得到的服務(wù)器證書，僅舉例雙擊它打開系統(tǒng)的鑰匙串，將桌面證書拖拽到系統(tǒng)鑰匙串中，
雙擊打開，選擇『始終信任』
圖6
圖7
注：截圖的證書為測試時隨意生成的根證書；所有證書信任的辦法類似。
重啟瀏覽器后，再訪問https://localhost/hello ，會看到這樣的結(jié)果:
圖8
2.4 測試加密效果
現(xiàn)在，我們嘗試用抓包工具模擬中間人截取報文，看看能不能截取到報文：
在mac上我們使用charles進行抓包，結(jié)果如下，報文已經(jīng)被加密，看到的內(nèi)容都是亂碼：
圖9
嘗試用Charles進行一次中間人攻擊：偽造證書，在Charles上可以安全一個代理證書，具體操作參考這里：http://www.jianshu.com/p/7a88617ce80b，然后再訪問https://localhost/hello
這時瀏覽器會又提示我們連接不安全，這是因為TLS握手感知到了客戶端的證書來源不明，假如我們點擊高級，繼續(xù)訪問，忽略這個警告，那么我們會在抓包工具上看到這樣的畫面：
圖10
報文的內(nèi)容成功被Charles竊聽了，所以，再次驗證了一點：如果正常上網(wǎng)瀏覽網(wǎng)頁，操作電子銀行等敏感信息時，不要隨便忽略瀏覽器的安全警告。
由于大多數(shù)人安全意識薄弱，很習(xí)慣地點繼續(xù)訪問不安全連接 ，所以就有了HSTS。
2.5 HSTS是什么
HSTS(HTTP Strict Transport Security)，這是一個由IEEE發(fā)布的網(wǎng)絡(luò)安全策略機制，如果服務(wù)器增加了這種策略，那么就意味著要求客戶端必須使用https協(xié)議和服務(wù)器進行對話。
主流的瀏覽器都實現(xiàn)了HSTS策略。當(dāng)TLS握手出現(xiàn)問題時，瀏覽器不會再訪問服務(wù)器。
百度的防火墻代理就實現(xiàn)了這個策略。訪問https://www.baidu.com ，在瀏覽器截取到的服務(wù)器響應(yīng)頭中有一個Strict-Transport-Security字段 max-age=172800 。max-age是指HSTS的失效時間，單位是秒。
圖11
由于服務(wù)器響應(yīng)頭增加了這個字段，瀏覽器就會履行一些HSTS的職責(zé)。假如我們采取抓包工具偽造一個未知證書，再去訪問域名，就會受到警告，嘗試讓瀏覽器忽略不安全的警告繼續(xù)訪問會被禁止，如下圖：
圖12
然而HSTS也不是絕對安全的。一方面原因在于Strict-Transport-Security的max-age會過期，瀏覽器是否強制HSTS策略取決于當(dāng)前系統(tǒng)時間，它可能偽造；另一方面是因為首次訪問網(wǎng)址并不受HSTS保護。可見技術(shù)對安全的防護永遠是有限的，還需要用戶有足夠的安全意識進行自我保護。
3 實現(xiàn)https抓包
了解了https的原理之后，知道TLS的握手關(guān)鍵在身份認證這一步。HTTPS的數(shù)據(jù)傳輸可以類比成交談的雙方各自亮出身份證，然后用約定的暗號進行交流，這樣即時旁邊有人竊聽，也無法破解經(jīng)過加密的信息。
測試時，我們通常會有抓取https包的需求。如果以為https已被加密，我們沒辦法抓到明文包，那這是不對的。抓包的原理通常是在通信雙方插一個中間代理，對原有的客戶端和服務(wù)器的請求進行來回轉(zhuǎn)發(fā)。如果要抓取https包，顯然，構(gòu)造的代理必須有完成TLS握手的能力，所以代理工具一般需要支持ssl。有了TLS的握手能力，我們再設(shè)法使通信雙方相信代理的身份，就能實現(xiàn)https的抓包了。可以看到，https的數(shù)據(jù)安全關(guān)鍵點其實就是在數(shù)字證書上 ，因此也很容易理解為什么主流的瀏覽器都會警告用戶使用了來路不明的機構(gòu)頒發(fā)的證書。
實現(xiàn)https抓包，具體操作方案就是：用一個支持ssl的代理，偽造一個ca證書，當(dāng)通信雙方在TLS握手時發(fā)現(xiàn)有人竊聽時，設(shè)法讓他們相信代理的身份(這個過程就見2.3)； 代理身份被信任了，就會發(fā)生這個過程： 客戶端和代理進行握手，請求數(shù)據(jù)發(fā)到代理上，由代理和服務(wù)器做TLS握手，并轉(zhuǎn)傳客戶端的請求數(shù)據(jù)；服務(wù)器加密報文應(yīng)答，代理解密報文再用和客戶端協(xié)商的密碼方案加密報文，傳給客戶端，客戶端解密報文。
Charles抓包參看：http：//www.jianshu.com/p/7a88617ce80b
4 HTTPS的性能
4.1 HTTPS與HTTP的性能評測對比
我們使用Jmeter來測試http和https的比較。
在遠程服務(wù)器上搭建一個http服務(wù)器，讓它返回一個簡單的靜態(tài)網(wǎng)頁：
然后使用nginx進行代理
%2
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.vmgcyvh.cn/
本文網(wǎng)址：http://m.vmgcyvh.cn/html/support/11121521035.html
本文轉(zhuǎn)自：e-works制造業(yè)信息化門戶網(wǎng)
本文來源于互聯(lián)網(wǎng)，拓步ERP資訊網(wǎng)本著傳播知識、有益學(xué)習(xí)和研究的目的進行的轉(zhuǎn)載，為網(wǎng)友免費提供，并盡力標明作者與出處，如有著作權(quán)人或出版方提出異議，本站將立即刪除。如果您對文章轉(zhuǎn)載有任何疑問請告之我們，以便我們及時糾正。聯(lián)系方式：QQ：10877846 Tel：0755-26405298。（請勿發(fā)郵件，由于垃圾郵件眾多，有可能會被當(dāng)作垃圾郵件處理掉，同時現(xiàn)在很用郵件處理事務(wù)了，郵件處理時效期為3天，如急件請直接QQ聯(lián)系。）
相關(guān)文章- 服務(wù)器搭建五——VPN服務(wù)器搭建
- 華為自己從來不說的領(lǐng)導(dǎo)力秘密
- 李開復(fù)：人工智能在什么前提下會超越人類？
- 運維逼格提升心法：從報警到預(yù)警，如何有效提升SLO
- 打造與客戶互動的流程
- 2009年-2017年物聯(lián)網(wǎng)相關(guān)政策文件匯總
- 為什么云計算不一定節(jié)省企業(yè)成本？
- 新形勢下物聯(lián)網(wǎng)終端安全發(fā)展趨勢
- 建立端到端業(yè)務(wù)流程，給執(zhí)行力裝上降落傘
- 公司流程化管理中的常見問題
- 從上菜太慢，談事件管理、流程管理、數(shù)據(jù)管理
- 由“端到端”流程到流程信息化管理的思考
- 流程治理：一種理念，多種方法
- OA與BPM，企業(yè)該何去何從？
- 中小企業(yè)管理――規(guī)范與效率的博弈
- 基于CAD系統(tǒng)的協(xié)同設(shè)計探討
- 論“大數(shù)據(jù)”時代下的海量數(shù)據(jù)存儲技術(shù)
- 構(gòu)建5G網(wǎng)絡(luò)的核心技術(shù)：SDN與NFV的區(qū)別與聯(lián)系
- 盤點2017漢諾威工業(yè)展上的10款物聯(lián)網(wǎng)新品
- 為什么流程部門又是警察又是保姆？
