广州总部电话:020-85564311
广州总部电话:020-85564311

广州网站建设-小程序商城开发-广州小程序开发-企业微信开发公司-网站建设高端品牌-优网科技

19年
互联网应用服务商
请输入搜索关键词
深入浅出HTTPS:全面解析网站安全的核心技术
发布日期:2024-10-15 09:28:54
浏览次数:528
来源:马哥Linux运维


1. 介绍

HTTPS其实就是在TCP及HTTP之间加入了SSL/TLS协议。

解决了HTTP协议以下问题:

  • 信息加密:交互信息无法被窃取

  • 校验机制:无法篡改通信内容,篡改了无法通过校验

  • 身份证书:可信的身份证明

2. TLS1.2握手过程

TLS中基本单位是记录(record),多个记录可以合并到一个TCP包中发送。

2.1 RSA TLS握手

2.1.1 RSA TLS握手过程分析

图中的一个框便是一个记录,可以看到RSA握手分为4步,时延为 2 RTT。

  1. 客户端发起TLS握手请求。

  2. 服务端公钥(TLS证书含有公钥),在握手阶段会传给客户端。

  3. 客户端在生成密钥后,使用服务端公钥加密再传回服务端。

  4. 服务器利用私钥解密,拿到相同的密钥。

最后便可以利用非对称加密协商好的对称密钥进行对称加密传输信息了。

完整握手过程如下图所示。

2.1.1.1 TLS第一次握手

客户端发送Client Hello给服务端,并携带客户端TLS版本号/支持的密钥套件/随机数A

2.2.1.2 TLS第二次握手

记录一:Server Hello

服务端发送Server Hello给客户端,并携带确认的TLS 版本号/确认的密码套件/随机数B

密钥套件格式 = 密钥交换算法 + 签名算法 + WITH + 对称加密算法 + 摘要算法, 如果WITH前只有一个算法则表示密钥交换算法及签名算法都用它。

比如,这里选择的密码套件Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256,其实是:
密钥交换算法及签名算法为RSA非对称算法,对称加密算法为GCM分组的密钥长度128的AES对称算法,摘要算法为SHA256。

记录二:数字证书:Certificate

这个记录中包含数字证书,用于客户端验证服务器的身份是否可信。

记录三:Server Hello Done

表示二次握手结束。

2.2.1.3 客户端验证证书

客户端拿到证书后,需要先验证证书是否可信,才决定是否继续握手。

2.2.1.3.1 数字证书和CA机构

数字证书是一种用于在网络通信和信息安全领域中验证身份的数字文件。它通常包含了一个实体(例如个人、组织、设备等)的公钥及其相关信息,并由可信的数字证书颁发机构(CA,Certificate Authority)签名,以确保证书的真实性和可信度。

数字证书的主要组成部分包括:

  • 公钥:证书中包含了实体的公钥,用于加密和解密数据。这个公钥是与私钥一一对应的,但是私钥通常保持在证书的拥有者手中。

  • 证书拥有者信息:包括证书拥有者的名称、电子邮件地址等身份信息。

  • 数字签名:由证书颁发机构使用自己的(CA)私钥对证书的内容进行签名,以确保证书的完整性和真实性。通过验证签名,可以确保证书没有被篡改,并且确实由颁发机构签发。

  • 证书认证机构(CA)的信息:用于证书链验证

2.2.1.3.2 数字证书签发和验证流程

签发流程

CA会将数字证书涉及的信息打包并摘要计算出Hash值。
用自己的私钥对Hash值进行加密,生成的值便是证书签名Certificate Signature。
最后将 Certificate Signature 添加在文件证书上,形成数字证书;

验证流程

客户端会通过一样的摘要算法对数字证书信息计算出一个Hash值A,再通过预置在系统中的CA公钥解密证书签名Certificate Signature得到Hash值B。
判断A和B是否相等便知道证书是否可信。

2.2.1.3.3 证书链

对于这种三级层级关系的证书的验证过程如下:

  • 客户端收到 baidu.com 的证书后,发现这个证书的签发者不是根证书,就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是,客户端根据 baidu.com 证书中的签发者,找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”,然后向 CA 请求该中间证书。

  • 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的,由于 “GlobalSign Root CA” 没有再上级签发机构,说明它是根证书,也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上,如果有,则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书,如果发现验证通过,就认为该中间证书是可信的。

  • “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后,可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性,如果验证通过,就可以信任 baidu.com 证书。


