1、HTTPS 原理与实践迅猛发展的互联网为我们提供了丰富的信息资源，在带来便利的同时也影响着人们工作和生活方式。大多数的互联网应用都是基于 http（超文本传输协议 ） ，我司原先开发的互联网应用也基本上是基于 http 的。但是随着商务百事通，口岸服务集成平台等项目的开展，在涉及资金交易，企业机密的网络传输中，安全性变得尤为重要。基于明文传输的 http 协议已无法满足这类项目的需要，因此我们在这些项目中也逐步采用了安全的 http 协议，即https.著名的 TCP/IP 五层模型分为：应用层，传输层，网络层，数据链路层，物理层。http位与最顶层的应用层，它直接放置与 TCP(传输层)协议
2、之上。而 https 则在 http 和 tcp 中间加上一层加密层(SSL)。从发送端看，SSL 负责把 http 的内容加密后送到下层的 TCP，从接收方看，这一层负责将 TCP 送来的数据解密还原成 http 的内容。 （如图一）图一既然 SSL 层如此重要，那么我们来看看 SSL 层是如何完成加解密通讯的。SSL 层加解密通讯主要原理是：1. 通过握手过程协商客户端和服务器端的加密算法和对称密钥。2. 通过协商达成的加密算法和对称密钥进行内容的加密传输。因为加密传输比较好理解，这里着重介绍一下 SSL 的握手过程：3. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器；
3、4. 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识；服务器同时还提供了一个用作产生密钥的随机数；5. 客户端对服务器的证书进行验证，并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串（用于内容加密的对称密钥） ，并使用服务器的公用密钥对其进行加密( 参考 非对称加/解密)，并将加密后的信息发送给服务器；6. 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC 密钥(参考 DH 密钥交换算法) 。7. 客户端将所有
4、握手消息的 MAC 值发送给服务器；8. 服务器将所有握手消息的 MAC 值发送给客户端。了解完 https 的原理，那么接下来我们动手做个例子吧：第一步：为服务器生成证书使用 keytool 为 Tomcat 生成证书，假定目标机器的域名是“zhenggm”，keystore 文件存放在“C:tomcat.keystore”，口令为“testssl” ，使用如下命令生成：C:keytool -genkeypair -v -alias tomcat -keyalg RSA -keystore c:tomcat.keystore -dname “CN=zhenggm,OU=eport,O=zje
5、port,L=hz,ST=zj,C=cn“ -storepass testssl -keypass testssl -validity 36000其中的参数可以具体查 keytool 命令。第二步：配置 Tomcat 服务器打开 Tomcat 根目录下的/conf/server.xml，找到如下配置段，修改如下：其中，clientAuth 指定是否需要验证客户端证书，如果该设置为“false”，则为单向 SSL 验证，SSL 配置可到此结束。如果 clientAuth 设置为“true” ，表示强制双向 SSL 验证，必须验证客户端证书。如果 clientAuth 设置为“want”，则表示可
6、以验证客户端证书，但如果客户端没有有效证书，也不强制验证。至此单向 SSL 验证服务器搭建完成。打开浏览器进行访问：浏览器对服务器发送的安全证书进行验证时，发现这个证书不是国际公认的第三方机构所签发的，所以浏览器报证书问题。我们只要点继续浏览此网站，即可进入以下页面。现在互联网涉及安全传输大多数是采用这种单向的 SSL 验证，因为双向验证需要客户端也有证书，对于面向不特定的互联网用户，实际操作起来还是有些困难的。双向 SSL 验证其实也不复杂，在原理上就是客户端向服务器发送 pre_master_secret 的时候，顺便将自己的证书也发过去，服务器端验证这个证书的合法性。在配置上增加以下步骤：第三步：为客户端生成证书第四步：将客户端证书导入服务器端证书库第五步：将客户端证书导入客户端（IE 等）第六步：将 tomcat 的配置改为 clientAuth=“true“因为篇幅关系，这里不进行详细介绍。另外，值得注意的是，采用 https 之后，服务器压力大概是采用 http 协议的 5 倍， 所以在安全性要求不高的传输中，尽量不要采用 https 协议，以免造成性能压力。
