ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

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

2021-04-08 10:30:15  阅读:231  来源: 互联网

标签:TLS 公钥 加密 发愁 密钥 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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有