证书链存在的原因:为了确保根证书的绝对安全性,将根证书隔离地越严格越好,如果根证书失守,那么整个信任链都有问题。

2.2.1.4 TLS第三次握手

客户端成功验证数字证书后,继续握手。

记录一:Client Key Exchange

客户端发送Client Key Exchange给服务端,携带用服务器RSA 公钥加密后的新随机数(pre-master)。

记录二:Change Cipher Spec

此时,客户端和服务端双方都共享了三个随机数,分别是 Client Random、Server Random、pre-master。
客户端和服务端会使用这三个随机数生成AES_128_GCM算法的对称密钥,用于后续消息加密。
生成对称密钥后,发送Change Cipher Spec消息告诉服务器开始使用对称密钥加密。

记录三:Encrypted Handshake Message

客户端发送Encrypted Handshake Message给服务端,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

2.2.1.5 TLS第四次握手

服务器给客户端发送Change Cipher SpecEncrypted Handshake Message
如果双方都验证加密和解密没问题,那么握手正式完成。

记录一:Change Cipher Spec

服务端发送给客户端,过程同TLS第三次握手。

记录二:Encrypted Handshake Message

服务端发送给客户端,过程同TLS第三次握手。

2.1.2 RSA缺陷

RSA 密钥协商算法不支持前向保密。

一旦服务端的私钥泄漏了,过去被第三方截获的所有 TLS 通讯密文都会被破解。因为可以通过私钥解密客户端发送的加密后的pre-master随机数。

2.2 ECDHE TLS握手

ECDHE算法具有前向安全性,所以被广泛使用,RSA算法则使用较少了。

2.2.1 DH 算法

ECDHE算法由DH算法演变而来,核心思想是离散对数。

2.2.1.1 离散对数

离散对数简单介绍下。公式如下。

底数G和模数P是离散对数公开的参数。x是对数,y是整数,用于加密。
知道对数x,可以直接算出整数y。但反过来,知道整数y却很难推算出对数x,特别当模数P是一个很大的质数时。

2.2.1.2 DH算法

现假设小红和小明约定使用 DH 算法来交换密钥,那么基于离散对数,小红和小明需要先确定模数和底数作为算法的参数,这两个参数是公开的,用 P 和 G 来代称。

然后小红和小明各自生成一个随机整数作为私钥,双方的私钥要各自严格保管,不能泄漏,小红的私钥用 a 代称,小明的私钥用 b 代称。

现在小红和小明双方都有了 P 和 G 以及各自的私钥,于是就可以计算出公钥:

小红的公钥记作 A,A = G ^ a ( mod P );
小明的公钥记作 B,B = G ^ b ( mod P );
A 和 B 也是公开的,因为根据离散对数的原理,从真数(A 和 B)反向计算对数 a 和 b 是非常困难的,至少在现有计算机的计算能力是无法破解的,如果量子计算机出来了,那就有可能被破解,当然如果量子计算机真的出来了,那么密钥协商算法就要做大的升级了。

双方交换各自 DH 公钥后,小红手上共有 5 个数:P、G、a、A、B,小明手上也同样共有 5 个数:P、G、b、B、A。

然后小红执行运算:B ^ a ( mod P ),其结果为 K,因为离散对数的幂运算有交换律,所以小明执行运算:A ^ b ( mod P ),得到的结果也是 K。

K 就是小红和小明之间用的对称加密密钥,可以作为会话密钥使用。

2.2.1.3 DHE算法

根据私钥生成的方式,DH 算法分为两种实现:

  • static DH 算法,已废弃

  • DHE 算法,当前使用

static DH 算法里有一方的私钥是静态的,也就说每次密钥协商的时候有一方的私钥都是一样的,一般是服务器方固定,即 a 不变,客户端的私钥则是随机生成的。

于是,DH 交换密钥时就只有客户端的公钥是变化,而服务端公钥是不变的,那么随着时间延长,黑客就会截获海量的密钥协商过程的数据,因为密钥协商的过程有些数据是公开的,黑客就可以依据这些数据暴力破解出服务器的私钥,然后就可以计算出会话密钥了,于是之前截获的加密数据会被破解,所以 static DH 算法不具备前向安全性。

既然固定一方的私钥有被破解的风险,那么干脆就让双方的私钥在每次密钥交换通信时,都是随机生成的、临时的,这个方式也就是 DHE 算法,E 全称是 ephemeral(临时性的)。

