【Web探秘】 使用HTTPS的意义所在、如何部署及延迟解决方案

       近日，与公司小伙伴在忙官网的Https协议的转变事宜，从中发现了很多价值所在，当然也暴露出了很多问题。利益嘛，最突出的莫过于安全性的提升（原来是裸奔即可访问，现在需要穿身像样的衣服才能进来，自然会过滤相当一部分访问动机不纯的不良份子）；至于影响吗，充当其冲的自然是访问速度大大延迟，应客户需求和公司内部人员的反馈，提升访问速度迫在眉睫，也一直在优化这块，下面就HTTPS这块给一些有打算转变和提升的你们分享下这段时间的心得与收获吧。

一、为何大家都向他靠拢

网上有一大堆名词性的解释太过复杂，把人都看晕了，我给大家分享个简单小故事吧来解释吧：

    有天，某猿接到客服妹子的反馈，说是有个用户反应在其官网下载的app是另家公司的产品。当时小猿天真的以为是自己公司网站的运营挂错了链接，怒气冲冲的与运营理论了一番，却发现链接没有问题，后来以为是用户自己下载错了，这件事也就过去了。但是，过了一段时间，公司内部人员在下载时发现了同样的事情！于是，内部开展深入调查，发现大概有20%左右的正常链接会被重定向到另一个链接。技术分析原因，应该是黑客在数据出口截取下载地址，并进行了替换。于是，公司采用了Https，以后就再未复现过此问题。
    其实，上面的小故事仅仅是危险的互联网中一个小小的事件，钓鱼网站、DNS劫持、DNS污染、网站篡改等等都无时无刻不在发生。为何看似平静的互联网会有如此多的风波？起因，是当时技术能力的限制，以及对人心的信任。由于Http只是基于TCP协议的字符串明文传输，在不可信任的网络中，这和裸奔没有任何区别，黑客用抓包软件可以轻易的看到网络上谁在访问哪个链接，这些琐碎的信息则会暴露用户的隐私。

明白了吧，HTTPS就是给你的网站加个官方认可的入场券和一个保安，用户访问的时候检查他的客户端环境是否带有官方认可的入场券，你有你进，没有请绕开。

二、实现机理所在及部署的关键步骤：

1、密文传输访问的资源：

从上图看，加密从客户端出来就已经是密文数据了，那么你的用户在任何网络链路上接入，即使被监听，黑客截获的数据都是密文数据，无法在现有条件下还原出原始数据信息。

2、TCP(Transmission Control Protocol 传输控制协议)的三次握手谈判：

Https在HTTP下加入SSL层（安全套接层）/TLS(TLS是SSL的升级协议)，HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行数次握手，在握手过程中将确立双方加密传输数据的密码信息。这样，Https就能保障数据在传输过程中不被非法篡改和利用重点内容

3、如何部署：

1、为服务器生成证书：（以appach tomcat服务器为例）：

