SSL原理及Java实现

た入场券 2022-07-16 14:46 372阅读 0赞

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