所以,即使有个牛逼的黑客破解了某一次通信过程的私钥,其他通信过程的私钥仍然是安全的,因为每个通信过程的私钥都是独立的,这样就保证了「前向安全」。RSA无前向安全性的问题也类似static DH算法,因为其私钥值固定保存在服务器。

2.2.2 ECDHE算法

ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性,避免了DHE算法的大量乘法计算,可以用更快点地计算出公钥及会话密钥。

小红和小明使用 ECDHE 密钥交换算法的过程:

  • 双方事先确定好使用哪种椭圆曲线,和曲线上的基点 G,这两个参数都是公开的;

  • 双方各自随机生成一个随机数作为私钥d,并与基点 G相乘得到公钥Q(Q = dG),此时小红的公私钥为 Q1 和 d1,小明的公私钥为 Q2 和 d2;

  • 双方交换各自的公钥,最后小红计算点(x1,y1) = d1Q2,小明计算点(x2,y2) = d2Q1,由于椭圆曲线上是可以满足乘法交换和结合律,所以 d1Q2 = d1d2G = d2d1G = d2Q1 ,因此双方的 x 坐标是一样的,所以它是共享密钥,也就是会话密钥。

2.2.2 ECDHE TLS握手过程分析

2.2.2.1 TLS第一次握手

客户端发送Client Hello给服务端,并携带客户端TLS版本号/支持的密钥套件/随机数A。这步和RSA是一样的。

2.2.2.2 TLS第二次握手

记录一:Server Hello

服务端发送Server Hello给客户端,并携带确认的TLS 版本号/确认的密码套件/随机数B

已经说过密钥套件格式 = 密钥交换算法 + 签名算法 + WITH + 对称加密算法 + 摘要算法, 如果WITH前只有一个算法则表示密钥交换算法及签名算法都用它。

这里密码套件Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,表示:

  • 密钥交换算法使用ECDHE

  • 签名算法为RSA非对称算法

  • 对称加密算法为GCM分组的密钥长度256的AES

  • 摘要算法为SHA384

记录二:数字证书:Certificate

这个记录中包含数字证书,用于客户端验证服务器的身份是否可信。

记录三:数字证书:Certificate

这个记录是RSA算法握手没有的。
因为服务端选择了 ECDHE 密钥协商算法,所以会在发送完证书后,发送Server Key Exchange消息。
这个过程服务器做了三件事:

  • 选择了名为 x25519 的椭圆曲线,选好了椭圆曲线相当于椭圆曲线基点 G 也定好了,这些都会公开给客户端;

  • 生成随机数作为服务端椭圆曲线的私钥,保留到本地;

  • 根据基点 G 和私钥计算出服务端的椭圆曲线公钥,这个会公开给客户端。

记录四:Server Hello Done

表示二次握手结束。

2.2.2.3 TLS第三次握手

记录一:Client Key Exchange

客户端证书验证通过过,会进行第三次握手。

客户端会生成一个随机数作为客户端椭圆曲线的私钥,然后再根据服务端前面给的信息,生成客户端的椭圆曲线公钥,然后用Client Key Exchange消息发给服务端。

记录二:Change Cipher Spec

至此,双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是,双方都就计算出点(x,y),其中 x 坐标值双方都是一样的,前面说 ECDHE 算法时候,说 x 是会话密钥,但实际应用中,x 还不是最终的会话密钥,因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性。
最终的会话密钥用客户端随机数 + 服务端随机数 + x(ECDHE 算法算出的共享密钥)三个值生成的。

生成对称密钥后,发送Change Cipher Spec消息告诉服务器开始使用对称密钥加密。

记录三:Encrypted Handshake Message

客户端发送Encrypted Handshake Message给服务端,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

2.2.2.4 TLS第四次握手

服务器给客户端发送Change Cipher SpecEncrypted Handshake Message
如果双方都验证加密和解密没问题,那么握手正式完成。

记录一:Change Cipher Spec

服务端发送给客户端,过程同TLS第三次握手。

记录二:Encrypted Handshake Message

服务端发送给客户端,过程同TLS第三次握手。

