HTTPS

为什么需要HTTPS？

在HTTP协议中有可能存在信息窃取或身份伪装等安全问题。使用HTTPS通信机制可以有效的防止这些问题。

HTTP协议存在的哪些问题：

• 通信使用明文（不加密），内容可能被窃听
  • 由于HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密，即，HTTP报文使用明文（指未经过加密的报文）方式发送。
  • HTTP明文协议的缺陷是导致数据泄漏，数据篡改，流量劫持，钓鱼攻击等安全问题的重要原因。HTTP协议无法加密数据，所有通信数据都在网络中明文“裸奔”。通过网络的嗅探设备及一些技术手段，就可还原HTTP报文内容。
• 无法证明报文的完整性，所以可能遭篡改
  • 所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性。因此，在请求或响应送出之后直到对方接收之前的这段时间内，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。
• 不验证通信方的身份，因此有可能遭遇伪装
  • HTTP协议中的请求和响应不会对通信方进行确认。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应。
  • HTTP协议无法验证通信方身份，任何人都可以伪造虚假服务器欺骗用户。

HTTPS如何解决HTTP上述问题

HTTPS并非是应用层的一种新协议。只是HTTP接口部分用SSL（安全套接字层）和TLS（传输层安全协议）协议代替而已。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP。

在采用SSL后，HTTP就拥有了HTTPS的加密，证书和完整性保护这些功能。也就是说HTTP加上加密处理和认证以及完整性保护后即是HTTPS。

HTTPS协议的主要功能基本都依赖于TLS/SSL协议，TLS/SSL的功能实现主要依赖于三种基本算法：散列函数，对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

对称加密 + 非对称加密（HTTPS采用这种方式）

使用对称密钥的好处是解密的效率比较块，使用非对称密钥的好处是可以使得传输的内容不能被破解。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称”密钥，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

解决报文可能遭篡改问题——数字签名

如何校验数据的完整性？——校验数字签名

数字签名的作用：

• 接收者能够核实发送者对报文的签名，也就是说，接收者能够确信该报文的确是发送者发送的，其他人无法伪造对报文的签名，这是报文鉴别。
• 接收者确信所收到的数据和发送者发送的完全一样而没有被篡改过，这是报文的完整性。
• 发送者不能抵赖对报文的签名。这叫做不可否认性。

数字签名如何生成

将一段文本先用HASH函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

校验数字签名流程

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

假设消息传递在Kobe，James两人之间发生。James将消息连同数字签名一起发送给Kobe，Kobe接收到消息后，通过校验数字签名，就可以验证接收到的消息就是James发送的。当然，这个过程的前提是Kobe知道James的公钥。问题的关键是，和消息本身一样，公钥不能在不安全的网络中直接发送给Kobe，或者说拿到的公钥如何证明是James的。

这时就需要引入了证书颁发机构（Certificate Authority，简称CA）。

中间人攻击

如果在数据传输过程中，中间人劫持了数据，此时它的确无法得到浏览器生成的密钥X，这个密钥本身被公钥A加密了，只有服务器才有私钥A‘ 解开它，然而中间人却完全不需要拿到私钥A’ 就能干坏事。

1. 某网站有用于非对称加密的公钥A，私钥A‘。
2. 浏览器向网站服务器请求，服务器把公钥明文传输给浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（当然，它也拥有公钥B对应的私钥B’）。
4. 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B‘ 解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’ 解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人掉包了服务器传来的公钥，进而得到了密钥X。根本原因在于浏览器无法确认收到的公钥是不是网站自己的。数字证书可以解决中间人攻击的问题。

数字证书的构成

• 颁发者：表示该证书是哪个机构发布的。
• 有效期：表示证书的有效期，超过期限证书就会作废。
• 公钥：证书持有者的公钥。
• 使用者：证书持有者，或者说证书颁发的对象。
• 签名哈希算法：对证书主体内容进行哈希的算法，可以获得证书主题内容的摘要，这个摘要就是证书的指纹，最终用于证书数字签名和证书认证。
• 签名算法：数字签名所使用的加密算法，使用CA的私钥加密。

数字证书认证机构的业务流程

• 服务器的运营人员向第三方机构CA提交公钥，组织信息，个人信息（域名）等信息并申请认证；
• CA通过线上，线下等多种手段验证申请者提供信息的真实性，如组织是否存在，企业是否合法，是否拥有域名的所有权等；
• 如信息审核通过，CA会向申请者签发认证文件——证书。证书包含以下信息：申请者公钥，申请者的组织信息和个人信息，签发机构CA的信息，有效时间，证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；
• 客户端Client向服务器Server发出请求时，Server返回证书文件；
• 客户端Client读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用CA对应的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
• 客户端还会验证证书相关的域名信息，有效时间等信息；客户端会内置信任CA的证书信息（包含公钥），如果CA不被信任，则找不到对应CA的证书，证书也会被判定无效。

SSL 4次握手阶段

1. 客户端发出请求

   • 首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这叫做ClientHello请求。

   • 在这一步中，客户端主要向服务器提供以下信息

     • 支持的协议版本，比如TLS 1.0版。
     • 一个客户端生成的随机数，稍后用于生成“对话密钥”。
     • 支持的加密算法，比如RSA公钥加密。
     • 支持的压缩方法。

2. 服务器回应

   • 服务器收到客户端请求后，向客户端发出回应，这叫做ServerHello。
   • 服务器的回应包含以下内容
     • 确认使用的加密通信协议版本，比如TLS 1.0版本，如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
     • 一个服务器生成的随机数，稍后用于生成“对话密钥”。
     • 确认使用的加密方法，比如RSA公钥加密。
     • 服务器证书

3. 客户端回应

   • 客户端收到服务器回应之后，首先验证服务器证书。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
   • 如果证书没有问题，客户端就会从证书中取出服务器的公钥，然后，向服务器发送下面三项信息。
     • 一个随机数。该随机数用服务器公钥加密，防止被窃听。
     • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
     • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
   • 上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称 “pre-master key”。有了它之后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把“会话密钥”。
   • 至于为什么一定要用三个随机数，来生成“会话密钥”？
     • 不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样，由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
     • 对于RSA密钥交换算法来说，pre-master key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个对称密钥。
     • pre-master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-master secret就可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret三个随机数一同生成的密钥就不容易被猜出来了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了。

4. 服务器的最后回应

   • 服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的“会话密钥”，然后向客户端最后发送下面的信息。
     • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
     • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
   • 至此，整个握手阶段全部结束，接下来，客户端与服务器进入加密通信。就完全使用普通的HTTP协议，只不过会用“会话密钥”加密内容。

HTTPS通信过程

步骤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连接就算建立完成。从此开始进行应用层协议的通信，即发送HTTP请求。

步骤11：应用层协议通信，即发送HTTP响应。

步骤12：最后由客户端断开连接。断开连接时，发送close_notify报文。

HTTP与HTTPS的区别

• HTTP是明文传输协议，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议，比HTTP协议安全；
• HTTPS需要用到SSL证书，而HTTP不用；
• HTTPS标准端口443，HTTP标准端口80；
• HTTPS基于传输层，HTTP基于应用层；
• HTTPS在浏览器显示绿色安全锁，HTTP没有显示；