安全科普：HTTPS初探

* 本文作者：HPT @Dragon团队，本文属FreeBuf原创奖励计划，未经许可禁止转载

本篇主要为大家带来的是HTTPS的内容，相信大家已经从各种途径看过不少关于HTTPS的精彩内容，在下在这里只是抱着一颗菜鸟学习的心跟大神们交流一下，也希望能够给和我一样水平的人一点馈赠。

在追求安全的道路上，有很多美好的风景，那下面就让我带你看看我眼中的HTTPS吧，看看你是否和我理解的一样呢！

当今互联网，基于B/S架构的应用大部分都运用了HTTPS这个技术，其主要目的就是保护数据在传输过程中的隐私，在传输过程中是无法窥探到传输的明文数据的，但是事无绝对，想要攻击基于HTTPS传输的通信也不是没有可能。

（网上的例子有很多，最近BLACKHAT大会上的两位研究员也研究出了很炫的攻击手段；但是，本人也还没把这个技术手段研究透，不敢在大神们面前献丑）

本篇主要讲述HTTPS的安全性以及怎么达到这种安全性的细节，关于HTTPS中的密码学知识、证书知识暂时会一带而过，因为这又将是一个非常大的话题，不是一句两句话能讲清楚的哦！

下面主要带着以下四个疑虑去认识HTTPS：

1. HTTPS和HTTP的关系 2. HTTPS为什么比HTTP安全呢 3. HTTPS在实际生活中的运用 4. 本地化测试HTTPS和HTTP在传输过程中的现象

1. HTTPS和HTTP的关系

HTTP全称是超文本传输协议，基于网络7层模型中的最上层的应用层协议，而HTTPS则是一种加密的超文本传输协议，它和HTTP在协议的本质上是一样的，多了一个“S”。

差异就在于对于数据在传输数据的过程中，HTTPS对数据做了完全加密，他两都是处于TCP传输层之上的，废话不多说，先看几张图来认识下HTTP和HTTPS吧：

HTTP请求：

图1

HTTP数据包：

图2

HTTPS请求：

图3

HTTPS数据包：

图4

从上面的4张图，大家可以看到HTTP与HTTPS大概的区别了吧，首先从请求上来说，一个是HTTP请求，能看到请求的报头；而另外一个就是SSL/TLS请求，没有任何信息；在数据包中也可以显而易见这个区别，HTTP数据包是完全裸露的，你可以看到任何信息，而HTTPS数据包只是二进制加密后的数据，看不到任何有用信息。

2. HTTPS为什么比HTTP安全呢

上面的步骤已经向大家证明了HTTPS相比于HTTP的安全性，那么接下来仔细分析下到底为什么会这样，带着这个疑问继续往下看。

HTTPS之所以能够对传输的数据进行加密，主要是在TCP协议层和HTTP协议层中间架起了一层SSL/TSL协议层，这一层能够把在网络中传输的数据进行有效的加密。

SSL（Security Socket Layer）这一层能够保持数据的安全，主要依赖证书检测、非对称加密、对称加密、数据完整性校验以及随机数这5个密码学的基础知识，从而构建出一个完整可信的传输链。

其实说到这里，大家心中的疑惑应该跟我是一样的，用了这些加密算法又怎么样呢，为什么一定是安全的呢，我也可以在传输的过程中对数据进行自行加密呀，用最高深的加密方法不就行了吗？不要急，且行且看，下面这张图是基于SSL协议的五层网络模型图，

图5 SSL协议网络模型图

图5中在原来的五层模型中嵌入了SSL/TSL层，用来为传输中的数据进行加密的服务，从这张图上可以看出，当数据从HTTP层往下流的时候经过SSL层的加密服务。

然后再把数据组合到TCP层进而传输，而当数据从另一端的TCP层向上流的时候，将加密后的数据往上交付，SSL层会为其解密，然后再交付给HTTP层。

概括的讲，就是一个端到端的加、解密流程而已，图6通过剖析SSL的工作机制就会向你解释这种安全性的原因与细节，

图6 SSL工作机制