2.3 RSA和ECDHE握手算法对比

  • RSA 密钥协商算法「不支持」前向保密,ECDHE 密钥协商算法「支持」前向保密;

  • 使用了 RSA 密钥协商算法,TLS 完成四次握手后,才能进行应用数据传输,而对于 ECDHE 算法,客户端可以不用等服务端的最后一次 TLS 握手,就可以提前发出加密的 HTTP 数据,节省了一个消息的往返时间(这个是 RFC 文档规定的,具体原因文档没有说明,所以这点我也不太明白);

  • 使用 ECDHE, 在 TLS 第 2 次握手中,会出现服务器端发出的「Server Key Exchange」消息,而 RSA 握手过程没有该消息;

3. TLS1.3握手过程

TLS1.3只需要1RTT便可建立连接,恢复连接只是0RTT。

可以看到TLS1.3不仅将握手过程的部分信息加密传输了,这个Application Data还可以直接开始传输真实的业务数据。
客户端也是同理,在完成握手的同时,也直接开始传输业务数据。故建立连接只需要1RTT。

优网科技,优秀企业首选的互联网供应服务商

优网科技秉承"专业团队、品质服务" 的经营理念,诚信务实的服务了近万家客户,成为众多世界500强、集团和上市公司的长期合作伙伴!

优网科技成立于2001年,擅长网站建设、网站与各类业务系统深度整合,致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设(品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、DIY体验、720°全景展厅及3D虚拟仿真)、移动端应用(手机站APP开发)、微信定制开发(微信官网、微信商城、企业微信)、微信小程序定制开发等一系列互联网应用服务。


责任编辑:优网科技

版权所有:http://www.uweb.net.cn (优网科技) 转载请注明出处

深入浅出HTTPS:全面解析网站安全的核心技术

日期:2024-10-15 09:28:54 发布人:优网科技


1. 介绍

HTTPS其实就是在TCP及HTTP之间加入了SSL/TLS协议。

解决了HTTP协议以下问题:

  • 信息加密:交互信息无法被窃取

  • 校验机制:无法篡改通信内容,篡改了无法通过校验

  • 身份证书:可信的身份证明

2. TLS1.2握手过程

TLS中基本单位是记录(record),多个记录可以合并到一个TCP包中发送。

2.1 RSA TLS握手

2.1.1 RSA TLS握手过程分析

图中的一个框便是一个记录,可以看到RSA握手分为4步,时延为 2 RTT。

  1. 客户端发起TLS握手请求。

  2. 服务端公钥(TLS证书含有公钥),在握手阶段会传给客户端。

  3. 客户端在生成密钥后,使用服务端公钥加密再传回服务端。

  4. 服务器利用私钥解密,拿到相同的密钥。

最后便可以利用非对称加密协商好的对称密钥进行对称加密传输信息了。

完整握手过程如下图所示。

2.1.1.1 TLS第一次握手

客户端发送Client Hello给服务端,并携带客户端TLS版本号/支持的密钥套件/随机数A

2.2.1.2 TLS第二次握手

记录一:Server Hello

服务端发送Server Hello给客户端,并携带确认的TLS 版本号/确认的密码套件/随机数B

密钥套件格式 = 密钥交换算法 + 签名算法 + WITH + 对称加密算法 + 摘要算法, 如果WITH前只有一个算法则表示密钥交换算法及签名算法都用它。

比如,这里选择的密码套件Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256,其实是:
密钥交换算法及签名算法为RSA非对称算法,对称加密算法为GCM分组的密钥长度128的AES对称算法,摘要算法为SHA256。

记录二:数字证书:Certificate

这个记录中包含数字证书,用于客户端验证服务器的身份是否可信。

记录三:Server Hello Done

表示二次握手结束。

2.2.1.3 客户端验证证书

客户端拿到证书后,需要先验证证书是否可信,才决定是否继续握手。

2.2.1.3.1 数字证书和CA机构

数字证书是一种用于在网络通信和信息安全领域中验证身份的数字文件。它通常包含了一个实体(例如个人、组织、设备等)的公钥及其相关信息,并由可信的数字证书颁发机构(CA,Certificate Authority)签名,以确保证书的真实性和可信度。

数字证书的主要组成部分包括:

  • 公钥:证书中包含了实体的公钥,用于加密和解密数据。这个公钥是与私钥一一对应的,但是私钥通常保持在证书的拥有者手中。

  • 证书拥有者信息:包括证书拥有者的名称、电子邮件地址等身份信息。

  • 数字签名:由证书颁发机构使用自己的(CA)私钥对证书的内容进行签名,以确保证书的完整性和真实性。通过验证签名,可以确保证书没有被篡改,并且确实由颁发机构签发。

  • 证书认证机构(CA)的信息:用于证书链验证

