Ricky.L的随笔
0%

https、TLS握手

发表于 更新于 分类于 Disqus：

http传输数据存在哪些问题？

不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。
（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。
（2） 篡改风险（tampering）：第三方可以修改通信内容。
（3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

Charles抓包就是中间人拦截监听。

https新引入了什么？解决了什么问题？

  1. 数据加密传输，防止窃听
  2. 校验数据，防止篡改
  3. 使用数字证书验证身份，防止身份被冒充

https缺点是什么？

  1. TLS握手增加了建立连接的时间
  2. 每次加密解密数据需要占用额外的时间和CPU资源

https如何保证数据的完整性？

http验证数据完整性存在的问题：

http通信是不加密的，即使对报文做了哈希摘要，并放在报文中传输，http通信内容被拦截篡改后，一并把哈希摘要也改掉，客户端是没办法识别报文是否被篡改。

https改进：

对报文的哈希摘要进行加密，另一方接受到报文并重新计算报文的哈希摘要，再对比解密后的摘要，检查是否一致。

对摘要的加密用对称加密，对称加密的秘钥用非对称加密方式加解密。

https加密过程是怎样的？

采用对称加密方式加密报文，对称加密的秘钥用非对称加密方式加密后传递给通信双方。

因为：

  1. 对称加密速度快，但是通信双方都需要同一个密钥，密钥在传输过程中被窃取泄露后就不安全了
  2. 非对称加密速度慢，但私钥不公开，只传递公钥出去，可以保证安全性

https通信过程是怎样的？

  1. 客户端发起SSL/TLS连接
  2. 客户端获取服务端数字证书，验证服务端身份
  3. 两端生成随机数，由服务端根据随机数，用私钥加密得到对称加密密钥
  4. http的请求和响应报文都用对称加密密钥加密后再传输

SSL/TLS握手过程是怎样的？

有四次握手

  1. 客户端请求建立SSL链接，并向服务端发送一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。
  2. 服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
  3. 客户端收到服务端的回复后利用服务端的公钥，加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密，发送给服务器。
  4. 服务端收到客户端的回复，利用已知的加解密方式进行解密，同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。

此后的HTTP链接数据传输即通过对称加密方式进行加密传输。

为什么需要3个随机数作为对称加密的密钥？

不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在，在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

还有什么密钥交换算法？

ECDHE ：“短暂 - 椭圆曲线 - 迪菲 - 赫尔曼”算法（ephemeral Elliptic Curve Diffie–Hellman）。

RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。而 ECDHE 算法具有前向安全，所以被广泛使用。

客户端和服务端双方在一个可以被窥探的信道下给双方建立起一个相同的密钥。

发送公有的参数，保留私有的参数，双方经过计算可以得到一个一致的结果，一致的结果可以用作会话密钥，这个运算的逆运算复杂度很高，所以不会泄露。

为什么参数被窥探后还能够达到保密的效果?

Deffie-Hellman算法的有效性依赖于计算离散对数的难度。

https总共有多少次握手了？

SSL是在TCP之上，在HTTP之下。

TCP先三次握手建立连接，然后SSL四次握手，最后进行HTTP通信。

https的身份认证是如何实现的？

通过数字证书验证通信方身份。

如何验证证书是否可信？

服务端证书都是向CA这类的权威机构申请的，CA颁发证书时会用根证书的私钥去给申请的证书的哈希摘要做加密作为申请的证书的签名。

客户端收到服务端的证书后，查询证书的颁发者，一直寻找到根证书，然后用根证书里的公钥去解密其颁发的证书的签名，对比证书文件的哈希摘要是否一致，这样就验证了身份没有被篡改。

数字证书验证身份的过程是怎样的？

服务端向CA（数字证书认证机构）提交自己的公钥申请数字证书，CA颁发证书，并把服务端的公钥内嵌在颁发的证书中，再对整个证书计算哈希摘要，用一个私钥加密这个哈希摘要，确保了申请到的证书在传输过程中可以校验证书是否被篡改，校验是通过CA提供的根证书里的公钥解密服务端证书中的哈希摘要，再计算服务端证书文件的哈希摘要，对比两者是否一致，根证书一般已事先内嵌客户端。

证书可以有信任链。

https单向认证是什么？

  1. 客户端发起请求，传送支持的TLS版本、摘要算法、随机数等信息
  2. 服务端返回确认的TLS版本、摘要算法，并再发送生成的随机数、服务端的证书
  3. 客户端验证证书是否可信，不可信则弹窗警告，可信则用随机数生成一个用于对称加密的密钥，用于接下来加密报文，用服务端证书的公钥加密发送给服务端
  4. 服务端接收到会话密钥，用私钥解密，得到会话密钥，返回ACK确认消息

https双向认证是什么？

单向认证是客户端验证服务端的证书来检验服务端身份是否合法。

双向认证是服务端也要求验证客户端的证书来检验客户端的身份是否合法。服务端会在发送证书给客户端时，要求客户端也发送证书给服务端。

双向认证使用场景：

使用网上银行可能需要在电脑上插U盾之类的东西，就是生成客户端证书的。