步骤 1. Client Hello – 客户端发送所支持的 SSL/TLS 最高协议版本号、所支持的加密算法集合及压缩方法集合和随机数A等信息给服务器端。 步骤 2. Server Hello – 服务器端收到客户端信息后，选定双方都能够支持的 SSL/TLS 协议版本和加密方法及压缩方法、 随机数B和服务器证书返回给客户端。 步骤 3. 客户端主动再生成一个随机数C，开始生成秘钥，这个生成秘钥的算法是客户端跟服务器端共享的，因为之前协商的时候已经确定了算法了，生成秘钥后就可以加密一段内容，试着跟服务区通信了。 这个内容是经过先散列，散列后将原内容和散列集一起用刚才的密钥加密；接着用服务器端证书中的公钥对随机数C加密。 步骤 4. 然后把加密过的内容和加密好的随机数一起发向服务器端。 步骤 5. 服务器用私钥解密得到随机数C，这样服务器端也同时拥有了随机数A、B、C，即刻生成密钥，再用密钥对加密的内容进行解密，然后解开后对其中的明文内容进行散列，与客户端发过来的散列值进行比较，如果相等，说明就是客户端发过来的，通信成功。 步骤 6. 用步骤3中同样的方式发一段加密过的内容给客户端。 步骤 7. 用步骤5一样的方式对服务器发来的内容进行验证。 步骤 8. 客户端确定开始通信。 步骤 9. 服务端确定开始通信。

3. HTTPS在实际生活中的运用

本人是非常喜欢购物的，那么我们就以大家经常购物的“淘宝”网为例，来看下淘宝采用的HTTPS协议是怎样的呢？

图7

好了，现在来分析下淘宝的数据传输的一个简单的验证机制吧，就拿图7中红圈圈出来的部分来说明，第一条“Client Hello”的这条消息，我们看到是从本地发往一个IP为140.205.174.1的请求，那么这个140.205.174.1通过验证，证明就是淘宝的一台服务器而已，这条消息表明本机正在向淘宝网发起一个请求。

于是淘宝网回应了一个“Server Hello”的消息，看到回复的IP地址是140.205.248.253，怎么不是140.205.174.1呢?

很容易可以回答你，淘宝每天有那么多的请求量，不可能所有数据都是放在一个服务器吧，可以想一想负载均衡、安全性方面的思路，那这里140.205.248.253就是淘宝的另外一台服务器咯。

它不仅回复了“Server Hello”，而且向你发送一些其他信息，我们可以展开编号为215的这条数据包来看一下，如图8，

图8

从图8中你可以看到，服务器告诉客户端，我支持的TLS的协议版本是1.2同时也传过来一个随机数并且选择了算法TLS_RSA_WITH_AES_128_GCM_SHA256，好了接下来可以看到编号为216的数据包。

传递的信息跟前面是一样的，这里承认网络学的不够好，也不知道是啥原因，猜测是TCP的可靠性连接导致的重传，只是猜测哦，未证实，如果有大牛明白的，还望解答。

看到这里，不知道你是否跟我有一个一样的疑问，在前面的SSL协议的分析中不是说好了服务端要传递证书过来给客户端做验证的吗，怎么证书连个影都没有呢？如果你能想到这个，说明前面的知识消化了，看下图9,

图9

图9中可以看到红圈圈出来的，一个“Client Hello”消息的数据包，一个似曾相识的IP地址140.205.248.25又出现了，想都不用想，这又是阿里的另外一台服务器了，接着你看到编号为195的数据包，你就恍然大悟了，原来Certificate，也就是传说中的证书在这里呀，于是可以展开这个数据包，图10所示，

图10

正如图10所示，当你展开数据包的时候，你已经看到了Alibaba这几个关键的字母，不错，这就是淘宝的证书信息，这下就解决了上面的疑问，为什么在上面刚才的那段通信中，服务端没有向本地发送证书信息呢。

就是因为在这之前已经发送过证书进行验证了，所以就不再需要了，但是还是有个问题，细心的你可以发现编号为195的数据包是IP为124.14.2.241这个主机返回过来的。

通过查证，这不是淘宝服务器的地址呀，为何是由它来发送过来呢，这个问题同样，在这里还是无法正确地回答你，网络学的不好只能默默哭泣了，还是希望大牛能够告知呀。