2.2.1.3.2 数字证书签发和验证流程

签发流程

CA会将数字证书涉及的信息打包并摘要计算出Hash值。
用自己的私钥对Hash值进行加密,生成的值便是证书签名Certificate Signature。
最后将 Certificate Signature 添加在文件证书上,形成数字证书;

验证流程

客户端会通过一样的摘要算法对数字证书信息计算出一个Hash值A,再通过预置在系统中的CA公钥解密证书签名Certificate Signature得到Hash值B。
判断A和B是否相等便知道证书是否可信。

2.2.1.3.3 证书链

对于这种三级层级关系的证书的验证过程如下:

  • 客户端收到 baidu.com 的证书后,发现这个证书的签发者不是根证书,就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是,客户端根据 baidu.com 证书中的签发者,找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”,然后向 CA 请求该中间证书。

  • 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的,由于 “GlobalSign Root CA” 没有再上级签发机构,说明它是根证书,也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上,如果有,则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书,如果发现验证通过,就认为该中间证书是可信的。

  • “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后,可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性,如果验证通过,就可以信任 baidu.com 证书。


证书链存在的原因:为了确保根证书的绝对安全性,将根证书隔离地越严格越好,如果根证书失守,那么整个信任链都有问题。

2.2.1.4 TLS第三次握手

客户端成功验证数字证书后,继续握手。

记录一:Client Key Exchange

客户端发送Client Key Exchange给服务端,携带用服务器RSA 公钥加密后的新随机数(pre-master)。

记录二:Change Cipher Spec

此时,客户端和服务端双方都共享了三个随机数,分别是 Client Random、Server Random、pre-master。
客户端和服务端会使用这三个随机数生成AES_128_GCM算法的对称密钥,用于后续消息加密。
生成对称密钥后,发送Change Cipher Spec消息告诉服务器开始使用对称密钥加密。

记录三:Encrypted Handshake Message

客户端发送Encrypted Handshake Message给服务端,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

2.2.1.5 TLS第四次握手

服务器给客户端发送Change Cipher SpecEncrypted Handshake Message
如果双方都验证加密和解密没问题,那么握手正式完成。

记录一:Change Cipher Spec

服务端发送给客户端,过程同TLS第三次握手。

记录二:Encrypted Handshake Message

服务端发送给客户端,过程同TLS第三次握手。

2.1.2 RSA缺陷

RSA 密钥协商算法不支持前向保密。

一旦服务端的私钥泄漏了,过去被第三方截获的所有 TLS 通讯密文都会被破解。因为可以通过私钥解密客户端发送的加密后的pre-master随机数。

2.2 ECDHE TLS握手

ECDHE算法具有前向安全性,所以被广泛使用,RSA算法则使用较少了。

2.2.1 DH 算法

ECDHE算法由DH算法演变而来,核心思想是离散对数。

2.2.1.1 离散对数

离散对数简单介绍下。公式如下。

底数G和模数P是离散对数公开的参数。x是对数,y是整数,用于加密。
知道对数x,可以直接算出整数y。但反过来,知道整数y却很难推算出对数x,特别当模数P是一个很大的质数时。

2.2.1.2 DH算法

现假设小红和小明约定使用 DH 算法来交换密钥,那么基于离散对数,小红和小明需要先确定模数和底数作为算法的参数,这两个参数是公开的,用 P 和 G 来代称。

然后小红和小明各自生成一个随机整数作为私钥,双方的私钥要各自严格保管,不能泄漏,小红的私钥用 a 代称,小明的私钥用 b 代称。

现在小红和小明双方都有了 P 和 G 以及各自的私钥,于是就可以计算出公钥:

小红的公钥记作 A,A = G ^ a ( mod P );
小明的公钥记作 B,B = G ^ b ( mod P );
A 和 B 也是公开的,因为根据离散对数的原理,从真数(A 和 B)反向计算对数 a 和 b 是非常困难的,至少在现有计算机的计算能力是无法破解的,如果量子计算机出来了,那就有可能被破解,当然如果量子计算机真的出来了,那么密钥协商算法就要做大的升级了。

双方交换各自 DH 公钥后,小红手上共有 5 个数:P、G、a、A、B,小明手上也同样共有 5 个数:P、G、b、B、A。

