TLS+FakeTLS
TLS+FakeTLS
为了更好的了解https这里写一篇随笔记录一下学习过程
引言
HTTP使用的相当广泛，但还是有很多不足。通信使用明文，内容可能会被窃听、无法证明完整性，可能遭到篡改、不验证通信方的身份，可能遭遇伪装。
解决上述问题的方法:HTTP+TLS(or SSL 下面只说TLS)
- 在互联网任何地方都可能存在监听嗅探，但是经过TLS之后，监听到的只是加密后的信息
- HTTP无法确定通信方，但是TLS可以通过证书来确定
- TLS 提供认证和加密处理及摘要功能。
HTTP+TLS(加密+认证+完整性保护) == HTTPS
上图可知TLS独立于HTTP，除了配合HTTP之外，还可以配合SMTP与Telnet等协议
HTTPS大致过程
对称加密:加密和解密密钥相同,速度快但是密钥管理是个大问题，例如DES、AES、3DES
非对称加密:加密和解密密钥不相同,处理速度慢，例如:RSA、DH
HTTPS是加密通信的，实际上HTTPS使用了非对称加密和对称加密两种算法，HTTPS服务端在连接建立过程中，会先将自身的公钥发送给客户端。客户端拿到公钥后，与服务端协商数据传输通道的对称加密密钥，这个协商过程是基于非对称加密的（因为这时客户端已经拿到了公钥，而服务端有私钥）。一旦双方协商出对称加密密钥，后续的数据通讯就会一直使用协商过的对称加密算法。
上面的阶段看起来完美，但是有一处是存在问题的，网络中随处都可能存在嗅探和中间人，如何判断发给客户端的公钥就是没有被篡改的公钥呢?----->通过数字证书来解决这个问题
HTTPS使用携带公钥信息的数字证书来保证公钥的安全性和完整性，下图只是单纯讲原理。
A为服务端，B为客户端 A向B发送原文件+加密的摘要(经过A的私钥加密)+A的公钥(经过CA私钥加密的)
CA公钥(ca.crt)各个浏览器都自带，先通过CA公钥来获取A的公钥，接着解密摘要，最终获取文件hash值判断摘要是否正确。到了这里我也就知道了为什么要抓取https包的时候(burpsuit要导出证书到浏览器，fiddler要导出证书到手机)
Wireshark TLS数据包分析
TLS 握手则是为了验证身份、交换信息从而生成秘钥，为后续加密通信做准备。通过抓包发现，所有连接最初都要经过 TCP 三次握手，而 TLS 握手是在 TCP 建立连接之后进行的。因此，HTTPS 首次通信需要 3+（不同版本TLS次数不一样） 次握手！
下面是wireshark抓包结果
- 客户端向服务器发送随机数+TLS版本+加密套件列表
- 服务端回包 确认加密版本加密套件等等
这是最新版本TLS1.3干净利落两步完成，具体协议字段含义:略
FakeTLS
大白话:
你黑进别人的服务器，黑完了就走吗？这不得留个后门以防之后对面把漏洞给补上。
留后门你难道后门明文传输吗？不可能明文很容易就会暴露。
那你用自己写的一些加密方式传输吗？当被安全设备发现之后还是会报警(因为内网中突然出现了未知的加密传输)。
那思来想去应该写一个工具用来生成伪造协议并且该协议中本来就存在加密的内容。emmmmTLS完美符合这个条件协议常见并且协议中存在加密的内容。TLS商量好对称加密的密钥后之后的传输就是经过加密的了，如果把后门执行的命令放到被加密的部分这不就完美了，这样就可以实现后门通信并且不会被发现
TLS经过Client Hello和Server Hello......之后会进行Application Data
这里面有一个字段:Encrypted Application Data：这里面存放的是密文，如果我们伪造正常握手然后把经过随便加密的命令放到这个字段里面传输，就实现了FakeTLS。
