SSL原理及Java实现

Https 实际上是两种协议的组合

 

Https = Http + SSL

 

SSL原理

1 首先利用不对称算法握手,交换一个对称的密钥

2 然后利用这个对称的密钥进行通信

 

原理:
要想保证网络通信的安全,我们第一反应就是给传输的数据加密,这也是现行安全传输通用的模式。但在传统加密方式(单密钥,对称加密)下,密钥不可避免的要 被传送于网络节点之间,(除非是写死到各个节点中,不过那样就没有任何灵活性和普适性),在一定强度的网络攻击下,这种加密方式是很脆弱的。
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,是否与信任域中证书记载的一致;不符合其中任何一项,通信都会被拒绝。但反过来,响应方是不对请求方做任何验证的。 所以有些需要双向验证的服务(比如某些服务只能对特定的拥有证书的用户开放),就需要添加客户端证书,由服务端来验证了,原理和实现与默认模式类似。

 

参考:

http://zh.wikipedia.org/zh-cn/HTTPS

http://leo-dream.javaeye.com/blog/313592

展开阅读全文

没有更多推荐了,返回首页