然后小红执行运算:B ^ a ( mod P ),其结果为 K,因为离散对数的幂运算有交换律,所以小明执行运算:A ^ b ( mod P ),得到的结果也是 K。

K 就是小红和小明之间用的对称加密密钥,可以作为会话密钥使用。

2.2.1.3 DHE算法

根据私钥生成的方式,DH 算法分为两种实现:

  • static DH 算法,已废弃

  • DHE 算法,当前使用

static DH 算法里有一方的私钥是静态的,也就说每次密钥协商的时候有一方的私钥都是一样的,一般是服务器方固定,即 a 不变,客户端的私钥则是随机生成的。

于是,DH 交换密钥时就只有客户端的公钥是变化,而服务端公钥是不变的,那么随着时间延长,黑客就会截获海量的密钥协商过程的数据,因为密钥协商的过程有些数据是公开的,黑客就可以依据这些数据暴力破解出服务器的私钥,然后就可以计算出会话密钥了,于是之前截获的加密数据会被破解,所以 static DH 算法不具备前向安全性。

既然固定一方的私钥有被破解的风险,那么干脆就让双方的私钥在每次密钥交换通信时,都是随机生成的、临时的,这个方式也就是 DHE 算法,E 全称是 ephemeral(临时性的)。

所以,即使有个牛逼的黑客破解了某一次通信过程的私钥,其他通信过程的私钥仍然是安全的,因为每个通信过程的私钥都是独立的,这样就保证了「前向安全」。RSA无前向安全性的问题也类似static DH算法,因为其私钥值固定保存在服务器。

2.2.2 ECDHE算法

ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性,避免了DHE算法的大量乘法计算,可以用更快点地计算出公钥及会话密钥。

小红和小明使用 ECDHE 密钥交换算法的过程:

  • 双方事先确定好使用哪种椭圆曲线,和曲线上的基点 G,这两个参数都是公开的;

  • 双方各自随机生成一个随机数作为私钥d,并与基点 G相乘得到公钥Q(Q = dG),此时小红的公私钥为 Q1 和 d1,小明的公私钥为 Q2 和 d2;

  • 双方交换各自的公钥,最后小红计算点(x1,y1) = d1Q2,小明计算点(x2,y2) = d2Q1,由于椭圆曲线上是可以满足乘法交换和结合律,所以 d1Q2 = d1d2G = d2d1G = d2Q1 ,因此双方的 x 坐标是一样的,所以它是共享密钥,也就是会话密钥。

2.2.2 ECDHE TLS握手过程分析

2.2.2.1 TLS第一次握手

客户端发送Client Hello给服务端,并携带客户端TLS版本号/支持的密钥套件/随机数A。这步和RSA是一样的。

2.2.2.2 TLS第二次握手

记录一:Server Hello

服务端发送Server Hello给客户端,并携带确认的TLS 版本号/确认的密码套件/随机数B

已经说过密钥套件格式 = 密钥交换算法 + 签名算法 + WITH + 对称加密算法 + 摘要算法, 如果WITH前只有一个算法则表示密钥交换算法及签名算法都用它。

这里密码套件Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,表示:

  • 密钥交换算法使用ECDHE

  • 签名算法为RSA非对称算法

  • 对称加密算法为GCM分组的密钥长度256的AES

  • 摘要算法为SHA384

记录二:数字证书:Certificate

这个记录中包含数字证书,用于客户端验证服务器的身份是否可信。

记录三:数字证书:Certificate

这个记录是RSA算法握手没有的。
因为服务端选择了 ECDHE 密钥协商算法,所以会在发送完证书后,发送Server Key Exchange消息。
这个过程服务器做了三件事:

  • 选择了名为 x25519 的椭圆曲线,选好了椭圆曲线相当于椭圆曲线基点 G 也定好了,这些都会公开给客户端;

  • 生成随机数作为服务端椭圆曲线的私钥,保留到本地;

  • 根据基点 G 和私钥计算出服务端的椭圆曲线公钥,这个会公开给客户端。

记录四:Server Hello Done

表示二次握手结束。

2.2.2.3 TLS第三次握手

记录一:Client Key Exchange

客户端证书验证通过过,会进行第三次握手。

客户端会生成一个随机数作为客户端椭圆曲线的私钥,然后再根据服务端前面给的信息,生成客户端的椭圆曲线公钥,然后用Client Key Exchange消息发给服务端。

