https实践之 抓包分析流程

概述：

     本文主要研究HTTPS协议的流程，通过抓包分析握手过程，主要将围绕HTTPS优化进行展开。

探究：

1、WHAT

     什么是HTTPS,这个百度应该就有一大堆了，不做详细描述，它是互联网安全的基础之一，工作在传输层之上，使用的加密协议为TLS/SSL,

具体分为以下几个版本，  截止目前  SSL/TLS  协议族中有7种协议（网上有）：  

• SSL v1 从未正式公开。

• SSL v2 协议设计有缺陷，不安全。

• SSL v3 老旧过时，缺乏一些新的密钥特性。

• TLS v1.0 在很大程度上是安全的，至少没有曝光重大的安全漏洞。

• TLS v1.1 和 TLS v1.2 目前都没有著名的安全漏洞曝光。

• TLS v1.3 仍然在草案阶段，而且有待时间检验。

2、HOW

     如何配置最简单的https服务，这里以nginx举例。

a、创建服务器私钥并去除口令：     

openssl genrsa -des3 -out server.key 1024

openssl rsa -in server.key -out server.key

b、创建签名请求的证书（CSR）,这个是给CA机构审核用的,这里我们自己审核生成CRT证书：     

            openssl req -new -key server.key -out server.csr

d、最后 使用上述私钥和CSR  标记证书：      

            openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

          e、配置nginx，在server块中开启 ssl，然后设置好证书和秘钥的地址即可。

            ssl on;  #开启

            ssl_certificate ssl/server.crt;  #证书，包含公钥

            ssl_certificate_key ssl/server.key; #秘钥

3、WHY

     整个SSL协议栈包括了三种类型的协议：

• • 握手协议：用于协商 SSL 密钥
  • 记录协议：用于记录 SSL 会话相关信息
  • 警报协议：用于通知对端停止 SSL 会话

     先来看看握手过程：

              

     

               以上图描述了 SSL握手的过程，主要分为以下几个部分   

• • • • client hello
      • server hello
      • client key exchange
      • change cipher spec

               前两个过程生成了 非对称加密的重要参数，创建了非对称秘钥，后两个过程创建了对称加密秘钥。

               接下来用wiresharke抓包，这里抓的是本地的请求数据。

               

               TCP先进行三次握手流程：

                    第一步：客户端(192.168.194.1)发送SYN包，seq为0，不携带数据

                    

               第二步 ：服务器端(192.168.194.132)返回SYN+ACK,不携带数据

                    

                    

               第三步： 客户端返回ACK，这里省略不在分析，就是把ACK位设置为了1, 至此TCP连接就已经建立了.

          

          接下来会建立SSL连接，下面继续分析SSL连接连接过程：

                第一步： 客户端发送 Client Hello数据包。具体抓包内容可以看到client hello握手协议的内容，稍后再根据这些内容研究优化HTTPS性能。

               

               

        主要内容：

支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本; 我这里因为使用的最新的谷歌浏览器，所以

支持的协议最高版本是TLS 1.2

客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：

认证算法 Au (身份验证)、

密钥交换算法 KeyExchange(密钥协商)、

对称加密算法 Enc (信息加密)、

信息摘要 Mac(完整性校验);

支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;

随机数 random_C，用于后续的密钥的生成;

扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。

。然后服务器端会返回一个ACK确认包。(2次RTT)；

            第二步：服务端返回ServerHello数据包。

          server hello

     a、server hello 主要确定了服务器端选择的版本，产生的随机字符串(用于生成对称秘钥), 使用的加密套件，压缩算法等。

     b、证书，即包含了服务器端信息的公钥。我这个证书的长度是587个字节，客户端会验证这个证书的身份

     c、server key exchange 这一步主要是根据前面选择的加密套件中的 对称秘钥交换算法来的。涉及到使用DH算法通过两个随机数RANDOM_C计算秘钥的问题。

     d、sever hello done   标记给客户端我发送完毕

这一步主要是服务器端发送证书，生成对称秘钥（1次RTT）

           第三步：客户端收到server hello以后,发送 client key exchange 等给服务器端,  注意这里标识了ACK，减少了一次RTT

这一步同样也是根据服务端选择的加密套件中的交换算法决定的 等（1次RTT）

                第四步： 客户端返回ACK以及会话的ticket  

这一步主要是

1、建立了ticket(类似于cookie,方便对称加密复用 见下方详解)

2、客户端通知服务器端，修改了加密方法，

3、之后就可以是用对称秘钥加解密通行了（1次RTT）

               