好啦，讲到这里，我的基本目的也已经达到了，不管怎么样，我们都亲眼见识了下淘宝是怎么玩HTTPS这个好东西的，其中还是有不少疑问的，除了刚才那两个网络问题之外，其实回过头还是可以仔细对照数据包的分发流程与顺序来思考下为何是这样的一个过程？

如果是我自己搭建服务器，也是同样的过程吗？“革命尚未成功，同志仍需努力”呀！

4. 本地化测试HTTPS和HTTP在传输过程中的现象

好了，通过前面3个部分的了解，对HTTPS应该有了一个还算不错的认识吧，那么现在就差最后一步了，HTTPS传输过程中的数据是看不到的，除非你有密钥，要不你是绝对不可能将密文变成明文的；

是的，别人网站的是看不到，但是为了获得一定的成就感、虚荣心，我们何不自己搭建一个小的web系统来测试下HTTPS，相信大家也知道了，我一直用的是WIRESHARK来抓取数据包的，下面的解密数据包也还是会用这个工具来做，开始啦！

下面首先我们要搭建一个符合我们测试标准的系统，在这里不会详细讲搭建系统的步骤及详情，这不是本文的重点，网上例子很多，下面就会以我本地搭建的一个小型Web网站为例（Tomcat7、JDK7、OpenSSL0.9.8）。

当一切都配置完成后，以HTTPS的方式来访问下本地的这个网站，图11所示，

图11

这里会有个红叉叉，是因为这个HTTPS的证书是自己生成的，并没有权威机构（CA）的授权、认证，所以是属于不安全的范畴的。

下面就用对其进行抓包，这里要注意了，如果是用WIRESHARK进行本地抓包，是要手动建立一条本地路由的，否则它是默认不会抓取本地的数据包的，在WINDOW下可以用以下命令：

这个192.168.5.118就是你的本地局域网IP地址，255.255.255.255这个掩码是固定值，而192.168.5.1就是你的IP地址对应的网关地址。

下面开始抓包。如图12所示，

图12

很显然，数据全部被加密了，什么都看不到了，接下来用我们自己生成的秘钥来解包吧！具体在WIRESHARK中配置SSL的解密密钥的步骤这里不会详细讲。当配置好秘钥后，再次用WIRESHARK抓包，就会出现图13的效果，

图13

可以看到，用密钥解密数据包后，HTTP所有的报头都是可以获取到的。这里关于用密钥解密数据包的时候会有一个比较棘手的问题，就是关于服务端选取算法套的问题，详细地解释下这个问题，当时也是被困扰了好久的。

客户端首先会与服务端协商，服务端会把自己的决定告诉客户端，这个过程如图14所示，

图14

图14描述的是客户端发送请求到服务器端，同时客户端会把自己支持的算法全部发给服务器，又服务器来选择使用什么算法进行后续的通信加密数据，看图15，

图15

于是，你可以从图15中看到，服务器端选择的是TLS_RSA_WITH_AES_128_CBC_SHA这个算法，这个算法就是经典的非对称加密RSA与对称加密AES128 CBC模式相结合的加密算法套，SHA是一个散列算法，主要用来防止数据被篡改。

那么为什么服务器会选择这个算法呢，这是可控的吗？回答是：可控的，就在服务端的配置文件中配置的一个算法支持序列，如图 16（以Tomcat为例），

图16

这是在Tomcat的Server.xml文件中配置HTTPS服务的时候所选取的算法套件，一旦配置完成后，以后服务器就会从这些可选的并且客户端中存在的算法中选择，这些都没什么，但是如果你在服务不配置ciphers这个属性的话，问题就来了。

服务端默认采取的算法就会是，图17中的这个，

图17

图17的这个算法TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA算法是基于“Diffie-Hellman”的一个算法，这种方法是一种协商式秘钥生成算法，是由服务端和客户端自动自己协商生成的一种算法，所以并不能用我们自己生成的秘钥来解密，因此这种情况下，是无法解密HTTPS数据包的。

至于具体的算法特性以及实现不在这里具体讲述，有兴趣的可以自己去查阅，目前我也还未尝试过解密这种算法加密的数据，只能贡献给大家这些了。

* 本文作者：HPT @Dragon团队，本文属FreeBuf原创奖励计划，未经许可禁止转载