HTTPS原理简述

本文涉及的产品
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介: 角色:   A,B,Server,Client,中间窃听者,数字证书签发机构(CA) 工具:对称加密算法,非对称加密算法,数字签名,数字证书 第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

角色:   A,B,Server,Client,中间窃听者,数字证书签发机构(CA)

工具:对称加密算法,非对称加密算法,数字签名,数字证书

第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

第三步,爱丽丝确认数字证书(对证书信息进行md5或者hash后的编号==用证书机构的公钥对加密的证书编号解密后的证书编号)有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥(鲍勃的公钥),加密这个随机数,发给鲍勃。

第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。

第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。

https要使客户端与服务器端的通信过程得到安全保证,必须使用对称加密算法并且每个客户端的算法都不一样,需要一个协商过程,但是协商对称加密算法的过程,需要使用非对称加密算法来保证安全,直接使用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

通信安全问题

当A在向B进行通信时,如果是以明文的方式进行通信,中间窃听者会获得双方的传输的数据。

HTTPS要解决如下问题:A发给B的消息包,即使被中间人拦截到了,也无法得知消息的内容。即A与B通信的内容,有且只有A和B有能力看到通信的真正内容。

解决方案-对称加密算法

对消息进行对称加密,只要这个密钥不公开给第三者,同时密钥足够安全,就可以解决通信的安全问题。

如果服务器端对所有的客户端通信都使用同样的对称加密算法,无异于没有加密。故Web服务器与每个客户端必须使用不同的对称加密算法。

确定对称加密算法

对称加密算法的协商-通过非对称加密

非对称加密特点是私钥加密后的密文,只要是公钥,都可以解密,但是公钥加密后的密文,只有私钥可以解密。私钥只有一个人有,而公钥可以发给所有的人。

解决了协商加密算法的问题:使用非对称加密算法进行对称加密算法协商过程。服务器端向A、B的方向还是不安全的,但是至少A、B向服务器端方向是安全的。

每个通信使用不同对称加密算法-使用随机数

要达到Web服务器针对每个客户端使用不同的对称加密算法,同时,也不能让第三者知道这个对称加密算法是什么,该怎么解决?使用随机数,就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。

客户端如何获取公钥-服务器发送公钥给客户端

如果使用非对称加密算法,客户端A,B需要一开始就持有公钥,否则无法进行加密。

需要解决A,B客户端安全的获得公钥问题。可以有以下方案:

方案1. 服务器端将公钥发送给每一个客户端

方案2. 服务器端将公钥放到一个远程服务器,客户端可以请求得到

选择方案1,因为方案2又多了一次请求,还要另外处理公钥的存放问题。

防止服务器发送给客户端公钥被调包-数字证书

让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。解决方案是使用第三方机构的公钥。

公钥被调包的问题出现,是因为我们的客户端无法分辨返回公钥的人到底是中间人,还是真的服务器。这其实就是密码学中提的身份验证问题。

使用数字证书来解决,不能直接将服务器的公钥传递给客户端,而是第三方机构使用它的私钥对我们的公钥进行加密后,再传给客户端客户端再使用第三方机构的公钥进行解密。

第三方机构向多家公司颁发证书并且这些证书的解密的第三方机构公钥都是一样的,这会导致客户端能解密同一家第三机构颁发的所有证书。最终导致其它持有同一家第三方机构证书的中间人可以进行中间证书传递时的调包。

 

防止服务端向客户端发送证书时证书被调包-数字签名&证书放在客户端

数字签名可以解决同一机构办法的不同证书被篡改的问题。证书应该放到客户端,客户端拿到证书后应该可以分辨证书是否被篡改了。

客户端如何才能具有这个辨别能力?,如下图:

这个"第三方机构"如果是个远端服务,整个交互都会慢了。所以,这个第三方机构的验证功能只能放在客户端的本地。

客户端本地如何验证证书:证书本身就已经告诉客户端怎么验证证书的真伪。

  • 证书上写着如何根据证书的内容生成证书编号。
  • 客户端拿到证书后根据证书上的方法自己生成一个证书编号,如果生成的证书编号与证书上的证书编号相同,那么说明这个证书是真实的。
  • 为避免证书编号本身又被调包,所以使用第三方的私钥进行加密。

