其他分享
首页 > 其他分享> > 听说你还为答不好 HTTPS 而发愁?

听说你还为答不好 HTTPS 而发愁?

作者:互联网

老标题党了,即将发车,请坐稳了

涉及问题

  1. 说说你对 HTTPS 的理解
  2. 为什么比 HTTP 更安全
  3. 为什么不直接使用非对称加密或对称加密
  4. 为什么要握手,TLS 的握手过程能讲讲吗

出现原因及特点

HTTPS 相比 HTTP 主要解决原先存在的安全问题,如使用纯文本的形式传输 header,没有完整性校验无法验证是否篡改,没有有效手段确认通信双方的身份等。

除此之外,它和 HTTP 表现一致,如传输内容不限于文本,分为请求方和应答方,有连接无状态等。

如何保障安全

安全性主要由 SSL / TLS 来保障。HTTPS 由原来的直接和 TCP 通信,变为先和 SSL / TLS 通信。

SSL,指安全套接层。TLS,指传输层安全。两者其实含义相近,TLS1.0 是 SSL3.1的正式标准化版本。

使用 TLS 建立连接时,会选用一组加密算法,它也称为密码套件。命名格式比较固定,通常由密钥交换算法,签名算法,对称加密算法,摘要算法组成,来保障安全。

如,ECDHE-RSA-AES256-GCM-SHA384

在这里插入图片描述

安全与解决方案的对应

安全可以从四个方面来理解:

  1. 机密性,即只有可信的人才能访问,对应上述的密钥交换算法和对称加密算法
    HTTPS 采用混合加密的形式,使用非对称加密算法传输用于对称加密的密钥。
    非对称加密,分为公钥和私钥,通常基于复杂的数学问题,计算量大;
    对称加密,加密解密使用同一密钥,计算快,但交换密钥时存在安全问题。
    混合加密将两者结合,效益最大。

  2. 完整性,即数据在传输过程中没有发生篡改,对应上述的摘要算法

    请求方会生成摘要附在原文后,应答方收到数据后,再做一次计算进行比对来验证是否发生篡改。
    完整性需要以机密性为前提,否则可以同时篡改摘要和内容,便失去了意义。

  3. 身份认证,即可以验证对方身份的真实性。

  4. 不可否认性,即不能抵赖已经做过的事。

    身份和不可否认性,对应上述的签名算法

    使用私钥加密,公钥解密的方式,私钥加密原文摘要,即数字签名,公钥解密后与摘要进行比对,来达到验证身份的效果。

    数字证书是为了验证公钥的来源,即确认是你的公钥。借助 CA 证书认证机构,来为各个公钥签名(像现实中的大佬背书)。

    证书可以分为 DV, OV, EV,可信度递增。免费证书通常为 DV,只验证域名,并不知道持有者身份。证书中包含各项信息,如颁发者,使用者,有效期,公钥等

    CA 的信任链也可能出现问题,如被黑客攻击,此时可以选择在浏览器中撤销对 CA 的信任,或借助 CRL (证书吊销列表),OCSP(在线证书状态协议) 找到有问题的证书

TLS 握手

握手主要是为安全地交换会话密钥,也就是做前文提到的:使用非对称加密算法传输用于对称加密的密钥

在这过程中,共出现了三个随机数(C,S,Pre-master),主要用于提高随机性,达到不可预测,提高破解的难度

根据密钥交换算法(即非对称算法)的选择不同,可以分为两种。

一种为目前主流的使用 ECDHE,客户端和服务端会相互交换 ECDHE 的公钥,由两个公钥再使用 ECDHE 计算得 pre-master,和握手过程中交换得到的客户端随机数,服务端随机数一起生成主密钥。这种形式具有前向安全性,每次握手时交换的公钥私钥对都是临时的,黑客破解一个后只破解了一次会话。

另一种为传统的 RSA,由客户端直接生成随机数 pre-master,使用服务端提供的 RSA 公钥传递。之后的流程相似,借助三个随机数生成主密钥。相比 ECDHE,这种方式的公钥固定,容易被破解。

ECDHE 握手过程

超长图例

  1. 客户端向服务端:TLS 版本号,随机数 C,可选密码套件列表
  2. 服务端向客户端:TLS 版本号,随机数 S,选择的密码套件;证书;ECDHE 公钥,携带签名;
  3. 客户端向服务端:(验证证书和签名)ECDHE 公钥;(两边计算得 Pre-master,生成主密钥);改用会话密钥(Change Cipher Spec);握手数据摘要(Finished)
  4. 服务端向客户端:改用会话密钥;握手数据摘要

RSA 握手过程

超长图例

  1. 客户端向服务端:TLS 版本号,随机数 C,可选密码套件列表
  2. 服务端向客户端:TLS 版本号,随机数 S,选择的密码套件;证书
  3. 客户端向服务端:(验证证书和签名,生成 Pre-master)RSA 公钥加密 pre-master;(三个随机数生成主密钥);改用会话密钥(Change Cipher Spec);握手数据摘要(Finished)
  4. 服务端向客户端:改用会话密钥;握手数据摘要

致谢

透视 HTTP 协议 yyds!

本文为阅读 安全篇 后的总结,带有个人理解部分。
如存在理解偏差,欢迎一起讨论~

标签:TLS,公钥,加密,发愁,密钥,HTTPS,不好,服务端,客户端
来源: https://blog.csdn.net/qq_44537414/article/details/115506193