建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容介紹了“nginx怎么實(shí)現(xiàn)keyless”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
簡介
創(chuàng)新互聯(lián)建站成都網(wǎng)站建設(shè)按需設(shè)計(jì)網(wǎng)站，是成都網(wǎng)站營銷公司,為白烏魚提供網(wǎng)站建設(shè)服務(wù),有成熟的網(wǎng)站定制合作流程，提供網(wǎng)站定制設(shè)計(jì)服務(wù)：原型圖制作、網(wǎng)站創(chuàng)意設(shè)計(jì)、前端HTML5制作、后臺(tái)程序開發(fā)等。成都網(wǎng)站改版熱線：13518219792
當(dāng)企業(yè)把業(yè)務(wù)遷移到云WAF/邊緣節(jié)點(diǎn)上，需向云廠商提供業(yè)務(wù)的私鑰安全性不能得到保證，且若業(yè)務(wù)私鑰證書發(fā)生變化或頻繁修改需要受限于人。風(fēng)險(xiǎn)：一旦服務(wù)端的私鑰泄露會(huì)導(dǎo)致惡意攻擊者偽造虛假的和客戶端通信，通信內(nèi)容也存在被劫持和解密的風(fēng)險(xiǎn)。keyless源于clouldflare，采用keyless方案私鑰部署在客戶自己的服務(wù)器，無需向把業(yè)務(wù)私鑰部署在云/CDN邊緣節(jié)點(diǎn)上。clouldflare keyless項(xiàng)目地址：
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/cloudflare keyless開源項(xiàng)目地址：
https://github.com/cloudflare/keyless相關(guān)基礎(chǔ)知識(shí)介紹：加解密套件知識(shí)普及
MAC(Message authentication code)：消息認(rèn)證碼
PRF（pseudorandom function）：偽隨機(jī)函數(shù)
SHA (Secure Hash Algorithm）：安全散列算法
對(duì)稱密碼：
DES：是以64比特的明文為一個(gè)單位來進(jìn)行加密的，密鑰長度是64比特
三重DES: 就是將DES重復(fù)3次，有3個(gè)密鑰
AES（Advanced Encryption Standard）：是一種新標(biāo)準(zhǔn)的對(duì)稱密碼算法，已取代DES
分組長度128比特，密鑰長度128、192、256三種規(guī)格
分組密碼模式 ：
ECB（Electronic CodeBook）:將明文分組加密之后的結(jié)果將直接成為密文分組
CBC（Cipher Block Chaining）:密文分組鏈接的模式
CFB（Cipher FeedBack）:密文反饋模式
OFB（Output-Feedback）:輸入反饋模式
CTR（CounTeR）:計(jì)數(shù)器模式
GCM（Galois Counter Mode）：Galois/計(jì)數(shù)器模式
填充模式：對(duì)當(dāng)明文長度不為分組長度的整數(shù)倍時(shí)，需要在最后一個(gè)分組中填充一些數(shù)據(jù)使其填滿一個(gè)分組長度，攻擊者會(huì)利用這個(gè)利用這個(gè)在最后一個(gè)分組填充一些數(shù)據(jù)。
單向散列函數(shù)
輸入的是消息輸出的是散列值，任意長度的消息計(jì)算出固定長度的散列值，消息不同散列值也不同
應(yīng)用：MD4、MD5;SHA-2系列（SHA-256，SHA-384，SHA-512，數(shù)字表示計(jì)算后的散列值長度）
密鑰交換算法
RSA本質(zhì)上是為了解決密鑰配送的問題，密鑰配送的是配送的是運(yùn)算對(duì)稱密鑰的關(guān)鍵信息，并不是對(duì)稱密鑰
RSA：這是一個(gè)標(biāo)準(zhǔn)的密鑰交換算法，在ClientKeyExchange階段客戶端生成預(yù)主秘鑰，不支持向前保密，并以服務(wù)器公鑰加密傳送給服務(wù)器
DHE_RSA：臨時(shí)Diffie-Hellman(ephemeral Diffie-Hellman, DHE)，支持向前保密，缺點(diǎn)是執(zhí)行緩慢，DHE是一種秘鑰協(xié)定算法，進(jìn)行協(xié)商的團(tuán)體都對(duì)密鑰生成產(chǎn)生作用，并對(duì)公共密鑰產(chǎn)生作用
ECDHE_RSA和ECDHE_ECDSA：
臨時(shí)橢圓曲線Diffe-Hellman(ephemeral elliptic curve Diffie-Hellman, ECDHE)密鑰交換建立在橢圓曲線加密的基礎(chǔ)之上。執(zhí)行很快而且提供了向前保密，和DHE類似
過濾了一臺(tái)設(shè)備上一天的數(shù)據(jù)
TLS握手中使用的密碼技術(shù)
TLS記錄協(xié)議位于TLS協(xié)議的下層，是負(fù)責(zé)使用對(duì)稱密碼對(duì)消息進(jìn)行加密通信（對(duì)消息壓縮、加密以及數(shù)據(jù)的認(rèn)證）的部分
TLS握手協(xié)議中使用的密碼技術(shù)
公鑰密碼：加密預(yù)主秘鑰用的
單向散列函數(shù)：構(gòu)成偽隨機(jī)數(shù)生成器
數(shù)字簽名：驗(yàn)證證書用的（單向散列函數(shù)計(jì)算公鑰密碼的散列值，加密后得到）
偽隨機(jī)書生成器：生成預(yù)主秘鑰
生成初始化向量（可以使用對(duì)稱密碼，單向散列函數(shù)來構(gòu)建）？
根據(jù)主密鑰生成密鑰（密碼參數(shù)）？
TLS記錄協(xié)議中使用的密碼技術(shù)
對(duì)稱密碼（CBC模式）：確保片段的機(jī)密性
消息認(rèn)證碼：確保片段的完整性并進(jìn)行認(rèn)證（單向散列函數(shù)和密鑰組合而成，也可以通過對(duì)稱密碼生成，應(yīng)用單向散列函數(shù)計(jì)算密鑰+消息構(gòu)成的）
認(rèn)證加密（AEAD，Authenticated-Encryption with Associated-Data用于關(guān)聯(lián)數(shù)據(jù)的認(rèn)證加密）：確保片段的完整性和機(jī)密性并進(jìn)行認(rèn)證？HTTPS中所用到的密碼技術(shù)
證書：公鑰、數(shù)字簽名和指紋組合而成，一般講是基于指紋的數(shù)字簽名，一堆的東西就認(rèn)證公鑰，為了保證不可否認(rèn)行、認(rèn)證、完整性Keyless原理
總體架構(gòu)
密鑰交換算法類
client random 是第1個(gè)隨機(jī)數(shù)R1（公開），對(duì)應(yīng)wireshark抓包里“Client Hello”的Random
server random 是第2個(gè)隨機(jī)數(shù)R2（公開），對(duì)應(yīng)wireshark抓包里“Server Hello”的Random
premaster 是第3個(gè)隨機(jī)數(shù)R3（私密），該隨機(jī)數(shù)是由客戶端創(chuàng)建，然后客戶端用服務(wù)端傳來的證書對(duì)premaster secret進(jìn)行加密，生成premaster secret用來實(shí)際傳輸，對(duì)應(yīng)抓包里的“Client Key Exchange”
服務(wù)端用私鑰對(duì)premaster secret解密，得到premaster，這樣只有客戶端和服務(wù)端知道premaster
最終，客戶端和服務(wù)端用公開的隨機(jī)數(shù)R1、R2、雙方私密的premaster（R3）組合起來，通過預(yù)定的算法生成一個(gè)hash值，作為之后的對(duì)話密鑰（session key）
RSA密鑰交換算法主密鑰計(jì)算
Client Random和Server Random明文傳輸，中間人可以直接查看，客戶端生成于中Premaster Secret后，如果有證書私鑰就可以直接通過這三個(gè)參數(shù)解得主密鑰
標(biāo)準(zhǔn)RSAkeyless握手方案
工作在：Server端的ChangeCipherSpec階段
基于DH的完整握手主密鑰的計(jì)算
從密鑰交換流程來說，DH算法和ECDHE一樣，二者的主要區(qū)別見該頁備注里的注意點(diǎn)1~3
client random 是第1個(gè)隨機(jī)數(shù)R1（公開），對(duì)應(yīng)wireshark抓包里“Client Hello”的Random ②a、server random 是第2個(gè)隨機(jī)數(shù)R2（公開），對(duì)應(yīng)wireshark抓包里“Server Hello”的Random
服務(wù)端自己創(chuàng)建一個(gè)隨機(jī)數(shù)或者 直接從證書中拿公鑰信息（圖例是拿公鑰信息），記為R3 ，結(jié)合上面的兩個(gè)公開的隨機(jī)數(shù)，通過DH算法算出來服務(wù)端DH參數(shù)=（R1 * R2 * R3） ，對(duì)應(yīng)wireshark抓包里“Server Key Exchange”的Pubkey。
服務(wù)端用私鑰，對(duì)兩個(gè)公開隨機(jī)數(shù)R1、R2和服務(wù)端的DH參數(shù)進(jìn)行簽名，對(duì)應(yīng)wireshark抓包里“Server Key Exchange”的Signature
客戶端用證書公鑰驗(yàn)證Signature，驗(yàn)證服務(wù)端確實(shí)擁有私鑰后，客戶端就創(chuàng)建一個(gè)隨機(jī)數(shù)，記為R4，通過DH算法算出來客戶端DH參數(shù)=（R1 * R2 * R4） ，對(duì)應(yīng)wireshark抓包里“Client Key Exchange”的Pubkey 。 這樣，客戶端和服務(wù)端用對(duì)方發(fā)來的DH參數(shù)，結(jié)合各自的私有隨機(jī)數(shù)R3或R4，分別計(jì)算得到相同的premaster = （R1 * R2 * R3 * R4） ，且只有客戶端和服務(wù)端知道premaster 最終，客戶端和服務(wù)端用公開的隨機(jī)數(shù)1、隨機(jī)數(shù)2、雙方私密的premaster組合起來，通過預(yù)定的算法生成一個(gè)hash值，作為之后的對(duì)話密鑰（session key）
Server DH Parameter 是用證書私鑰簽名的，客戶端使用證書公鑰就可以驗(yàn)證服務(wù)端合法性，相比 RSA 密鑰交換，DH 由傳遞 Premaster Scret 變成了傳遞 DH 算法所需的 Parameter，然后雙方各自算出 Premaster Secret。由于 Premaster Secret 無需交換，中間人就算有私鑰也無法獲得 Premaster Secret 和 Master Secret。
ServerKeyExchange
基于DH的keyless的完整握手
工作在：Server端的ServerKeyExchange階段
開源項(xiàng)目做了什么keyless server安裝和配置
存儲(chǔ)給定的私鑰。
使用加速卡(EXAR)進(jìn)行解密，簽名操作。
狀態(tài)信息統(tǒng)計(jì)。開源項(xiàng)目地址：
https://github.com/cloudflare/keyless
需要進(jìn)行二次開發(fā)，開源版本很多細(xì)節(jié)處理的不好。
On Centos:
sudo yum install gcc automake libtool
sudo yum install rpm-build rubybgems ruby-devel # only required for packages
sudo gem install fpm --no-ri --no-rdoc # only required for packages
安裝 make即可，make test測(cè)試
參數(shù)說明 --port keyless server端的監(jiān)聽端口
--ip keyless server端監(jiān)聽的ip
--server-cert和--server-key簽發(fā)的證書
--private-key-directory 用戶證書對(duì)應(yīng)的私鑰存放文件夾
--ca-file生成的根證書
--pid-file pid文件
--num-workers 線程數(shù)
--verbose打印日志
--daemon守護(hù)進(jìn)程開啟nginx于keyless server交互?
在SSL_do_handshake解密和簽名處理過程中增加一個(gè)keyless狀態(tài)。
PREPARE REQUEST狀態(tài)，封裝keyless請(qǐng)求報(bào)文，然后將狀態(tài)設(shè)置為SEND REQUEST，SSL_do_handshake函數(shù)返回，nginx將keyless_connection的wev放到epoll里；
SEND REQUEST狀態(tài)發(fā)送keyless請(qǐng)求，成功后將狀態(tài)設(shè)置為RECEIVE RESPONSE，SSL_do_handshake函數(shù)返回，nginx將keyless_connection的rev放到epoll里；
RECEIVE RESPONSE狀態(tài)讀請(qǐng)求，全部讀完將狀態(tài)設(shè)置為FINISH；如果未讀完數(shù)據(jù)SSL_do_handshake函數(shù)返回，nginx將keyless_connection的rev放到epoll里；
FINISH 繼續(xù)由openssl原有的邏輯處理。
如果rev和wev超時(shí)，則關(guān)閉ssl_connection。
nginx 處理https握手
ngx_http_init_connection中recv→handler設(shè)置為ngx_http_ssl_handshake,把這個(gè)讀時(shí)間加入到epoll中，重點(diǎn)看handshake這個(gè)函數(shù)
第一次收到client hello之后，完成初始化后調(diào)用ngx_ssl_handshake，其調(diào)用openssl的ssl_do_handshake
調(diào)用keyless模塊的init函數(shù)先是獲取coremodule的main conf，然后獲取到servers，遍歷這些servers的上下文中的srv conf配置，然后把sscf→ssl.ctx設(shè)置cert_cb為keyless_cert_handler，這個(gè)函數(shù)在api使用證書的時(shí)候會(huì)調(diào)用。
cert handler做了了很多事情，初始化了很多nginx keyless相關(guān)的參數(shù)，核心在于這個(gè)函數(shù)新建了一條通向keyserver的連接。
do handshake的時(shí)候調(diào)用的是openssl的async job的庫，相當(dāng)于新開一個(gè)函數(shù)棧
ASYNC JOB
先做初始化get下context，malloc一個(gè)stack，這個(gè)堆棧創(chuàng)建完成后把函數(shù)放進(jìn)去，使用makecontext來創(chuàng)建一旦調(diào)用就會(huì)運(yùn)行該函數(shù)，async_start_func本身使用當(dāng)前job中的func，函數(shù)也是傳進(jìn)來的參數(shù)
Pause job最關(guān)鍵的是swapcontext，這個(gè)在func中一旦被調(diào)用的話，就可以立即切換棧信息，切回start_job的主函數(shù)，根據(jù)job→status=ASYNC_JOB_PAUSING來返回
切回主函數(shù)之后，因?yàn)閟tart job是for死循環(huán)，所以會(huì)根據(jù)job的狀態(tài)進(jìn)行返回
返回的這個(gè)狀態(tài)碼，在nginx里面接到就是SSL_ERROR_WANT_ASYNC
關(guān)鍵就是調(diào)用async_pause_job交還給nginx來做keyless處理，以及將與keyserver的狀態(tài)調(diào)整為presend。
這里處理完交還給nginx，之后nginx 就可以做原本由openssl實(shí)現(xiàn)的加解密。
重寫engine重寫兩個(gè)關(guān)鍵函數(shù)
重寫的兩個(gè)函數(shù)是sign和priv_dec
調(diào)用pause時(shí)最重要邏輯是async_fibre_swapcontext，這個(gè)函數(shù)是用于切換的核心，同時(shí)進(jìn)行初始化操作，把函數(shù)放到新開辟棧里運(yùn)行。
本文標(biāo)題：nginx怎么實(shí)現(xiàn)keyless
網(wǎng)址分享：http://www.dlmjj.cn/article/ejocgh.html
