HTTPS入门级总结

服务端配置证书，证书就是一个公私钥对。

SSL握手过程

简陋版本：

• 客户端向服务端索要+验证公钥
• 双方协商生成session key
• 利用session key进行对称加密下的通信

详细版本：

• Client Hello，客户端发起请求：客户端向服务端发送

  • 支持的加密协议和对应版本。如TLS 1.0
  • 一个由客户端生成的随机数A
  • 支持的加密方法，比如RSA公钥加密
  • 支持的压缩方法

• Server Hello：服务端回应，服务端发送

  • 确认使用的加密协议和版本，如果不支持客户端发过来的协议and版本，服务器会关闭该流程
  • 一个由服务器生成的随机数B
  • 确认服务器使用的加密方法（可以理解为客户端支持很多种，服务端使用其中一种）
  • 服务器证书

• client reply：客户端回应，客户端先验证服务器的证书，如果证书不可信则抛出警告；如果证书正常，则客户端从证书中提取服务器公钥，并向服务器发送

  • 一个随机数C，称为pre-master key。至此，客户端和服务端同时有了3个随机数，双方会使用事先商定的加密方法，各自生成本次session所用的session key。这把session key在两端都是相同的
  • 编码改变通知。表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 客户端握手结束通知（相当于FIN），表示客户端的握手阶段已经结束。FIN的值等于前面发送的所有内容的hash值，供服务器校验。

• server reply：服务端最后回应，服务端收到pre-master key后生成session key

  • 编码改变通知。表示随后的信息都将用双方商定的加密方法和密钥发送。
  • FIN，FIN的值等于前面发送的所有内容的hash值，供客户端校验。

HTTP过程

• 就是普通的HTTP协议过程，只是用session key加密

如何保证公钥不被篡改

• 解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

  • 怎么保证证书是真的呢？

    • 一般是操作系统自带的，所以提醒我们一定要买正版操作系统。

公钥加密计算量很大，如何减少计算时间

• 解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

为什么生成session key要3个随机数呢

• "不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

HTTPS是绝对安全的吗？如果不是，什么情况下会遭到攻击

• 如果关闭了证书验证，则可能会遭受双重中间人攻击，那什么是双重中间人攻击？

  • 

    

    这里应该上个图

• 如果在SSL握手的时候信息被嗅探到3个随机数

TLS和SSL的关系是什么，差异在哪里

• 简陋版本：TLS 1.0 = SSL 3.1，TLS总体比SSL更安全，TLS有更安全的MAC算法，更严密的警报机制，

• 具体版本：

  • SSL，secure socket layer，安全套接字层。是在网络层和应用层之间的一层协议（该复习下OSI 7层模型了） HTTP - SSL/TLS - TCP - IP
  • TLS比SSL补充了更多的报警代码
  • 在加密计算 session key (master secret)时采用的方式不同
  • 填充：TLS支持填充密文块长度任意整数倍的数据长度，而SSL只支持填充到最小整数倍

HTTPS怎么做到数据防篡改和两端的身份确认？

• 利用摘要算法+数字签名

  • 摘要算法：采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（通常是128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

  • 数字签名

    • 定义：数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
    • 过程：明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名
    • 数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

HTTPS中的session可复用吗？如何恢复

• 是可以的，主要有2种方式

  • 利用session ID

    • session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。
    • session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话

  • 利用session token

    • 客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。