确保Web安全的HTTPS

HTTP为什么需要加密

HTTP的缺点

1. 通信使用明文（不加密），内容可能会被窃听

   因为互联网是由能连接到全世界的网络组成的，当客户端和服务器通信时，通信线路上存在各种网络设备、交换机等等，因此不排除某个环节中会遭到恶意偷窥行为。

2. 不验证通信方的身份，因此有可能遭遇伪装

   HTTP协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等类似问题

3. 无法证明报文的完整性，所以有可能已遭篡改

   所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

加密处理防止被监听

当我们要给一个人传输秘密数字比如：123456，我们可以事先指定传输时的数字是每位加1之后的，比如234567，当对方拿到数字之后，再通过逐一减1进行解密，即可获得我们最初想要传输的数字，这就是经过加密传输的处理，当中间有人获取到234567时，它并不知道我们之间通信的真正内容是123456.

对称加密

对称加密是指双方持有相同的密钥进行通信，即双方使用同一套加密算法，上述举例就是一种对称加密。但是这样有一个安全问题，如何使通信双方获得相同的密钥，如果服务器直接将密钥传输给客户端，这个传输过程同样有可能在中间被拦截窃听。

非对称加密

非对称加密，又称为公开密钥加密，是为了解决对称加密中的安全问题而诞生。一个称为公开密钥(public key)，即公钥，另一个称为私钥(private key)，即私钥。但是它的加密速度相对于对称加密来说很慢。

• 公钥(public key)是对外开放的，私钥(private key)是自己拥有的。
• 公钥(public key)加密的数据，只能用私钥(private key)解密。
• 私钥(private key)加密的数据，只能用公钥(public key)解密。

注意： 公钥加密的数据，不能由公钥解密。(公钥加密私钥解，私钥加密公钥解)

对称加密和非对称加密结合使信息保密传输

我们可以使服务器传递一个公钥给客户端，然后客户端生成一段密文，通过公钥加密传输给服务器，即使中间设备拦截到了公钥，因为公钥不能解开公钥加密数据，所以此时中间设备无法获取传输的加密内容。从而加密过的密钥安全传递到服务器，服务器再使用私钥解密获取密钥。之后传输数据都使用这个服务器和客户端独有的密钥进行加密传输。

信息的完整性（数字签名）

信息传输的途中，我们的信息很有可能被第三方劫持篡改，所以我们需要保证信息的完整性，通用方法是使用散列算法如SHA1，MD5将传输内容hash一次获得hash值，即摘要。客户端使用服务端的公钥对摘要和信息内容进行加密，然后传输给服务端，服务端使用私钥进行解密获得原始内容和摘要值，这时服务端使用相同的hash算法对原始内容进行hash，然后与摘要值比对，如果一致，说明信息是完整的。

数字证书

如果中间设备自己也生成一套公钥和私钥，并在服务器传送信息时，中间设备将自己的公钥传递给客户端，这样不就拦截到了客户端传输的密钥了吗。也就是说，客户端无法判断这个公钥是服务器传递过来的，还是中间的攻击者传递的。此时就需要一种身份识别的机制来验证这个公钥是否是服务器传递过来的。

为了解决这个问题，我们可以用第三方机构来证明服务器真实性，这个机构就好比我们大学，当我们毕业之后大学会颁发给我们盖有公章的毕业证书，当我们去求职的时候，我们出示证书，可以证明自己确实毕业于这所大学。

可以使用数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

首先服务器将自己的域名和公钥去机构认证，获取认证证书，第三方机构辨识申请者身份之后，会使用自己的私钥对证书和服务器的公钥加密。

服务器就会将这份由数字证书认证机构颁发的公钥证书发送给客户端。那么问题又来了，如何将第三方机构的公钥安全传递给客户端呢？换句话说，客户端如何知道这就是第三方机构的公钥呢？实际上，权威的第三方机构的公钥不需要通过通信获取，都已经内嵌在各个操作系统中，因此当接收到服务器证书时，只需要使用提前内嵌在操作系统中的公钥解密，就可以了。这样，通过证书认证的方式，客户端就能够辨识证书中的公钥，确实是和自己通信的服务器传递的而不是其他中间服务器的。然后用服务器的公钥对自己生成的密文加密，传递给服务器。之后便可以使用这个密钥进行对称加密传输数据了。

通信步骤

• 步骤1： 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
• 步骤2： 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
• 步骤3： 之后服务器发送Certificate报文。报文中包含公开密钥证书。
• 步骤4： 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
• 步骤5: SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
• 步骤6： 接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
• 步骤7： 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
• 步骤8： 服务器同样发送Change Cipher Spec报文。
• 步骤9： 服务器同样发送Finished报文。
• 步骤10： 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
• 步骤11： 应用层协议通信，即发送HTTP响应。
• 步骤12： 最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

参考《图解HTTP》