【安全系列】wireshark解析https

1.http痛点

​ http协议使用极为广泛，但是存在不小的安全缺陷。主要是其数据的明文传送和消息完整性检测的缺乏, 而这两点恰好是网络支付，网络交易等新兴应用中安全方面最需要关注的。
如以下场景：
当我们在进行一些敏感操作的时候，如果有中间人拦截了我们请求，那就会很轻易的得到和服务器直接交互的数据，并且很轻易的进行篡改。

​ 以上，中间人在对请求进行拦截时，可以很轻易的获取用户A的账号密码；对用户B的转账金额或者转账人进行篡改。
​ https针对http的数据不安全等问题做出了改善。主要解决在数据的传输过程中数据不被窃取、改变，确保数据的完整性。

2.https思路

通俗一点讲，https在http交互时通过信息加密的手段来保证信息的安全。但是如何将秘钥安全的交给客户端就是一个难题。如果通过普通的网络传输，中间人截获了秘钥之后，同样可以对传输的信息进行解密。

为了更好的传输服务器，就诞生了一个证书的概念，可认为证书是一个安全的加密的载体，里面存放了服务器下发的公钥等信息（证书的验证是一个很繁琐的过程，暂时先不说）。服务器如果需要https进行加密的话，需要去权威的机构申请证书，客户端收到证书，验证证书的合法性，如果合法，则解析证书获得服务器的公钥。

这时候就想，所有的用户都可以获取证书呀，也可以解析到公钥呀，服务器下发什么信息，中间人照样可以获取呀，难道这样就安全了吗？
当然不是。对称加密是有一个特点，公钥加密的可以使用私钥解密；私钥加密可以公钥解密。
利用这一特点，客户端生成对称加密key。通过公钥进行加密，这时只有服务器有私钥，所以就只有服务器才能解密。
服务器通过私钥解析出对称加密的信息之后，通过相同的加密算法计对称的加密加密key之后，剩下信息交互即可通过对称加密进行通信。保证了信息的安全。

3.wireshark抓包

以左边的no来进行解释。

1.tcp握手阶段

​ 1，2，3这三个包，有SYN和ACK的过程，很明显是3次握手。

2.Client Hello

Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301) ##版本号
Length: 512
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 508
Version: TLS 1.2 (0x0303)
Random: cae0f1588a004987de3cda24cbc308d580b245b9e527ef15…
Session ID Length: 32 ## session Id
Session ID: 90526a2fd91ed0881c64d003718e9e271edb0ab8f7c34629…
Cipher Suites Length: 32
Cipher Suites (16 suites) ## 密码套件，说明客户端支持的加密方式
Cipher Suite: Reserved (GREASE) (0xeaea)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)

​ … 此处省略…

• version 版本号,https也有版本号哦TLS 1.0、TLS 1.1、TLS 1.2等等
• random 随机数，用来以后计算对称加密key
• Session ID 保存会话的标识
• Cipher Suites 说明客户端支持的加密方式，如上说明支持16种加密方式。
  • TLS_AES_128_GCM_SHA25，说明使用的TLS版本协议，公钥下发的时候使用ASE非对称加密，交互的时候GCM对称加密，通过SHA25检查信息完整性。

3.server hello

Handshake Type: Server Hello (2)
Length: 59
Version: TLS 1.2 (0x0303)
Random: 5f3f386661455aa00293318935cf9d92796fa6d8bcc6acc5…
Session ID Length: 0
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Compression Method: null (0)
Extensions Length: 19
Extension: session_ticket (len=0)
Extension: application_layer_protocol_negotiation (len=11)

服务器的hello信息比较简单，主要是从客户端的加密方式中选择一个合适的加密方式告诉客户端。而且也有random，这个时候服务器和客户端就同时有只属于这次信息交互的唯一标识了。

4.Certificate
接着服务器下发证书。下发的信息如下：

TLSv1.2 Record Layer: Handshake Protocol: Certificate
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 3756
    Handshake Protocol: Certificate
        Handshake Type: Certificate (11)
        Length: 3752
        Certificates Length: 3749
        Certificates (3749 bytes)
            Certificate Length: 2610
            Certificate: 30820a2e30820916a003020102020c725878366e9f56e81d… (id-at-commonName=baidu.com,id-at-organizationName=Beijing Baidu Netcom Science Technology ,id-at-organizationalUnitName=service operation department,id-at-localityName=beiji
            Certificate Length: 1133
            Certificate: 3082046930820351a003020102020b040000000001444ef0… (id-at-commonName=GlobalSign Organization Validation CA - SHA256,id-at-organizationName=GlobalSign nv-sa,id-at-countryName=BE)

这里的信息看着好像看不懂的样子，但是自己查看，就发现了baidu.com的字眼，这个就是百度的证书，这里主要是证书的信息，比如有效时间，颁发者是谁颁给谁，域名信息等等。有兴趣的可以点击锁子查看证书信息。

5.Client Key Exchange
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3 生成 PreMaster Key。
将PreMaster Key传给服务器，这时再通过相同的算法，计算出对称加密的key,算法选择在证书下发的时候有。
6.Encrypted Handshake Message
这个是Finish消息。
客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
之后服务器也会发一个相同的消息，作用是一样的
7.Application Data
之后的信息传输会通过这个包进行传输。这个包的信息是通过对称加密算法进行加密后的信息。

总结

简单的说https的交互是通过非对称加密算法最后换取对称加密算法的key，最后通过加密算法进行交互。
主要是因为对称加密的加解密速度优于非对称加密。
​ 但是，凡事有好处就一定存在弊端。https也不是特别的完美：

1. https为了确保数据的安全性，交互过程及其复杂，和服务器交互的时候存在相当多的加密机密操作，相同网络环境下，速度相比http协议会慢很多，毕竟第一次需要交换密钥，每一次信息的传输都有加密解密的操作。
2. https只是防止了和服务器交互时数据的安全性，并不是防止了所有的黑客攻击。在使用拒绝服务攻击时，起不到什么作用。
3. https加大的中间人获取信息内容的难度，但是丝毫不影响中间人阻止信息传输到服务器。
4. HTTPS安全主要是通过证书实现的。SSL证书的信用链并不安全，如果可以控制CA根证书的情况下，中间人攻击一样可以生效。控制CA的根证书可能是有难度，但是攻击者通常使客户端信任一个仿造的证书来达到攻击目的，常见的fiddler抓取https包就是通过仿造证书达到的。

系列文章目录

【安全系列】https中间人攻击