确保Web安全的HTTPS
在HTTP协议中有可能存在信息窃听或者身份伪装等问题，使用HTTPS协议通信机制可以有效地防止这些问题。
1 HTTP协议的缺点
- 通信使用明文，内容可能被窃听
- 不用验证通信方的身份，因此可能会遭遇伪装
- 无法证明报文的完整性，可能已经被人恶意篡改了哦
1.1 通信使用明文被窃听
按照TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。即便是加密处理后的通信，也会被窥视到通信的内容，但是加密后，可能让人无法破解报文信息的含义，但是加密后的报文信息本身还是会被看到的。这里有两种不同形式的加密方式，通信加密和内容加密。
1.1.1 通信加密
HTTP协议中没有加密机制，但是可以通过可SSL【Secure Socket Layer —— 安全套接字层 注：TLS前身】或者TLS【Transport layer Security——安全传输层协议】的组合使用，来加密通信内容。使用SSL建立安全的通信线路后，就可以在这条线路上进行HTTP通信了。
1.1.2 内容加密
只对HTTP协议传输的内容本身进行加密。即把HTTP报文中的内容进行加密处理，报文的首部不加密，报文主体会加密。
1.2 不验证通信方的身份就可能会遭遇到伪装
HTTP协议实现非常简单，不论是谁发送过来的请求都会返回响应【不考虑Web服务器限制访问的情况】。因此会存在以下几种隐患：
- 无法确定请求发送至目标的Web服务器是否是按照真实意图返回响应的服务器，即服务器不是自己请求的那台服务器
- 无法确认返回响应抵达的客户端是不是发送请求的客户端
- 无法确认正在通信的对方是否具备访问权限
- 无法拒绝海量请求下的Dos攻击
因此，为了解决这些问题，有以下几种方法。
1.2.1 查明证书
SSL不仅提供了加密处理的功能，还是用了一种被称为证书的手段，可以用于确认通信的双方。证书需要由值得信任的三方进行颁发，用以证明通信双方是真实存在的。
1.3 无法证明报文的完整性，可能被篡改
请求或者响应在传输途中，遭遇到攻击者拦截并且篡改内容的攻击称为中间人攻击【MITM】。
1.3.1 如何防止篡改
- MD5和SHA-1等根据散列值进行校验的方法，不靠谱，
2 HTTP + 加密 + 认证 + 完整性保护 = HTTPS
HTTPS其实就是先和SSL进行通信，再由SSL和TCP进行通信
2.1 相互交换密钥的公开密钥加密技术
加密和解密使用同一个密钥的方式成为共享密钥加密，也被叫做对称密钥加密。可是密钥要怎么发送呢，既然密钥都能安全发送了，是不是数据也可以不通过加密就可以安全发送呢？
2.2 使用两把密钥的公开密钥加密技术
非对称加密使用两把密钥，一把是公钥，一把是私钥。使用非对称加密的双方，发送方使用公钥对数据进行加密，接收方使用私钥进行解密。
2.3 HTTPS使用混合加密技术
- 使用非对称加密发送需要使用的对称密钥
- 使用对称密钥对信息进行加密
2.4 证明公开密钥正确性的证书
非对称加密还存在一个问题，那就是无法证明公开密钥的正确性。比如，如果打算和某台服务器建立公开密钥加密方式下的通信时，怎样证明收到的公开密钥就是服务器一开始发行的公开密钥呢？
为了解决这个问题，可以使用由数字证书认证机构和其相关机关颁发的公开密钥证书。服务器可以将这份公钥证书发送给客户端，以进行公开密钥加密方式通信。
3 HTTPS通信步骤
- 客户端发送Client Hello报文开始SSL通信。报文中包含了客户端支持的SSL指定版本，加密组件列表
- 服务端可以进行SSL通信时，会以Server Hello报文进行应答
- 之后服务器发送Certificate报文，报文中包含公开密钥证书
- 服务器发送Server Hello done报文通知客户端，最初阶段的SSL握手部分结束
- SSL第一次握手结束后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种Pre-master secret的随机密码串，已用公开密钥进行加密
- 客户端发送Change Cipher Spec报文，提示服务器，之后的通信会采用Pre-master secret密钥加密
- 客户端发送Finished报文，包含全部报文的整体校验值，这次握手是否成功，需要以服务端是否可以正确解密该报文作为判定标准
- 服务端发送Change Cipher Spec报文
- 服务端发送Finished报文
- 服务端和客户端的Finished报文交换结束后，SSL连接建立完成。开始应用层协议通信，发送HTTP请求
- 发送HTTP响应
- 客户端断开连接