总结：以上就是HTTPS首次建立连接的大体过程，当然还包括了一些复杂的扩展选项。

PS：

难点一：关于server hello中的server key exchange 和 第三步中的客户端响应client key exchange

这个是客户端和服务器端交换秘钥的算法，不同的加密使用的是不同的算法， 比如这里（server hello），服务器选择了

使用 

，这个加密套件中包含的 秘钥交换算法为 DH算法，还有其他的秘钥交换算法，比如直接通过生成的公秘钥进行加密发送。

     a、公秘钥交换秘钥

          使用服务器的公钥对premaster进行加密，发送给服务器端，服务器端通过私钥解密，最后双方根据premaster和相互生成的随机字符串确定一个对称秘钥。

     b、DH秘钥交换算法 （这里使用的加密套件就是使用这种交换算法）

           how： 迪菲－赫尔曼密钥交换（Diffie–Hellman key exchange，简称“D–H”） 是一种安全协议。

它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。

           what： 它的使用是封装在加密套件中的，协商加密使用的交换算法不需要我们介入。

           why ：

假如用户 A和用户 B希望交换一个密钥。

取素数 p和整数 a， a是 p的一个原根，公开 a和p 。

A选择随机数 XA < p，并计算 YA= a^ XA mod p。

B选择随机数 XB < p，并计算 YB= a^ XB mod p。

每一方都将 X保密而将 Y公开让另一方得到。

A计算密钥的方式是： K=(YB) ^XA mod p

          B计算密钥的方式是：K=(YA) ^XB mod p

上面是相关算法的实现，同样我们来看看server key exchange包中的DH参数和 client key exchange中的参数：

有一个参数 pubkey， 还有一个是为了防止参数被篡改增加的签名

同样有一个参数 pubkey

这里的算法稍微有点复杂，在下一篇文章中具体介绍。 大家只要记住这里有一个Client random, server random, server pub ,client pub的交换就行了。

难点二：会话中建立的session ID和ticket

    HTTPS的过程是在TCP三次握手之后会进行SSL的四次握手，如果一个业务请求包含多条的加密流，反复的握手请求势必会导致较高的延迟。SSL的设计者们在尽量减少握手次数方面也是做了一定的考虑的。具体就是Session ID和Session ticket的应用。本文主要就Session ticket方法结合具体应用做一次简单的分析。

       流关联的一种形式是Session ID，可以去了解一下原理。而本文所述的Sessionticket，是流关联的另外一种应用场景。

       无论是Session ID还是Session ticket都是为了复用已有的加密参数，诸如秘钥以及加密 算法等，进而减少SSL的握手次数，目的是提高有效数据的响应效率。

       Session ID的思想就是服务器端为每一次的会话生成并记录一个ID号并发送给客户端，在重新连接的时候（多次短连接场景），客户端向服务器发送该ID号，服务器查找自己的会话记录，匹配之后，重用之前的加密参数信息。

       而Sessionticket的思想类似于cookie，是由服务器将ticket 数据结构发由客户端管理，ticket中是包含了加密参数等连接信息。当需要重连的时候，客户端将ticket发送给服务器。这样双方就得到了重用的加密参数。

       Session ticket较之Session ID优势在于服务器使用了例如DNS负载均衡等技术的时候。Session ID往往是存储在一台服务器上，当我向不同的服务器请求的时候，就无法复用之前的加密参数信息，而Session ticket可以较好的解决此类问题，因为相关的加密参数信息交由客户端管理，服务器只要确认即可。不过目前只有部分浏览器支持 Session ticket，比如谷歌等。其他不支持的浏览器仍然使用 Session ID

难点三： TLS/SSL的区别

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

　　TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

　　SSL是Netscape开发的专门用户保护Web通讯的，目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。两者差别极小，可以理解为SSL 3.1，它是写入了RFC的。 

难点四： RSA和DH秘钥协商的区别和优缺点

RSA算法是基于大数难于分解的原理。不但可以用于认证，也可以用于密钥传输。那么用户A和B如何利用RSA算法来传输密钥呢？

1：A产生一个密钥K，用B的公钥加密K，然后将得到的密文发送给B。

2：B用自己的私钥解密收到的密钥，就可以得到密钥。

DH算法实现 以及两者的区别 见下一章，

摘要参考：

http://kb.cnblogs.com/page/197396/

http://blog.csdn.net/mrpre/article/details/52608867

http://blog.csdn.net/qq_31780525/article/details/54579439

https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/   这个写得很详细。