证书的制作如图所示:

证书中的“编号生成方法MD5”就是告诉客户端:你使用MD5对证书的内容求值就可以得到一个证书编号。

当客户端拿到证书后,开始对证书中的内容进行验证,如果客户端计算出来的证书编号与证书中的证书编号相同,则验证通过:

但是第三方机构的公钥怎么跑到了客户端的机器中呢?

现实中,浏览器和操作系统都会维护一个权威的第三方机构列表(包括它们的公钥)。--此处相当重要,必须相信权威,否则进入鸡生蛋蛋生鸡。

因为客户端接收到的证书中会写有颁发机构,客户端就根据这个颁发机构的值在本地找相应的公钥。

ps:证书就是HTTPS中数字证书,证书编号就是数字签名,而第三方机构就是指数字证书签发机构(CA)。

 

目录
相关文章
|
13天前
|
安全 算法 网络安全
一张图就把HTTPS工作原理讲明白了!
【10月更文挑战第31天】
28 1
一张图就把HTTPS工作原理讲明白了!
|
2月前
|
安全 网络安全 数据安全/隐私保护
https的原理
https的原理
57 2
|
3月前
|
安全 算法 网络协议
【在Linux世界中追寻伟大的One Piece】HTTPS协议原理
【在Linux世界中追寻伟大的One Piece】HTTPS协议原理
47 2
|
4月前
|
缓存 网络协议 算法
(二)Java网络编程之爆肝HTTP、HTTPS、TLS协议及对称与非对称加密原理!
作为一名程序员,尤其是Java程序员,那必须得了解并掌握HTTP/HTTPS相关知识。因为在如今计算机网络通信中,HTTP协议的作用功不可没,无论是日常上网追剧、冲���、亦或是接口开发、调用等,必然存在HTTP的“影子”在内。尤其对于WEB开发者而言,HTTP几乎是每天会打交道的东西。
96 10
|
3月前
|
安全 Nacos 数据安全/隐私保护
【技术干货】破解Nacos安全隐患:连接用户名与密码明文传输!掌握HTTPS、JWT与OAuth2.0加密秘籍,打造坚不可摧的微服务注册与配置中心!从原理到实践,全方位解析如何构建安全防护体系,让您从此告别数据泄露风险!
【8月更文挑战第15天】Nacos是一款广受好评的微服务注册与配置中心,但其连接用户名和密码的明文传输成为安全隐患。本文探讨加密策略提升安全性。首先介绍明文传输风险,随后对比三种加密方案:HTTPS简化数据保护;JWT令牌减少凭证传输,适配分布式环境;OAuth2.0增强安全,支持多授权模式。每种方案各有千秋,开发者需根据具体需求选择最佳实践,确保服务安全稳定运行。
320 0
|
5月前
|
安全 网络协议 算法
Android网络基础面试题之HTTPS的工作流程和原理
HTTPS简述 HTTPS基于TCP 443端口,通过CA证书确保服务器身份,使用DH算法协商对称密钥进行加密通信。流程包括TCP握手、证书验证(公钥解密,哈希对比)和数据加密传输(随机数加密,预主密钥,对称加密)。特点是安全但慢,易受特定攻击,且依赖可信的CA。每次请求可能复用Session ID以减少握手。
63 2
|
5月前
|
网络协议 前端开发 Java
网络原理 - HTTP / HTTPS(4)——构造http请求
网络原理 - HTTP / HTTPS(4)——构造http请求
56 1
|
5月前
|
存储 JSON 安全
网络原理 - HTTP / HTTPS(2)——http请求
网络原理 - HTTP / HTTPS(2)——http请求
59 1
|
6月前
|
安全 网络协议 算法
秒懂HTTPS接口(原理篇)
【4月更文挑战第24天】秒懂HTTPS接口(原理篇)
499 4
秒懂HTTPS接口(原理篇)
|
6月前
|
安全 网络协议 应用服务中间件
一文读懂HTTPS⭐揭秘加密传输背后的原理与Nginx配置攻略
一文读懂HTTPS⭐揭秘加密传输背后的原理与Nginx配置攻略