ssl的原理以及在tomcat上的部署

zsyzhou

　　转自http://leo-dream.javaeye.com/blog/313592
　　原理：
要想保证网络通信的安全，我们第一反应就是给传输的数据加密，这也是现行安全传输通用的模式。但在传统加密方式(单密钥，对称加密)下，密钥不可避免的要被传送于网络节点之间，(除非是写死到各个节点中,不过那样就没有任何灵活性和普适性)，在一定强度的网络攻击下，这种加密方式是很脆弱的。
SSL 的出现解决了这个难题，理解SSL 的关键是理解非对称加密的含义。
在对称加密的情况下，源数据A，通过使用密钥B，加密成为密文C。任何人，只要获得了密钥B，就能够对截获的密文C解密，还原出源数据A。(依靠"算法安全"远不如依靠"密钥安全")；在非对称加密中，出现了“密钥对”的概念，即有一个公共密钥(公钥)和一个私有密钥(私钥)，经公钥加密的密文只能由私钥解密，反过来，经私钥加密的密文只能由公钥解密。这是个重要的特性(数学原理可参考RSA算法)，下面的模拟https通信流程说明了这一特性的重要。
1，客户端向服务端发出请求，服务端将公钥(以及服务端证书)响应给客户端；
2，客户端接收到服务器端端公钥与证书，验证证书是否在信任域内，不信任则结束通信，信任则使用服务端传过来的公钥生成一个“预备主密码”，返回给服务端。
3，服务端接收客户端传过来的“预备主密码”密文，使用私钥解密。非对称加密的安全性也就在于此了，第三方无法获取到“预备主密码”的明文，因为除了服务端，其他任何人是没有私钥的。
4，双方使用“预备主密码”生成用于会话的“主密码”。确认后，结束本次SSL 握手，停止使用非对称加密。
5，双方使用“主密码”对称加密传输数据，直到本次会话结束。
总结整个流程：先采用非对称加密模式，保证“主密码”只被通信双方获知，而后使用传统的对称加密方式通信，这样，保证了密钥安全(即“主密码”)就等于保证了数据安全。之所以建立安全连接后，转而使用对称加密，是因为非对称加密的运算量很大，用于“常态”的数据通信十分低效。
以上描述的仅是SSL 协议中加密通信的原理，没有涉及到证书验证，以及客户端，服务端模式。
实现： JDK里面自带了一个密钥生成工具keytool，可以通过它生成SSL 通信需要的密钥对，或者生成自签名的证书。所有密钥对或者签名证书都是存放在“keystore”密钥仓库中，由它来管理。
下面结合具体例子说明：(java  WEB容器:tomcat 5.0)
1，生成服务端密钥仓库，
keytool -genkey -alias svrkey -keyalg RSA -keystore d:\svr.jks -validity 365
"alias"是生成的密钥别名，密钥的导入导出都需要由别名来定位。
"keystore"生成的密钥仓库
"validity"生成密钥仓库的有效期(天)
随后会要求输入密钥仓库入口密码,比如: lostsky_11
输完密码后，接着会要求一系列的输入，无非是单位，所在地区之类的信息，
但是第一项很重要！为输入服务端域名或IP，如: 192.168.1.3或www.591pic.com
必须与服务器域名或IP相同，否则SSL 连接无法建立(这也是SSL 通信验证的一部分)
2，在tomcat_home/conf/server.xml中配置:
找到ssl 通信配置那一段，加入：
keystoreFile="d:\svr.jks" keystorePass="lostsky_11"
服务器启动时会从中寻找用于建立ssl 连接的密钥
3，导出服务端证书
keytool -export -alias svrkey -file d:\svr.cer -keystore d:\svr.jks
"alias"为想导出的密钥的别名，"file"为导出的证书，"keystore"为存储着导出密钥的仓库
4，生成客户端密钥仓库
keytool -genkey -alias clientkey -keyalg RSA -keystore d:\client.jks
会要求输入仓库密码：如：midsky
5，将服务端证书导入到客户端密钥仓库
keytool -import -file d:\svr.cer -keystore d:\client.jks
会要求输入客户端密钥仓库的密码：如上是：midsky
这样服务端的密钥仓库就在tomcat部署完毕了，
6，在客户端，每次访问服务端之前，加入
"System.setProperty("javax.net.ssl .trustStore","d:\\client.jks");
System.setProperty("javax.net.ssl .trustStorePassword","midsky"); "
就把服务端证书添加到了客户端的信任域中，能够完成ssl 通信。
注：ssl 通信主要验证三个方面：
a, 证书是否可信(第6步)
b, 证书是否过期(第1步:validity)
c, 证书地址是否和当前访问地址符合(第1步)
客户端添加信任域还有编程的动态方法，但是那样会降低通信的安全性，对于证书相对固定的服务，不建议使用。
以上是客户端对于服务端的验证，这也是SSL 默认的实现方式。在这种方式下，每次通信时，发起请求方(如PC中的BROWSER)都会验证响应方(如某个WEB服务端)的证书是否在己方信任域中，对方的证书是否过期，对方的域名或IP，是否与信任域中证书记载的一致；不符合其中任何一项，通信都会被拒绝。但反过来，响应方是不对请求方做任何验证的。所以有些需要双向验证的服务(比如某些服务只能对特定的拥有证书的用户开放)，就需要添加客户端证书，由服务端来验证了，原理和实现与默认模式类似。