记录二:Change Cipher Spec

至此,双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是,双方都就计算出点(x,y),其中 x 坐标值双方都是一样的,前面说 ECDHE 算法时候,说 x 是会话密钥,但实际应用中,x 还不是最终的会话密钥,因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性。
最终的会话密钥用客户端随机数 + 服务端随机数 + x(ECDHE 算法算出的共享密钥)三个值生成的。

生成对称密钥后,发送Change Cipher Spec消息告诉服务器开始使用对称密钥加密。

记录三:Encrypted Handshake Message

客户端发送Encrypted Handshake Message给服务端,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

2.2.2.4 TLS第四次握手

服务器给客户端发送Change Cipher SpecEncrypted Handshake Message
如果双方都验证加密和解密没问题,那么握手正式完成。

记录一:Change Cipher Spec

服务端发送给客户端,过程同TLS第三次握手。

记录二:Encrypted Handshake Message

服务端发送给客户端,过程同TLS第三次握手。

2.3 RSA和ECDHE握手算法对比

  • RSA 密钥协商算法「不支持」前向保密,ECDHE 密钥协商算法「支持」前向保密;

  • 使用了 RSA 密钥协商算法,TLS 完成四次握手后,才能进行应用数据传输,而对于 ECDHE 算法,客户端可以不用等服务端的最后一次 TLS 握手,就可以提前发出加密的 HTTP 数据,节省了一个消息的往返时间(这个是 RFC 文档规定的,具体原因文档没有说明,所以这点我也不太明白);

  • 使用 ECDHE, 在 TLS 第 2 次握手中,会出现服务器端发出的「Server Key Exchange」消息,而 RSA 握手过程没有该消息;

3. TLS1.3握手过程

TLS1.3只需要1RTT便可建立连接,恢复连接只是0RTT。

可以看到TLS1.3不仅将握手过程的部分信息加密传输了,这个Application Data还可以直接开始传输真实的业务数据。
客户端也是同理,在完成握手的同时,也直接开始传输业务数据。故建立连接只需要1RTT。

责任编辑:优网科技

版权所有:http://www.uweb.net.cn (优网科技) 转载请注明出处

