1. 背景
1.1. 严峻的安全形势
1.1.1. OpenSSL Heart bleed漏洞
2014年上半年对网络安全影响最大的问题就是OpenSSL Heart bleed漏洞,来自Codenomicon和谷歌安全部门的研究人员发现OpenSSL的源代码中存在一个漏洞,可以让攻击者获得服务器上64K内存中 的数据内容。该漏洞在国内被译为” OpenSSL心脏出血漏洞”,因其破坏性之大和影响的范围之广,堪称网络安全里程碑事件。
OpenSSL是为网络通信提供安全及数据完整性的一种安全协议,囊括了主要的密码算法、常用的密钥和证书封装管理功能以及SSL协议.多数SSL 加密网站是用名为OpenSSL的开源软件包,由于这也是互联网应用最广泛的安全传输方法,被网银、在线支付、电商网站、门户网站、电子邮件等重要网站广 泛使用,所以漏洞影响范围广大。
全球第一个被攻击通告的案例是加拿大税务局确认OpenSSL Heart bleed漏洞导致了900个纳税人的社会保障号被盗,这900个纳税人的社保号被攻击者在系统中完全删除了。
1.1.2. 安全漏洞的高成本
任何网络攻击都能够给企业造成破坏,但是如何将这些破坏具体量化成金融数据呢?2013年,B2B International联合卡巴斯基实验室基于对全球企业的调查结果,计算出网络攻击平均造成的损失。
根据调查报告得出的结论,当企业遭遇网络攻击后平均损失为649,000美元。损失主要包括两方面:
- 安全事件本身造成的损失,即由重要数据泄漏、业务连续性以及安全修复专家费用相关成本;
- 为列入计划的”响应”成本,用于阻止未来发生类似的攻击事件,包括雇佣、培训员工成本以及硬件、软件和其它基础设施安全升级成本。
1.2. Netty面临的安全风险
作为一个高性能的NIO通信框架,基于Netty的行业应用非常广泛,不同的行业、不同的应用场景,面临的安全挑战也不同,下面我们根据Netty的典型应用场景,分析下Netty面临的安全挑战。
1.2.1. 仅限内部使用的RPC通信框架
随着业务的发展,网站规模的扩大,传统基于MVC的垂直架构已经无法应对业务的快速发展。需要对数据和业务进行水平拆分,基于RPC的分布式服务框架成为最佳选择。
业务水平拆分之后,内部的各个模块需要进行高性能的通信,传统基于RMI和Hession的同步阻塞式通信已经无法满足性能和可靠性要求。因此,高性能的NIO框架成为构建分布式服务框架的基石。
网站的架构演进过程如下:
图1-1 网站的架构演进
高性能的RPC框架,各模块之间往往采用长连接通信,通过心跳检测保证链路的可靠性。由于RPC框架通常是在内部各模块之间使用,运行在授信的内部安全域中,不直接对外开放接口。因此,不需要做握手、黑白名单、SSL/TLS等,正所谓是“防君子不防小人”。
在这种应用场景下,Netty的安全性是依托企业的防火墙、安全加固操作系统等系统级安全来保障的,它自身并不需要再做额外的安全性保护工作。
1.2.2. 对第三方开放的通信框架
如果使用Netty做RPC框架或者私有协议栈,RPC框架面向非授信的第三方开放,例如将内部的一些能力通过服务对外开放出去,此时就需要进行安全认证,如果开放的是公网IP,对于安全性要求非常高的一些服务,例如在线支付、订购等,需要通过SSL/TLS进行通信。
它的原理图如下:
图1-2 对第三方开放的通信框架
对第三方开放的通信框架的接口调用存在三种场景:
- 在企业内网,开放给内部其它模块调用的服务,通常不需要进行安全认证和SSL/TLS传输;
- 在企业内网,被外部其它模块调用的服务,往往需要利用IP黑白名单、握手登陆等方式进行安全认证,认证通过之后双方使用普通的Socket进行通信,如果认证失败,则拒绝客户端连接;
- 开放给企业外部第三方应用访问的服务,往往需要监听公网IP(通常是防火墙的IP地址),由于对第三方服务调用者的监管存在诸多困难,或者无法有效监管,这些第三方应用实际是非授信的。为了有效应对安全风险,对于敏感的服务往往需要通过SSL/TLS进行安全传输。
1.2.3. 应用层协议的安全性
作为高性能、异步事件驱动的NIO框架,Netty非常适合构建上层的应用层协议,相关原理,如下图所示:
图1-3 基于Netty构建应用层协议
由于绝大多数应用层协议都是公有的,这意味着底层的Netty需要向上层提供通信层的安全传输,也就是需要支持SSL/TLS。
JDK的安全类库提供了javax.net.ssl.SSLSocket和javax.net.ssl.SSLServerSocket类库用于支持SSL/TLS安全传输,对于NIO非阻塞Socket通信,JDK并没有提供现成可用的类库简化用户开发。
Netty通过JDK的SSLEngine,以SslHandler的方式提供对SSL/TLS安全传输的支持,极大的简化了用户的开发工作量,降低开发难度。
对于Netty默认提供的HTTP协议,Netty利用SslHandler,同样支持HTTPS协议。
2. Netty SSL开发
2.1. SSL单向认证
单向认证,即客户端只验证服务端的合法性,服务端不验证客户端。下面我们通过Netty的SSL单向认证代码开发来掌握基于Netty的SSL单向认证。
2.1.1. SSL单向认证开发
首先,利用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链路初始化的时候,创建SSLContext并对其进行正确的初始化,下面我们对SSLContext的创建进行讲解:
因为是客户端认证服务端,因此服务端需要正确的设置和加载私钥仓库KeyStore,相关代码如下:
初始化KeyManagerFactory之后,创建SSLContext并初始化,代码如下:
由于是单向认证,服务端不需要验证客户端的合法性,因此,TrustManager为空,安全随机数不需要设置,使用JDK默认创建的即可。
服务端的SSLContext创建完成之后,利用SSLContext创建SSL引擎SSLEngine,设置SSLEngine为服务端模式,由于不需要对客户端进行认证,因此NeedClientAuth不需要额外设置,使用默认值False。相关代码如下:
SSL服务端创建完成之后,下面继续看客户端的创建,它的原理同服务端类似,也是在初始化TCP链路的时候创建并设置SSLEngine,代码如下:
由于是客户端认证服务端,因此,客户端只需要加载存放服务端CA的证书仓库即可。
加载证书仓库完成之后,初始化SSLContext,代码如下:对于客户端只需要设置信任证书TrustManager。
客户端SSLContext初始化完成之后,创建SSLEngine并将其设置为客户端工作模式,代码如下:
将SslHandler添加到pipeline中,利用SslHandler实现Socket安全传输,代码如下: