HTTPS原理与实践

来源:互联网

迅猛发展的互联网为我们提供了丰富的信息资源,在带来便利的同时也影响着人们工作和生活方式。大多数的互联网应用都是基于http(超文本传输协议),我司原先开发的互联网应用也基本上是基于http的。但是随着商务百事通,口岸服务集成平台等项目的开展,在涉及资金交易,企业机密的网络传输中,安全性变得尤为重要。基于明文传输的http协议已无法满足这类项目的需要,因此我们在这些项目中也逐步采用了安全的http协议,即https.

著名的TCP/IP五层模型分为:应用层,传输层,网络层,数据链路层,物理层。http位与最顶层的应用层,它直接放置与TCP(传输层)协议之上。而https则在http和tcp中间加上一层加密层(SSL)。从发送端看,SSL负责把http的内容加密后送到下层的TCP,从接收方看,这一层负责将TCP送来的数据解密还原成http的内容。(如图一)

wps_clip_image-4909[3][1]

图一

既然SSL层如此重要,那么我们来看看SSL层是如何完成加解密通讯的。SSL层加解密通讯主要原理是:

1. 通过握手过程协商客户端和服务器端的加密算法和对称密钥。

2. 通过协商达成的加密算法和对称密钥进行内容的加密传输。

因为加密传输比较好理解,这里着重介绍一下SSL的握手过程:

3. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器;

4. 服务器从算法列表中选择一种加密算法,并将它和一份包含服务器公用密钥的证书发送给客户端;该证书还包含了用于认证目的的服务器标识;服务器同时还提供了一个用作产生密钥的随机数;

5. 客户端对服务器的证书进行验证,并抽取服务器的公用密钥;然后,再产生一个称作pre_master_secret的随机密码串(用于内容加密的对称密钥),并使用服务器的公用密钥对其进行加密(参考非对称加/解密),并将加密后的信息发送给服务器;

6. 客户端与服务器端根据pre_master_secret以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。

7. 客户端将所有握手消息的MAC值发送给服务器;

8. 服务器将所有握手消息的MAC值发送给客户端。

wps_clip_image-9479[3][1]

了解完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=zjeport,L=hz,ST=zj,C=cn" -storepass testssl -keypass testssl -validity 36000

wps_clip_image-53[3][1]

其中的参数可以具体查keytool命令。

第二步:配置Tomcat服务器

打开Tomcat根目录下的/conf/server.xml,找到如下配置段,修改如下:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

    maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="C:/tomcat.keystore" keystorePass="testssl"/>

其中,clientAuth指定是否需要验证客户端证书,如果该设置为“false”,则为单向SSL验证,SSL配置可到此结束。如果clientAuth设置为“true”,表示强制双向SSL验证,必须验证客户端证书。如果clientAuth设置为“want”,则表示可以验证客户端证书,但如果客户端没有有效证书,也不强制验证。

至此单向SSL验证服务器搭建完成。打开浏览器进行访问:

wps_clip_image-14055[3][1]

浏览器对服务器发送的安全证书进行验证时,发现这个证书不是国际公认的第三方机构所签发的,所以浏览器报证书问题。我们只要点[继续浏览此网站],即可进入以下页面。

wps_clip_image-2764[3][1]

现在互联网涉及安全传输大多数是采用这种单向的SSL验证,因为双向验证需要客户端也有证书,对于面向不特定的互联网用户,实际操作起来还是有些困难的。

双向SSL验证其实也不复杂,在原理上就是客户端向服务器发送pre_master_secret的时候,顺便将自己的证书也发过去,服务器端验证这个证书的合法性。

在配置上增加以下步骤:

第三步:为客户端生成证书

第四步:将客户端证书导入服务器端证书库

第五步:将客户端证书导入客户端(IE等)

第六步:将tomcat的配置改为 clientAuth="true"

因为篇幅关系,这里不进行详细介绍。

另外,值得注意的是,采用https之后,服务器压力大概是采用http协议的5倍, 所以在安全性要求不高的传输中,尽量不要采用https协议,以免造成性能压力。

发表评论