上一篇 返回列表 下一篇
推荐案例
眼光高度决定品牌厚度 !
广州网站建设-大良实验小学系统开发
广州网站建设-大良实验小学系统开发
大良实验小学于1998年成立,占地4万5千多平方米,是顺德区规模的民办学校之一。现有71个教学班,学生3223人,教职员工436人。学校按广东省一级学校标准建设,配有图书馆、舞蹈室、管乐室、多媒体电子琴室、实验室、英语乐园等功能场室36个,还拥有大礼堂、羽毛球馆、生物园、地理园、游泳池和200米塑胶运动场等活动场所。学校先后荣获“广东省一级学校”、“全国少先队红旗大队”、“广东省首届优秀书香校园”、“广东省书法教育名校”、“广东省综合实践样本学校”等光荣称号。
广州网站建设-海天味业公众号开发
广州网站建设-海天味业公众号开发
海天是中国调味品行业的优秀企业,专业的调味品生产和营销企业,历史悠久,是中华人民共和国商务部公布的首批“中华老字号”企业之一。目前生产的产品涵盖酱油、蚝油、酱、醋、料酒、调味汁、鸡精、鸡粉、腐乳等几大系列百余品种300多规格,年产值过百亿元。
广州网站建设-中凯网站建设
广州网站建设-中凯网站建设
中凯(海南)控股集团有限公司本次项目是集团网站建设,与优网科技合作过程中,双方配合默契,保质保量的仅一个月就完成了整站建设。优网科技帮助中凯(海南)快速树立了一个集团专业形象展示,同时网站的设计效果、体验和交互也让中凯(海南)非常满意。
广州网站建设-中国联塑网站建设
广州网站建设-中国联塑网站建设
中国联塑集团控股有限公司(简称:中国联塑,股份代号:2128.HK )是国内大型建材家居产业集团,产品及服务涵盖管道产品、水暖卫浴、整体厨房、整体门窗、装饰板材、净水设备、消防器材、卫生材料、海洋养殖、环境保护、建材家居渠道与服务等领域。
广州网站建设-前海益广网站建设
广州网站建设-前海益广网站建设
深圳前海益广股权投资有限公司成立于2016年04月18日,注册地位于深圳市前海深港合作区前湾一路1号A栋201室,经营范围包括一般经营项目是:股权投资;受托管理股权投资基金;受托资产管理;企业管理咨询、经济信息咨询;投资兴办实业等。
广州网站建设-萨米特高端品牌网站建设
广州网站建设-萨米特高端品牌网站建设
佛山市萨米特陶瓷销售有限公司始于2000年,在陶瓷行业风潮中发展壮大,是新明珠陶瓷集团的核心品牌。萨米特瓷砖注重营销系统的升级与消费体验模式的实施,倡导“设计+生活”的品牌理念,致力于打造有温度,有态度的瓷砖品牌。用设计提高人居价值,以创新驱动行业发展,与全球不同国家和文化背景的消费者共享美好家居。
广州网站建设-欧迪克网站建设
广州网站建设-欧迪克网站建设
佛山市南海欧迪克五金制品有限公司始创于2003年,致力于发展高端硅镁铝合金安全门窗,木铝门窗、阳光房定制,集研发、生产、销售、服务于一体。自创立以来,系列产品畅销大江南北,获得由权威媒体及单位颁发的多项殊荣。目前为止,“欧迪克门窗”的专卖店遍布全国800多个县市及地区,共有1000多家专卖店辐射全国。
广州网站建设-好太太网站建设
广州网站建设-好太太网站建设
好太太集团是一家集研发、生产、销售、服务于一体的智能家居企业,产品与服务涵盖智能晾晒、智能锁、智能电器等众多领域。坐落于广州番禺区,自1999年始便致力于打造 “好太太”品牌,经过将近二十年的发展,如今好太太已成为全球的晾衣架行业研发、生产、销售、服务商,在中国拥有近2000万户家庭在使用好太太产品。好太太集团于2017年主板上市,成为智能晾晒领域首家A股上市企业。
广州网站建设-中山公用水务网站建设
广州网站建设-中山公用水务网站建设
中山公用事业集团股份有限公司成立于1998年,是一家国有控股的上市公司(SZ:000685)。公司坚持“产业经营+资本运营”双轮驱动的战略思路,定位环保水务为核心业务,通过提升环保水务板块的产业经营能力,与资本运营平台协同增效,致力打造行业内有影响力的领先企业,积极担当社会责任和环境保护的公民企业,促成员工实现自身价值的平台企业。
广州网站建设--华标集团物业公众号
广州网站建设--华标集团物业公众号
华标集团物业为了进一步提升服务质量,满足业主的多元化需求,采用微信公众号作为服务平台,为业主提供日常物业缴费、报事报修、社区活动等便利性服务。本次量身定制的微信公众号,旨在打造一个高效、稳定、便捷的线上服务平台,让业主享受到更加贴心、便捷的物业服务。
广州网站建设-欧派家居集团官网建设
广州网站建设-欧派家居集团官网建设
欧派集团官网作为欧派对外展现品牌形象、传达服务理念的重要信息平台,也向用户展示了欧派最新的资讯和相关的售后服务。优网作为欧派集团的信息化战略合作伙伴,本次的官网开发基于专业的设计水平和扎实的技术能力,为欧派的互联网品牌形象全面升级。
广州网站建设-康臣药业网站建设
广州网站建设-康臣药业网站建设
康臣药业集团(HK.01681)是一家主要从事现代中成药及医用成像对比剂研发、生产及营销的现代化制药企业,创立于1997年,于2013年12月19日在香港联合交易所主板上市,旗下拥有广州康臣药业有限公司、康臣药业(内蒙古)有限责任公司、广西玉林制药集团有限责任公司、广州康臣药物研究有限公司等从事药品生产和研发的企业,运营康臣、玉林等知名医药品牌,在国内建有广东广州、内蒙古通辽、广西玉林等3个生产基地,员工逾2000人。

我要投稿

姓名

文章链接

提交即表示你已阅读并同意《个人信息保护声明》

专属顾问 专属顾问
扫码咨询您的优网专属顾问!
专属顾问
马上咨询
联系专属顾问
联系专属顾问
联系专属顾问
扫一扫马上咨询
扫一扫马上咨询

扫一扫马上咨询

和我们在线交谈!
展开菜单
关于我们
优网观点
项目动态
公司新闻
优网学院
常见问题
收起菜单
活动会议应用
答题应用
班车预定应用
应急值班表应用
春节活动应用
活动直播应用
内部培训及任务应用
返回上一级