1. 背景
1.1. 嚴峻的安全形勢
1.1.1. OpenSSL Heart bleed漏洞
2014年上半年對網絡安全影響最大的問題就是OpenSSL Heart bleed漏洞，來自Codenomicon和谷歌安全部門的研究人員發(fā)現(xiàn)OpenSSL的源代碼中存在一個漏洞，可以讓攻擊者獲得服務器上64K內存中的數(shù)據(jù)內容。該漏洞在國內被譯為” OpenSSL心臟出血漏洞”，因其破壞性之大和影響的范圍之廣，堪稱網絡安全里程碑事件。
OpenSSL是為網絡通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議，囊括了主要的密碼算法、常用的密鑰和證書封裝管理功能以及SSL協(xié)議．多數(shù)SSL加密網站是用名為OpenSSL的開源軟件包，由于這也是互聯(lián)網應用最廣泛的安全傳輸方法，被網銀、在線支付、電商網站、門戶網站、電子郵件等重要網站廣泛使用，所以漏洞影響范圍廣大。
全球第一個被攻擊通告的案例是加拿大稅務局確認OpenSSL Heart bleed漏洞導致了900個納稅人的社會保障號被盜，這900個納稅人的社保號被攻擊者在系統(tǒng)中完全刪除了。
?
1.1.2. 安全漏洞的高成本
任何網絡攻擊都能夠給企業(yè)造成破壞，但是如何將這些破壞具體量化成金融數(shù)據(jù)呢？2013年，B2B International聯(lián)合卡巴斯基實驗室基于對全球企業(yè)的調查結果，計算出網絡攻擊平均造成的損失。
根據(jù)調查報告得出的結論，當企業(yè)遭遇網絡攻擊后平均損失為649,000美元。損失主要包括兩方面：
- 安全事件本身造成的損失，即由重要數(shù)據(jù)泄漏、業(yè)務連續(xù)性以及安全修復專家費用相關成本；
- 為列入計劃的”響應”成本，用于阻止未來發(fā)生類似的攻擊事件，包括雇傭、培訓員工成本以及硬件、軟件和其它基礎設施安全升級成本。
1.2. Netty面臨的安全風險
作為一個高性能的NIO通信框架，基于Netty的行業(yè)應用非常廣泛，不同的行業(yè)、不同的應用場景，面臨的安全挑戰(zhàn)也不同，下面我們根據(jù)Netty的典型應用場景，分析下Netty面臨的安全挑戰(zhàn)。
1.2.1. 僅限內部使用的RPC通信框架
隨著業(yè)務的發(fā)展，網站規(guī)模的擴大，傳統(tǒng)基于MVC的垂直架構已經無法應對業(yè)務的快速發(fā)展。需要對數(shù)據(jù)和業(yè)務進行水平拆分，基于RPC的分布式服務框架成為最佳選擇。
業(yè)務水平拆分之后，內部的各個模塊需要進行高性能的通信，傳統(tǒng)基于RMI和Hession的同步阻塞式通信已經無法滿足性能和可靠性要求。因此，高性能的NIO框架成為構建分布式服務框架的基石。
網站的架構演進過程如下：
圖1-1 網站的架構演進
高性能的RPC框架，各模塊之間往往采用長連接通信，通過心跳檢測保證鏈路的可靠性。由于RPC框架通常是在內部各模塊之間使用，運行在授信的內部安全域中，不直接對外開放接口。因此，不需要做握手、黑白名單、SSL/TLS等，正所謂是“防君子不防小人”。
在這種應用場景下，Netty的安全性是依托企業(yè)的防火墻、安全加固操作系統(tǒng)等系統(tǒng)級安全來保障的，它自身并不需要再做額外的安全性保護工作。
1.2.2. 對第三方開放的通信框架
如果使用Netty做RPC框架或者私有協(xié)議棧，RPC框架面向非授信的第三方開放，例如將內部的一些能力通過服務對外開放出去，此時就需要進行安全認證，如果開放的是公網IP，對于安全性要求非常高的一些服務，例如在線支付、訂購等，需要通過SSL/TLS進行通信。
它的原理圖如下：
圖1-2 對第三方開放的通信框架
對第三方開放的通信框架的接口調用存在三種場景：
- 在企業(yè)內網，開放給內部其它模塊調用的服務，通常不需要進行安全認證和SSL/TLS傳輸；
- 在企業(yè)內網，被外部其它模塊調用的服務，往往需要利用IP黑白名單、握手登陸等方式進行安全認證，認證通過之后雙方使用普通的Socket進行通信，如果認證失敗，則拒絕客戶端連接；
- 開放給企業(yè)外部第三方應用訪問的服務，往往需要監(jiān)聽公網IP（通常是防火墻的IP地址），由于對第三方服務調用者的監(jiān)管存在諸多困難，或者無法有效監(jiān)管，這些第三方應用實際是非授信的。為了有效應對安全風險，對于敏感的服務往往需要通過SSL/TLS進行安全傳輸。
1.2.3. 應用層協(xié)議的安全性
作為高性能、異步事件驅動的NIO框架，Netty非常適合構建上層的應用層協(xié)議，相關原理，如下圖所示：
圖1-3 基于Netty構建應用層協(xié)議
由于絕大多數(shù)應用層協(xié)議都是公有的，這意味著底層的Netty需要向上層提供通信層的安全傳輸，也就是需要支持SSL/TLS。
JDK的安全類庫提供了javax.net.ssl.SSLSocket和javax.net.ssl.SSLServerSocket類庫用于支持SSL/TLS安全傳輸，對于NIO非阻塞Socket通信，JDK并沒有提供現(xiàn)成可用的類庫簡化用戶開發(fā)。
Netty通過JDK的SSLEngine，以SslHandler的方式提供對SSL/TLS安全傳輸?shù)闹С?，極大的簡化了用戶的開發(fā)工作量，降低開發(fā)難度。
對于Netty默認提供的HTTP協(xié)議，Netty利用SslHandler，同樣支持HTTPS協(xié)議。
2. Netty SSL開發(fā)
2.1. SSL單向認證
單向認證，即客戶端只驗證服務端的合法性，服務端不驗證客戶端。下面我們通過Netty的SSL單向認證代碼開發(fā)來掌握基于Netty的SSL單向認證。
2.1.1. SSL單向認證開發(fā)
首先，利用JDK的keytool工具，Netty服務端依次生成服務端的密鑰對和證書倉庫、服務端自簽名證書。
生成Netty服務端私鑰和證書倉庫命令：
keytool -genkey -alias securechat -keysize 2048 -validity
365 -keyalg RSA -dname "CN=localhost" -keypass sNetty
-storepass sNetty -keystore sChat.jks
生成Netty服務端自簽名證書：
keytool -export -alias securechat -keystore sChat.jks -storepass sNetty -file sChat.cer
生成客戶端的密鑰對和證書倉庫，用于將服務端的證書保存到客戶端的授信證書倉庫中，命令如下：
keytool -genkey -alias smcc -keysize 2048 -validity 365
-keyalg RSA -dname "CN=localhost" -keypass cNetty
-storepass cNetty -keystore cChat.jks
隨后，將Netty服務端的證書導入到客戶端的證書倉庫中，命令如下：
keytool -import -trustcacerts -alias securechat -file sChat.cer -storepass cNetty -keystore cChat.jks
上述工作完成之后，我們就開始編寫SSL服務端和客戶端的代碼，下面我們對核心代碼進行講解。
首先看服務端的代碼，在TCP鏈路初始化的時候，創(chuàng)建SSLContext并對其進行正確的初始化，下面我們對SSLContext的創(chuàng)建進行講解：
因為是客戶端認證服務端，因此服務端需要正確的設置和加載私鑰倉庫KeyStore，相關代碼如下：
初始化KeyManagerFactory之后，創(chuàng)建SSLContext并初始化，代碼如下：
由于是單向認證，服務端不需要驗證客戶端的合法性，因此，TrustManager為空，安全隨機數(shù)不需要設置，使用JDK默認創(chuàng)建的即可。
服務端的SSLContext創(chuàng)建完成之后，利用SSLContext創(chuàng)建SSL引擎SSLEngine，設置SSLEngine為服務端模式，由于不需要對客戶端進行認證，因此NeedClientAuth不需要額外設置，使用默認值False。相關代碼如下：
SSL服務端創(chuàng)建完成之后，下面繼續(xù)看客戶端的創(chuàng)建，它的原理同服務端類似，也是在初始化TCP鏈路的時候創(chuàng)建并設置SSLEngine，代碼如下：
由于是客戶端認證服務端，因此，客戶端只需要加載存放服務端CA的證書倉庫即可。
加載證書倉庫完成之后，初始化SSLContext，代碼如下：對于客戶端只需要設置信任證書TrustManager。
客戶端SSLContext初始化完成之后，創(chuàng)建SSLEngine并將其設置為客戶端工作模式，代碼如下：
將SslHandler添加到pipeline中，利用SslHandler實現(xiàn)Socket安全傳輸，代碼如下：
客戶端和服務端創(chuàng)建完成之后，測試下SSL單向認證功能是否OK，為了查看SSL握手過程，我們打開SSL握手的調測日志，Eclipse設置如下：
圖2-1 打開SSL調測日志
分別運行服務端和客戶端，運行結果如下：
圖2-2 客戶端SSL握手日志
圖2-3 服務端SSL握手日志
在客戶端輸入信息，服務端原樣返回，測試結果如下：
到此，Netty SSL單向認證已經開發(fā)完成，下個小節(jié)我們將結合SSL握手日志，詳細解讀下SSL單向認證的原理。
2.1.2. SSL單向認證原理分析
SSL單向認證的過程總結如下：
- SSL客戶端向服務端傳送客戶端SSL協(xié)議的版本號、支持的加密算法種類、產生的隨機數(shù)，以及其它可選信息；
- 服務端返回握手應答，向客戶端傳送確認SSL協(xié)議的版本號、加密算法的種類、隨機數(shù)以及其它相關信息；
- 服務端向客戶端發(fā)送自己的公鑰；
- 客戶端對服務端的證書進行認證，服務端的合法性校驗包括：證書是否過期、發(fā)行服務器證書的CA是否可靠、發(fā)行者證書的公鑰能否正確解開服務器證書的“發(fā)行者的數(shù)字簽名”、服務器證書上的域名是否和服務器的實際域名相匹配等；
- 客戶端隨機產生一個用于后面通訊的“對稱密碼”，然后用服務端的公鑰對其加密，將加密后的“預主密碼”傳給服務端；
- 服務端將用自己的私鑰解開加密的“預主密碼”，然后執(zhí)行一系列步驟來產生主密碼；
- 客戶端向服務端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用主密碼為對稱密鑰，同時通知服務器客戶端的握手過程結束；
- 服務端向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用主密碼為對稱密鑰，同時通知客戶端服務器端的握手過程結束；
- SSL的握手部分結束，SSL安全通道建立，客戶端和服務端開始使用相同的對稱密鑰對數(shù)據(jù)進行加密，然后通過Socket進行傳輸；
下面，我們結合JDK的SSL工作原理對Netty的SSL單向認證過程進行講解，首先，我們看下JDK SSL單向認證的流程圖：
圖2-4 SSL單向認證流程圖
下面結合JDK SSL引擎的調測日志信息我們對SSL單向認證的流程進行詳細講解，對于比較簡單的流程會進行步驟合并。
步驟1：客戶端使用TLS協(xié)議版本發(fā)送一個ClientHello消息，這個消息包含一個隨機數(shù)、建議的加密算法套件和壓縮方法列表，如下所示：
*** ClientHello, TLSv1
RandomCookie: GMT: 1389796107 bytes = { 125, 107, 138, 150, 226, 182, 238, 75, 38,
150, 222, 147, 127, 35, 36, 149, 172, 128, 152, 34, 110, 104, 176, 34, 180, 118, 185, 55 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1,
sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1,
sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1,
sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
步驟2：服務端使用ServerHello消息來響應，這個消息包含由客戶提供的信息基礎上的另一個隨機數(shù)和一個可選的會話ID，以及服務端選擇的加密套件算法，響應消息如下：
*** ServerHello, TLSv1
RandomCookie: GMT: 1389796108 bytes = { 27, 170, 76, 238, 56, 58, 172, 146,
41, 159, 249, 213, 16, 214, 53, 167, 50, 74, 39, 107, 121, 63, 80, 26, 210, 149, 249, 194 }
Session ID: {83, 215, 155, 12, 122, 5, 231, 3, 13, 11, 17, 204, 56, 73, 119,
49, 85, 229, 220, 92, 55, 40, 25, 194, 198, 244, 200, 6, 55, 209, 23, 245}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
步驟3：服務端發(fā)送自簽名的證書消息，包含完整的證書鏈：
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=localhost
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 180074092335949740506599932729136061127910704822256890304785299212
89120399567693292155689698972062026646025485683710348109589875614228688670418
26997320367322716218554750309434289655244757299259864742384047112657948157239
74656070231306588457907121768485493115189644689102055777319298694358710534010
07782509767857568645054682957874162480829502504137753701941108204165639642395
91445925708790136700350526512926021140926345621403182628994210668730957728483
67874786322927437079881769937503767679525485790533062220506746478912515940552
94347989837561879359652740344329755331698082706888032724267649830488014296906
294110074041
public exponent: 65537
Validity: [From: Sun Jul 27 08:49:30 CST 2014,
To: Mon Jul 27 08:49:30 CST 2015]
Issuer: CN=localhost
SerialNumber: [ 53d44c9a]
]
Algorithm: [SHA1withRSA]
Signature:
0000: 10 05 5E D4 EE A8 1C 8E 82 F1 3F 6B 0A 34 9B 96 ..^.......?k.4..
0010: 97 BE 62 13 F7 2E 94 74 A5 46 CC AB C5 0B FC 67 ..b....t.F.....g
0020: 3C E1 1B 43 B8 A4 3B C9 F9 44 9F F2 D2 90 35 3C <..C..;..D....5<
0030: F6 47 78 3A AC 6B 87 E5 43 EA C8 C5 8C 4C 6E AB .Gx:.k..C....Ln.
0040: 46 F8 C8 C4 BA 86 97 1E C5 75 2F 85 15 CB A1 93 F........u/.....
0050: 0E 23 06 57 93 47 DF 8D 04 0F 21 AC FC E0 7D 14 .#.W.G....!.....
0060: 07 BE 0F 62 F4 75 A9 CE F9 B3 11 0B 75 B4 87 22 ...b.u......u.."
0070: D5 8E E2 0A A9 1F C2 15 3A 64 B2 23 8F 1A 84 6C ........:d.#...l
0080: EE 2C 3A C3 24 65 F5 BC 5C AF BD F8 B9 C4 45 83 .,:.$e..\.....E.
0090: 5B FF BD 36 E8 5D BE 98 03 2E AB 3F FE EC 9A 7B [..6.].....?....
00A0: 31 35 7D EF 53 81 8B 7A 8B 37 7D BD EB 17 F0 36 15..S..z.7.....6
00B0: 93 CF 74 28 A3 C1 8B E1 B1 12 9F 44 20 CA 48 64 ..t(.......D .Hd
00C0: D6 F5 B0 B1 D9 18 AA F6 88 02 26 93 C8 B8 91 1A ..........&.....
00D0: F8 B0 8B E6 7D C6 56 39 B2 6A AF 73 D2 78 76 1A ......V9.j.s.xv.
00E0: 10 F0 C5 98 4F 90 39 2F 84 BC A0 78 81 8B ED 04 ....O.9/...x....
00F0: B8 60 49 84 C3 BD CC D2 CA 52 0A 03 E0 6C 21 B3 .`I......R...l!.
]
***
步驟4：服務端向客戶端發(fā)送自己的公鑰信息，最后發(fā)送ServerHelloDone：
*** ECDH ServerKeyExchange
Server key: Sun EC public key, 256 bits
public x coord: 11246390291863077910794590233832192297756589204670697
905888685651118114908704
public y coord: 14161558430218398366136024174925258002831938156653157
074058492642854053163673
parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
*** ServerHelloDone
步驟5：客戶端對服務端自簽名的證書進行認證，如果客戶端的信任證書列表中包含了服務端發(fā)送的證書，對證書進行合法性認證，相關信息如下：
***
Found trusted certificate:
[
[
Version: V3
Subject: CN=localhost
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 18007409233594974050659993272913606112791070482225689030478529921
2891203995676932921556896989720620266460254856837103481095898756142286886704
1826997320367322716218554750309434289655244757299259864742384047112657948157
2397465607023130658845790712176848549311518964468910205577731929869435871053
4010077825097678575686450546829578741624808295025041377537019411082041656396
4239591445925708790136700350526512926021140926345621403182628994210668730957
7284836787478632292743707988176993750376767952548579053306222050674647891251
5940552943479898375618793596527403443297553316980827068880327242676498304880
14296906294110074041
public exponent: 65537
Validity: [From: Sun Jul 27 08:49:30 CST 2014,
To: Mon Jul 27 08:49:30 CST 2015]
Issuer: CN=localhost
SerialNumber: [ 53d44c9a]
]
Algorithm: [SHA1withRSA]
Signature:
0000: 10 05 5E D4 EE A8 1C 8E 82 F1 3F 6B 0A 34 9B 96 ..^.......?k.4..
0010: 97 BE 62 13 F7 2E 94 74 A5 46 CC AB C5 0B FC 67 ..b....t.F.....g
0020: 3C E1 1B 43 B8 A4 3B C9 F9 44 9F F2 D2 90 35 3C <..C..;..D....5<
0030: F6 47 78 3A AC 6B 87 E5 43 EA C8 C5 8C 4C 6E AB .Gx:.k..C....Ln.
0040: 46 F8 C8 C4 BA 86 97 1E C5 75 2F 85 15 CB A1 93 F........u/.....
0050: 0E 23 06 57 93 47 DF 8D 04 0F 21 AC FC E0 7D 14 .#.W.G....!.....
0060: 07 BE 0F 62 F4 75 A9 CE F9 B3 11 0B 75 B4 87 22 ...b.u......u.."
0070: D5 8E E2 0A A9 1F C2 15 3A 64 B2 23 8F 1A 84 6C ........:d.#...l
0080: EE 2C 3A C3 24 65 F5 BC 5C AF BD F8 B9 C4 45 83 .,:.$e..\.....E.
0090: 5B FF BD 36 E8 5D BE 98 03 2E AB 3F FE EC 9A 7B [..6.].....?....
00A0: 31 35 7D EF 53 81 8B 7A 8B 37 7D BD EB 17 F0 36 15..S..z.7.....6
00B0: 93 CF 74 28 A3 C1 8B E1 B1 12 9F 44 20 CA 48 64 ..t(.......D .Hd
00C0: D6 F5 B0 B1 D9 18 AA F6 88 02 26 93 C8 B8 91 1A ..........&.....
00D0: F8 B0 8B E6 7D C6 56 39 B2 6A AF 73 D2 78 76 1A ......V9.j.s.xv.
00E0: 10 F0 C5 98 4F 90 39 2F 84 BC A0 78 81 8B ED 04 ....O.9/...x....
00F0: B8 60 49 84 C3 BD CC D2 CA 52 0A 03 E0 6C 21 B3 .`I......R...l!.
]
步驟6：客戶端通知服務器改變加密算法，通過Change Cipher Spec消息發(fā)給服務端，隨后發(fā)送Finished消息，告知服務器請檢查加密算法的變更請求：
nioEventLoopGroup-2-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
步驟7：服務端讀取到Change Cipher Spec變更請求消息，向客戶端返回確認密鑰變更消息，最后通過發(fā)送Finished消息表示SSL/TLS握手結束。
nioEventLoopGroup-3-1, READ: TLSv1 Change Cipher Spec, length = 1
nioEventLoopGroup-3-1, READ: TLSv1 Handshake, length = 48
*** Finished
verify_data: { 157, 255, 187, 52, 139, 16, 20, 190, 11, 35, 79, 0 }
***
nioEventLoopGroup-3-1, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
2.2. SSL雙向認證
2.2.1. SSL雙向認證開發(fā)
我們在2.1章節(jié)的基礎上進行開發(fā)，與單向認證不同的是服務端也需要對客戶端進行安全認證。這就意味著客戶端的自簽名證書也需要導入到服務端的數(shù)字證書倉庫中。
首先，生成客戶端的自簽名證書：
keytool -export -alias smcc -keystore cChat.jks -storepass cNetty
-file cChat.cer
最后，將客戶端的自簽名證書導入到服務端的信任證書倉庫中：
keytool -import -trustcacerts -alias smcc -file cChat.cer -storepass
sNetty -keystore sChat.jks
證書導入之后，需要對SSL客戶端和服務端的代碼同時進行修改，首先我們看下服務端如何修改。
由于服務端需要對客戶端進行驗證，因此在初始化服務端SSLContext的時候需要加載證書倉庫。首先需要對TrustManagerFactory進行初始化，代碼如下：
初始化SSLContext的時候根據(jù)TrustManagerFactory獲取TrustManager數(shù)組，代碼如下：
最后，創(chuàng)建SSLEngine之后，設置需要進行客戶端認證，代碼如下：
完成服務端修改之后，再回頭看下客戶端的修改，由于服務端需要認證客戶端的證書，因此，需要初始化和加載私鑰倉庫，向服務端發(fā)送公鑰，初始化KeyStore的代碼如下：
初始化SSLContext的時候需要傳入KeyManager數(shù)組，代碼如下：
客戶端開發(fā)完成之后，測試下程序是否能夠正常工作，運行結果如下所示。
客戶端運行結果：
圖2-5 Netty SSL雙向認證客戶端運行結果
服務端運行結果：
圖2-6 Netty SSL雙向認證服務端運行結果
在客戶端控制臺進行輸入，看SSL傳輸是否正常：
圖2-7 Netty SSL 安全傳輸測試
2.2.2. SSL雙向認證原理分析
SSL雙向認證相比單向認證，多了一步服務端發(fā)送認證請求消息給客戶端，客戶端發(fā)送自簽名證書給服務端進行安全認證的過程。下面，我們結合Netty SSL調測日志，對雙向認證的差異點進行分析。
相比于客戶端，服務端在發(fā)送ServerHello時攜帶了要求客戶端認證的請求信息，如下所示：
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<CN=localhost>
<CN=localhost>
*** ServerHelloDone
客戶端接收到服務端要求客戶端認證的請求消息之后，發(fā)送自己的證書信息給服務端，信息如下：
matching alias: smcc
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=localhost
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 212639695562264078962258083015763969567082142460170954053624074
53705267323050920051941696590911289892005894127848317880153980200067657563
15944918691324084822137929027919841383304228071408660098765703368443353862
47349919704780645114810932016343908989985053434023995248208445566727867691
73042913746571760169661698040844437316556983406538131853892449014877947773
16977794500345715634646402492099542466990685058179767825995777860790787074
72339147926907851214779520246763960901175126351376922481444497141021631392
59603124160944922844840171133151822882039207352509182052426500279100525773
147139994269292585983679425433429361
public exponent: 65537
Validity: [From: Sun Jul 27 08:50:35 CST 2014,
To: Mon Jul 27 08:50:35 CST 2015]
Issuer: CN=localhost
SerialNumber: [ 53d44cdb]
服務端對客戶端的自簽名證書進行認證，信息如下：
***
Found trusted certificate:
[
[
Version: V3
Subject: CN=localhost
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 21263969556226407896225808301576396956708214246017095405362407
4537052673230509200519416965909112898920058941278483178801539802000676575
6315944918691324084822137929027919841383304228071408660098765703368443353
8624734991970478064511481093201634390898998505343402399524820844556672786
7691730429137465717601696616980408444373165569834065381318538924490148779
4777316977794500345715634646402492099542466990685058179767825995777860790
7870747233914792690785121477952024676396090117512635137692248144449714102
1631392596031241609449228448401711331518228820392073525091820524265002791
00525773147139994269292585983679425433429361
public exponent: 65537
Validity: [From: Sun Jul 27 08:50:35 CST 2014,
To: Mon Jul 27 08:50:35 CST 2015]
Issuer: CN=localhost
SerialNumber: [ 53d44cdb]
2.3. 第三方CA認證
使用jdk keytool生成的數(shù)字證書是自簽名的。自簽名就是指證書只能保證自己是完整且沒有經過非法修改，但是無法保證這個證書是屬于誰的。為了對自簽名證書進行認證，需要每個客戶端和服務端都交換自己自簽名的私有證書，對于一個大型網站或者應用服務器，這種工作量是非常大的。
基于自簽名的SSL雙向認證，只要客戶端或者服務端修改了密鑰和證書，就需要重新進行簽名和證書交換，這種調試和維護工作量是非常大的。因此，在實際的商用系統(tǒng)中往往會使用第三方CA證書頒發(fā)機構進行簽名和驗證。我們的瀏覽器就保存了幾個常用的CA_ROOT。每次連接到網站時只要這個網站的證書是經過這些CA_ROOT簽名過的。就可以通過驗證了。
CA數(shù)字證書認證服務往往是收費的，國內有很多數(shù)字認證中心都提供相關的服務，如下所示：
圖2-8 商業(yè)的數(shù)字認證中心
作為示例，我們自己生成一個CA_ROOT的密鑰對，部署應用時，把這個CA_ROOT的私鑰部署在所有需要SSL傳輸?shù)墓?jié)點就可以完成安全認證。作為示例，如果要生成CA_ROOT，我們使用開源的OpenSSL。
在Windows上安裝和使用OpenSSL網上有很多教程，也不是本文的重點，因此，OpenSSL的安裝和使用本文不詳細介紹。
下面我們對基于第三方CA認證的步驟進行詳細介紹。
2.3.1. 服務端證書制作
步驟1：利用OpenSSL生成CA證書：
openssl req -new -x509 -keyout ca.key -out ca.crt -days 365
步驟2：生成服務端密鑰對：
keytool -genkey -alias securechat -keysize 2048 -validity 365
-keyalg RSA -dname "CN=localhost" -keypass sNetty -storepass sNetty
-keystore sChat.jks
步驟3：生成證書簽名請求：
keytool -certreq -alias securechat -sigalg MD5withRSA -file sChat.csr
-keypass sNetty -storepass sNetty -keystore sChat.jks
步驟4：用CA私鑰進行簽名：
openssl ca -in sChat.csr -out sChat.crt -cert ca.crt -keyfile ca.key -notext
步驟5：導入信任的CA根證書到keystore：
keytool -import -v -trustcacerts -alias ca_root -file ca.crt -storepass
sNetty -keystore sChat.jks
步驟6：將CA簽名后的server端證書導入keystore：
keytool -import -v -alias securechat -file server.crt -keypass sNetty
-storepass sNetty -keystore sChat.jks
2.3.2. 客戶端證書制作
步驟1：生成客戶端密鑰對：
keytool -genkey -alias smcc -keysize 2048 -validity 365 -keyalg
RSA -dname "CN=localhost" -keypass cNetty -storepass cNetty -keystore cChat.jks
步驟2：生成證書簽名請求：
keytool -certreq -alias smcc -sigalg MD5withRSA -file cChat.csr
-keypass cNetty -storepass cNetty -keystore cChat.jks
步驟3：用CA私鑰進行簽名：
openssl ca -in cChat.csr -out cNetty.crt -cert ca.crt -keyfile ca.key -notext
步驟4：導入信任的CA根證書到keystore：
keytool -import -v -trustcacerts -alias ca_root -file ca.crt
-storepass cNetty -keystore cChat.jks
步驟5：將CA簽名后的client端證書導入keystore：
keytool -import -v -alias smcc -file cNetty.crt -keypass cNetty -storepass
cNetty -keystore cChat.jks
2.3.3. 開發(fā)和測試
基于CA認證的開發(fā)和測試與SSL雙向和單向認證代碼相同，此處不再贅述。
3. Netty SSL源碼分析
3.1. SSL客戶端
當客戶端和服務端的TCP鏈路建立成功之后，SslHandler的channelActive被觸發(fā)，SSL客戶端通過SSL引擎發(fā)起握手請求消息，代碼如下：
發(fā)起握手請求之后，需要將SSLEngine創(chuàng)建的握手請求消息進行SSL編碼，發(fā)送給服務端，因此，握手之后立即調用wrapNonAppData方法，下面具體對該方法進行分析：
因為只需要發(fā)送握手請求消息，因此Source ByteBuf為空，下面看下wrap方法的具體實現(xiàn)：
將SSL引擎中創(chuàng)建的握手請求消息編碼到目標ByteBuffer中，然后對寫索引進行更新。判斷寫入操作是否越界，如果越界說明out容量不足，需要調用ensureWritable對ByteBuf進行動態(tài)擴展，擴展之后繼續(xù)嘗試編碼操作。如果編碼成功，返回SSL引擎操作結果。
對編碼結果進行判斷，如果編碼字節(jié)數(shù)大于0，則將編碼后的結果發(fā)送給服務端，然后釋放臨時變量out。
判斷SSL引擎的操作結果，SSL引擎的操作結果定義如下：
- FINISHED：SSLEngine 已經完成握手；
- NEED_TASK：SSLEngine 在繼續(xù)進行握手前需要一個（或多個）代理任務的結果；
- NEED_UNWRAP：在繼續(xù)進行握手前，SSLEngine 需要從遠端接收數(shù)據(jù)，所以應帶調用SSLEngine.unwrap()；
- NEED_WRAP:在繼續(xù)進行握手前，SSLEngine 必須向遠端發(fā)送數(shù)據(jù)，所以應該調用 SSLEngine.wrap()；
- NOT_HANDSHAKING:SSLEngine 當前沒有進行握手。
下面我們分別對5種操作的代碼進行分析：
如果握手成功，則設置handshakePromise的操作結果為成功，同時發(fā)送SslHandshakeCompletionEvent.SUCCES給SSL監(jiān)聽器，代碼如下：
如果是NEED_TASK，說明異步執(zhí)行SSL Task，完成后續(xù)可能耗時的操作或者任務，Netty封裝了一個任務立即執(zhí)行線程池專門處理SSL的代理任務，代碼如下：
如果是NEED_UNWRAP，則判斷是否由UNWRAP發(fā)起，如果不是則執(zhí)行UNWRAP操作。
如果是NOT_HANDSHAKING，則調用unwrap，繼續(xù)接收服務端的消息。
服務端應答消息的接收跟服務端接收客戶端的代碼類似，唯一不同之處在于SSL引擎的客戶端模式設置不同，一個是服務端，一個是客戶端。上層的代碼處理是相同的，下面我們在SSL服務端章節(jié)分析握手消息的接收。
3.2. SSL服務端
SSL服務端接收客戶端握手請求消息的入口方法是decode方法，下面對它進行詳細分析。
首先獲取接收緩沖區(qū)的讀寫索引，并對讀取的偏移量指針進行備份：
對半包標識進行判斷，如果上一個消息是半包消息，則判斷當前可讀的字節(jié)數(shù)是否小于整包消息的長度，如果小于整包長度，則說明本次讀取操作仍然沒有把SSL整包消息讀取完整，需要返回IO線程繼續(xù)讀取，代碼如下：
如果消息讀取完整，則修改偏移量：同時置位半包長度標識。
下面在for循環(huán)中讀取SSL消息，因為TCP存在拆包和粘包，因此一個ByteBuf可能包含多條完整的SSL消息。
首先判斷可讀的字節(jié)數(shù)是否小于協(xié)議消息頭長度，如果是則退出循環(huán)繼續(xù)由IO線程接收后續(xù)的報文：
獲取SSL消息包的報文長度，具體算法不再介紹，可以參考SSL的規(guī)范文檔進行解讀，代碼如下：
對長度進行判斷，如果SSL報文長度大于可讀的字節(jié)數(shù)，說明是個半包消息，將半包標識長度置位，返回IO線程繼續(xù)讀取后續(xù)的數(shù)據(jù)報，代碼如下：
對消息進行解碼，將SSL加密的消息解碼為加密前的原始數(shù)據(jù)，unwrap方法如下：
調用SSLEngine的unwrap方法對SSL原始消息進行解碼，對解碼結果進行判斷，如果越界，說明out緩沖區(qū)不夠，需要進行動態(tài)擴展。如果是首次越界，為了盡量節(jié)約內存，使用SSL最大緩沖區(qū)長度和SSL原始緩沖區(qū)可讀的字節(jié)數(shù)中較小的。如果再次發(fā)生緩沖區(qū)越界，說明擴張后的緩沖區(qū)仍然不夠用，直接使用SSL緩沖區(qū)的最大長度，保證下次解碼成功。
解碼成功之后，對SSL引擎的操作結果進行判斷：如果需要繼續(xù)接收數(shù)據(jù)，則繼續(xù)執(zhí)行解碼操作；如果需要發(fā)送握手消息，則調用wrapNonAppData發(fā)送握手消息；如果需要異步執(zhí)行SSL代理任務，則調用立即執(zhí)行線程池執(zhí)行代理任務；如果是握手成功，則設置SSL操作結果，發(fā)送SSL握手成功事件；如果是
應用層的業(yè)務數(shù)據(jù)，則繼續(xù)執(zhí)行解碼操作，其它操作結果，拋出操作類型異常。
需要指出的是，SSL客戶端和服務端接收對方SSL握手消息的代碼是相同的，那為什么SSL服務端和客戶端發(fā)送的握手消息不同呢？這些是SSL引擎負責區(qū)分和處理的，我們在創(chuàng)建SSL引擎的時候設置了客戶端模式，SSL引擎就是根據(jù)這個來進行區(qū)分的，代碼如下：
無論客戶端還是服務端，只需要圍繞SSL引擎的操作結果進行編程即可。
3.3. SSL消息讀取
SSL的消息讀取實際就是ByteToMessageDecoder將接收到的SSL加密后的報文解碼為原始報文，然后將整包消息投遞給后續(xù)的消息解碼器，對消息做二次解碼。基于SSL的消息解碼模型如下：
SSL消息讀取的入口都是decode，因為是非握手消息，它的處理非常簡單，就是循環(huán)調用引擎的unwrap方法，將SSL報文解碼為原始的報文，代碼如下：
握手成功之后的所有消息都是應用數(shù)據(jù)，因此它的操作結果為NOT_HANDSHAKING，遇到此標識之后繼續(xù)讀取消息，直到沒有可讀的字節(jié)，退出循環(huán)，代碼如下：
如果讀取到了可用的字節(jié)，則將讀取到的緩沖區(qū)加到輸出結果列表中，代碼如下：
ByteToMessageDecoder判斷解碼結果List，如果非空，則循環(huán)調用后續(xù)的Handler，由后續(xù)的解碼器對解密后的報文進行二次解碼。
3.4. SSL消息發(fā)送
SSL消息發(fā)送時，由SslHandler對消息進行編碼，編碼后的消息實際就是SSL加密后的消息，它的入口是flush方法，代碼如下：
從待加密的消息隊列中彈出消息，調用SSL引擎的wrap方法進行編碼，代碼如下：
wrap方法很簡單，就是調用SSL引擎的編碼方法，然后對寫索引進行修改，如果緩沖區(qū)越界，則動態(tài)擴展緩沖區(qū)：
對SSL操作結果進行判斷，因為已經握手成功，因此返回的結果是NOT_HANDSHAKING，執(zhí)行finishWrap方法，調用ChannelHandlerContext的write方法，將消息寫入發(fā)送緩沖區(qū)中，如果待發(fā)送的消息為空，則構造空的ByteBuf寫入：
編碼后，調用ChannelHandlerContext的flush方法消息發(fā)送給對方，代碼如下：
ctx.flush();
?
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
