安全通信的几个方面
HTTP是使用明文传输协议，使用明文传输导致信息容易泄漏，可是难道安全通信就只有这一个方面吗，我们必须要了解我们所面对的所有安全问题，才能往下解决问题，下面是几个安全问题
机密性
发送方和接收方希望只有他们能理解报文的内容
解决方案：加密算法
- 对称加密：加密和解密用的密钥(或密码表)相同，典型有凯撒密码、流密码、块密码、密码块链接
- 非对称加密：加密和解密用的密钥(或密码表)不相同，典型有RSA,(HTTP也是用非对称加密)
有时加密后也没有任何作用，中间人完全可以使用重放攻击，如你的密码加密后传输给服务器，但是中间人仍然能看到你密码的加密版本，如果加密算法每次加密相同内容时得到的结果都一样，中间人完全可以使用你密码的加密版本去传输给服务器登陆你账号，所以引入不重数概念
不重数： 在很长一段时间内不会重复的数，每次加密时会把不重数加在明文密码后面再一起加密，这样加密的东西一直都不会一样了，服务器如果收到和以前一样的密文可以选择丢弃该请求
报文完整性
发送方和接收方希望通信的内容在传输过程中未被改变
解决方法：密码散列函数(Hash函数)
- 散列算法如SHA-1是公开的，所以中间人完全可以先更改报文，再用算法对更改后的报文计算哈希值
- 发送方和接收方必须秘密商定一个鉴别密钥s，则假设报文为d，则计算哈希值时使用Hash(d+s) = m，然后只传递d
- 验证报文完整性时，接收方也用s来计算Hash(d+s)和哈希值m比对，中间人不知道s无法生成有效的哈希值，用这种方法生成的哈希值称为报文鉴别码MAC(Message Authentication Code)，要与MAC (Media Access Control)地址 区分开
端点鉴别
发送方和接收方希望在通信过程中能鉴别彼此不是中间人伪造的
解决方法：非对称加密的公钥认证方式
- 当访问一个网站时，先获取其数字证书，它的数字证书怎么来的呢，是认证中心CA(Certification Authority) 颁发给它的
- CA把与它网站的身份信息和通信所需的公钥一起用CA的私钥加密生成一个数字证书，CA的公钥在我们的电脑里面（出厂自带）
- 我们用CA的公钥解密数字证书，证实该网站身份，同时取出该网站的公钥加密我们要传输给该网站的报文，这也保证了机密性
可以看出非对称加密的私钥和公钥加密解密顺序不同有不同的作用：
公钥加密私钥解密： 保证机密性
私钥加密公钥解密： 验证身份、数字证书
如某凡事件，中间人伪造双方（由于缺少端点鉴别），且大家都使用明文交流（没有保证机密性），中间人在传递消息时可以随意篡改消息（缺少报文完整性），如果当事人稍微有些网络安全的知识也不会如此吧（想法来自小林coding)
SSL(Secure Socket Layer)/TLS(Transport Layer Security)
SSL/TLS 安全套接字层/运输层安全性，是HTTPS在HTTP和TCP直接加了一层加密层，就可以保证通信安全了
SSL的加密过程
握手
发送方和接收方先建立TCP连接，发送方验证接收方是真正的接收方，发送方发给接收方一个主密钥（实际会更复杂，实际版本在下面）
密钥导出
- 发送方和接收方根据主密钥，各自导出4个四个密钥，两个对称加密密钥Ea,Eb,两个MAC密钥Ma,Mb
- 这个MAC密钥正是上面讲报文完整性的s，用于和数据报d组合起来一起计算Hash值来验证报文完整性的,对称加密密钥就是是用来加密报文的
- 为什么要两个对称加密密码了和两个MAC密钥呢，因为HTTP报文可以在客户端和服务器两个方向进行传输，所以不同方向用不同的对称加密密钥，不同方向用不同的MAC密钥
- 如从A——>B 加密报文用Ea，生成报文鉴别码MAC用Ma
从B——>A 加密报文用Eb，生成报文鉴别码MAC用Mb
数据传输
- SSL会将数据流分割成SSL记录，对每个记录d附加一个MAC用于完整性检查，该MAC = Hash( d + Ma ) ，假设使用密钥Ma
- 然后用Ea加密该 记录+MAC，然后把加密后的数据封装在TCP数据报的数据中，经过TCP传输数据
- 但这样就没问题了吗，攻击者仍然可以更改TCP数据报头部的序号字段，调换两个TCP报文顺序，而该被篡改的报文仍然能通过SSL的安全认证
- 于是SSL维护一个序号，但该序号不加入SSL记录中，只是计算MAC时变为 Hash(d + Ma + 序号)，如果被调换顺序了，则在接收方处无法通过报文完整性检测，会直接被丢弃，然后发送方就会通过TCP重传机制重新传输没被篡改的报文
- 无法通过报文完整性检测是因为接收方是根据TCP报文顺序生成对应报文的序号的，但TCP报文序号被修改了则报文顺序变了,如本来发送 100，200，300，400，500，而发送方也是根据SSL计时器维持的序号1，2，3，4，5计算的MAC，如果被交换顺序了100，200，400，300，500，那么接收方SSL计时器维持的序号仍然是1，2，3，4，5，但是此时3对应400，发送方计算的MAC=Hash(300 + Ma + 3)，而接收方计算的MAC=Hash(400 + Ma + 3)，两者肯定不一致
SSL记录格式
- 前三个字段是不加密的，只有数据和MAC会用Ea加密。
- 类型字段指出该字段是握手报文还是包含应用数据报文，也用于关闭SSL连接
- 看过这么多攻击情况了，敏锐的你是不是能想到，如果有攻击者修改类型字段关闭SSL连接，那么不是也可以让连接提前中断吗，这确实是一种攻击方式称为截断攻击(truncation attack)
- 但SSL记录虽然只加密数据和MAC，但是其报文鉴别码MAC确实根据整个SSL记录加上鉴别密钥Ma算出来的，如果有人修改了明文字段，也是通不过的完整性检测的
根据SSL记录格式，我们也很明显能找到接收方对SSL记录的解密过程，它会先拿会话密钥Ea解密出数据和MAC，再用把整个SSL记录加上鉴别密钥Ma再加上面提到的序号一起进行Hash计算，并把计算的值和MAC比对，如果比对通过了才算真正完成了一次安全通信
HTTPS建立连接流程
- TCP三次握手建立连接，必须先建立TCP双方才能通信，协商SSL协议细节
- 客户发送它支持的密码算法列表，连同一个客户的不重数
- 从该列表中，服务器选择一个对称算法、一种公钥算法和一种MAC(报文鉴别码)算法。它把它的选择以及证书和一个服务器不重数返回给客户
- 客户验证该证书，提取服务器的公钥，生成一个前主密钥PMS(Pre-Master Secret)，用服务器的公钥加密该PMS，并将加密的PMS发送给服务器
- 使用相同的密钥导出函数，客户和服务器独立地从PMS和不重数中计算出主密钥MS(Master Secret)。然后该MS被切片生成两个对称加密密码和两个MAC密钥
- 客户发送所有握手报文的一个报文鉴别码MAC（Message Authentication Code）
- 服务器发送所有握手报文的一个MAC
从第二步开始就是SSL握手过程，最后为什么要所有握手报文发送MAC报文呢，因为在第一步客户发送它支持的密码算法列表和第二步服务器选择算法时都是明文发送的，攻击者可以把一些比较难破解的加密方式从列表中去掉，上面的不重数是为了防止多次连接中的重放攻击，而SSL自带的序号只能防止同一次连接中的重放攻击
参考
《计算机网络 自顶向下》