运行”控制台，进入%JAVA_HOME%/bin目录，使用如下命令进入目录： cd “c:\Program
Files\Java\jdk1.6.0_11\bin”
使用keytool为Tomcat生成证书，假定目标机器的域名是“localhost”，keystore文件存放在“D:\home\tomcat.keystore”，口令为“password”，使用如下命令生成：
keytool -genkey -v -alias tomcat -keyalg RSA -keystore
D:\home\tomcat.keystore -validity 36500
(参数简要说明：“D:\home\tomcat.keystore”含义是将证书文件的保存路径，证书文件名称是tomcat.keystore

在命令行填写必要参数：
A、 输入keystore密码：此处需要输入大于6个字符的字符串。
B、 “您的名字与姓氏是什么？”这是必填项，并且必须是TOMCAT部署主机的域名或者IP[如：gbcom.com 或者
10.1.25.251]（就是你将来要在浏览器中输入的访问地址），否则浏览器会弹出警告窗口，提示用户证书与所在域不匹配。在本地做开发测试时，应填入“localhost”。
C、 你的组织单位名称是什么？”、“您的组织名称是什么？”、“您所在城市或区域名称是什么？”、“您所在的州或者省份名称是什么？”、“该单位的两字母国家代码是什么？”可以按照需要填写也可以不填写直接回车，在系统询问“正确吗？”时，对照输入信息，如果符合要求则使用键盘输入字母“y”，否则输入“n”重新填写上面的信息。
D、 输入的主密码，这项较为重要，会在tomcat配置文件中使用，建议输入与keystore的密码一致，设置其它密码也可以，完成上述输入后，直接回车则在你在第二步中定义的位置找到生成的文件。

2、为客户端生成证书：

为浏览器生成证书，以便让服务器来验证它。为了能将证书顺利导入至IE和Firefox，证书格式应该是PKCS12，因此，使用如下命令生成：
keytool -genkey -v -alias mykey -keyalg RSA -storetype PKCS12
-keystore D:\home\mykey.p12 （mykey为自定义）。 对应的证书库存放在“D:\home\mykey.p12”，客户端的CN可以是任意值。双击mykey.p12文件，即可将证书导入至浏览器（客户端）。

3、联系两个证书，让服务器信任客户端的证书：

由于是双向SSL认证，服务器必须要信任客户端证书，因此，必须把客户端证书添加为服务器的信任认证。由于不能直接将PKCS12格式的证书库导入，必须先把客户端证书导出为一个单独的CER文件，使用如下命令：
keytool -export -alias mykey -keystore D:\home\mykey.p12 -storetype
PKCS12 -storepass password -rfc -file D:\home\mykey.cer
(mykey为自定义与客户端定义的mykey要一致，password是你设置的密码)。通过以上命令，客户端证书就被我们导出到“D:\home\mykey.cer”文件了。
下一步，是将该文件导入到服务器的证书库，添加为一个信任证书使用命令如下：
keytool -import -v -file D:\home\mykey.cer -keystore D:\home\tomcat.keystore
通过list命令查看服务器的证书库，可以看到两个证书，一个是服务器证书，一个是受信任的客户端证书： keytool -list
-keystore D:\home\tomcat.keystore (tomcat为你设置服务器端的证书名)。

4、信任是相互的，让客户端信任服务器的证书：

由于是双向SSL认证，客户端也要验证服务器证书，因此，必须把服务器证书添加到浏览的“受信任的根证书颁发机构”。由于不能直接将keystore格式的证书库导入，必须先把服务器证书导出为一个单独的CER文件，使用如下命令：
keytool -keystore D:\home\tomcat.keystore -export -alias tomcat -file
D:\home\tomcat.cer (tomcat为你设置服务器端的证书名)。
通过以上命令，服务器证书就被我们导出到“D:\home\tomcat.cer”文件了。双击tomcat.cer文件，按照提示安装证书，将证书填入到“受信任的根证书颁发机构”。

5、配置服务器：

 打开Tomcat根目录下的/conf/server.xml，找到Connector port="8443"配置段，修改为如下：
> <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> SSLEnabled="true" maxThreads="150" scheme="https" secure="true"
> clientAuth="true" sslProtocol="TLS"
> keystoreFile="D:\\home\\tomcat.keystore" keystorePass="123456"
> truststoreFile="D:\\home\\tomcat.keystore" truststorePass="123456" />
> （tomcat要与生成的服务端证书名一致） 属性说明： clientAuth:设置是否双向验证，默认为false，设置为true代表双向验证
> keystoreFile:服务器证书文件路径 keystorePass:服务器证书密码
> truststoreFile:用来验证客户端证书的根证书，此例中就是服务器证书 truststorePass:根证书密码

6、测试是否部署成功

在浏览器中输入:https://localhost:8443/，会弹出选择客户端证书界面，点击“确定”，会进入tomcat主页，地址栏后会有“锁”图标，表示本次会话已经通过HTTPS双向验证，接下来的会话过程中所传输的信息都已经过SSL信息加密。

三、部署后访问有延迟的原因级解决方案

1、延迟原因：（拜访我家的访问要多走几道手续，能不慢吗）

Http使用TCP 三次握手即可建立连接，客户端和服务器需要交换3个包，但是Https除了 TCP 的三个包，还要加上
SSL握手需要的9个包，一共是12个包。那么实际SSL握手到底需要多长时间？目前有一些同时支持Http和Https的网站，以 localhost网站为测试范本，建立一个Http链接需要114毫秒，而https建立连接，则耗费436毫秒。也就是说Https比Http多花费322毫秒，其中大部分是SSL本身加解密的开销。为什么一个握手环节环节会有如此大的时间消耗？
我们来看看，在Https建立连接前的这300多毫秒中到底发生了什么？Https的握手环节中，首先当你的浏览器向服务器请求一个安全的网页(通常是 https://)，服务器就把它的证书和公匙发回来，浏览器检查证书是不是由可以信赖的机构颁发的，确认证书有效和此证书是此网站的。使用公钥加密了一个随机对称密钥，包括加密的URL一起发送到服务器，服务器用自己的私匙解密了你发送的钥匙。然后用这把对称加密的钥匙给你请求的URL链接解密。服务器用你发的对称钥匙给你请求的网页加密，你也有相同的钥匙就可以解密发回来的网页了。

2、解决方案：（单纯从配置层面解决不了的问题，那我就提高生产力，使用新工具）

2015年，Google I/O大会上，谷歌提出了在网络上使用“HTTPS everywhere”的倡导，目前在国内百度和淘宝已经实现了Https的全站覆盖，并且越来越多的网站开始使用Https协议来保障数据的安全，随着https的大行其道，这块很多公司在研究优化的方案。（比如使用加速卡，以及中间资源访问代理）

有很多公司推出了面向SSL加解密加速的软硬一体化解决方案。支持IPsec、SSL 加速和压缩功能，可提供高达，50 Gbps 的加密速度和高达 24 Gbps 的压缩性能，能让Https加解密效率提升十倍以上。（比如：浪潮推出了基于SA5212M4,专门面向SSL加解密加速的软硬一体化解决方案，支持IPsec、SSL 加速和压缩功能，可提供高达 50 Gbps 的加密速度和高达 24 Gbps 的压缩性能）

ps:小编也在寻找性价比更高的优化方式，设置免费的优化方案，如果有的话会及时在线共享出来，大家一起努力来助https一把力吧~~~