ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

HTTPS 加密原理与 CA 数字证书:从对称加密到完整通信流程

HTTPS 加密原理与 CA 数字证书:从对称加密到完整通信流程 HTTPS 加密原理与 CA 数字证书从对称加密到完整通信流程一、HTTPS是什么二、加密基础1. 数字摘要2. 数字签名三、HTTPS加密方案演进方案一对称加密方案二只使用非对称加密方案三双方都使用非对称加密方案四非对称加密 对称加密方案四仍存在的中间人攻击四、CA数字证书五、HTTPS完整通信流程一、HTTPS是什么HTTPS就是在HTTP的基础上加了一层加密层。加密是在传输层以下加密传输的在应用层是明文的。加密就是原始数据通过密钥加密后得到密文然后密文再通过密钥就可以解密得到原始数据。服务端S和用户端C进行HTTPS通信时若通信内容涉及密码等需要加密的敏感数据服务端会拥有自己的非对称密钥对私钥由自身妥善留存公钥用于对外传输一个公钥一个密钥公钥和密钥必须成对。二、加密基础1. 数字摘要数字摘要也叫数字指纹它的基本原理是利用单向散列Hash函数对信息运算生成一串固定长度的数字摘要可以实现把一大篇文章或者小文本甚至一个字符利用hash形成一个固定长度的字符串摘要都是等长的。这个数字签名和文章基本上是1:1的就是你文章有一点改动都会使这个数字签名发生改变。所以可以用来对比两个文件是否是同一个文件同一个文件经过hash就会得到相同的数列不一样的文件非常大的概率会得到不同的序列。它并不是加密机制不存在解密过程很难从摘要反推原始信息主要用于判断数据是否被篡改。常见算法包括MD5、SHA1、SHA256、SHA512由于是将无限的信息映射为有限长度输出理论上会存在哈希碰撞也就是不同信息算出相同摘要MD5和SHA1已被证实可以人为构造碰撞安全性较差SHA256、SHA512更为安全。和加密算法最大区别就是摘要单向不可解密只适合做数据对比校验不能还原原始明文。2. 数字签名数字签名就是把你hash得到的序列再经过加密得到的就是数字签名。在网络通信中我们要解决的主要就是1. 内容被监听2. 内容被篡改。三、HTTPS加密方案演进方案一对称加密通信双方客户端与服务器使用同一套密钥完成加解密客户端利用密钥把明文加密为密文后在网络中传输即便黑客截获密文没有密钥就无法解析真实内容以此保障数据安全。但该方案存在明显短板服务器要对接众多客户端就需要为每个客户端分配专属密钥维护客户端与密钥的对应关系成本很高。同时最大难点是如何安全分发共享密钥若明文传输密钥会被黑客截获若加密传输密钥又需要提前拥有另一密钥陷入鸡生蛋、蛋生鸡的循环困境。所以在进行正常的加密通信之前要解决的是对方怎么安全拿到密钥所以单纯的对称加密行不通。方案二只使用非对称加密服务器将公钥明文发送给客户端客户端使用该公钥加密数据后发给服务器该方向的数据只有服务器持有的私钥能够解密客户端到服务器这条链路看似安全。但公钥本身是明文传输所有人都可以获取服务器如果用私钥加密返回给客户端的数据拦截到公钥的中间人就可以利用公钥解开服务器下发的报文无法保障服务器到客户端方向的数据安全同时单纯依靠这一组公私密钥也无法完整实现双向安全通信。方案三双方都使用非对称加密服务端持有公钥S与私钥S’客户端持有公钥C与私钥C’通信时双方先明文互相交换公钥客户端发送数据使用服务端公钥S加密只能由服务端私钥S’解密服务端返回数据使用客户端公钥C加密只能由客户端私钥C’解密看似实现双向加密通信。但非对称加密运算开销大整体执行效率很低同时公钥为明文传输依旧无法抵御中间人攻击存在安全隐患。方案三看似没有问题但是实际上仍然有安全问题然后双方都要解密会导致效率低下。方案四非对称加密 对称加密解决效率问题结合非对称加密与对称加密。服务端持有非对称公钥S和私钥S’客户端发起HTTPS请求拿到服务端明文传输的公钥S客户端本地随机生成一份对称密钥C使用公钥S对该对称密钥C进行加密后发送给服务器。中间人即便截获这份密文因为没有私钥S’不能解密拿到对称密钥C。服务器收到密文后通过自身私钥S’解密还原得到客户端生成的对称密钥C之后客户端与服务器之间全部使用对称密钥C完成业务数据的加解密通信。充分利用对称加密运算速度快的优势仅密钥协商阶段使用开销更大的非对称加密兼顾安全与传输效率。方案四仍存在的中间人攻击客户端向服务器发起连接请求之后服务器会将自身的公钥S通过明文报文的方式传输给客户端这份报文在网络传输途中会被中间人劫持中间人提取并保存报文里真实的服务端公钥S随后将报文中的公钥替换成中间人自己的公钥M再把这份经过篡改的伪造报文转发给客户端。客户端收到报文之后没有办法校验公钥的真实来源便误以为接收到的公钥M就是目标服务器的公钥于是客户端在本地随机生成本次会话所使用的对称密钥X使用中间人公钥M对对称密钥X进行加密生成密文报文向外发送意图传递给服务器。该报文会再次途经中间人并被截获中间人调用自己的私钥M’完成解密直接获取到明文状态的对称密钥X至此中间人就掌握了后续双方全部通信所依赖的会话密钥。接着中间人取出此前保存的真实服务端公钥S使用公钥S对对称密钥X重新加密组装成全新的密文报文转发给真正的服务器。服务器接收到报文后使用自身私钥S’解密顺利得到对称密钥X服务器全程无法感知密钥已经被第三方窃取。在这之后客户端和服务器双方都会使用对称密钥X开展加密通信客户端发出的数据会被中间人截获中间人可以使用密钥X解密读取全部报文内容甚至能够修改报文数据完成操作之后再使用X重新加密报文转发给服务器。服务器返回的响应数据同样会经过中间人遭受窃听与篡改客户端与服务器始终认为双方正在进行安全的加密通信但实际上所有传输的流量都完全处于中间人掌控之下。产生该漏洞的根本原因在于公钥以明文形式在网络中传递客户端缺少可靠的验证手段无法确认收到的公钥确实来自目标服务器。四、CA数字证书为了解决公钥明文传输带来的中间人攻击漏洞HTTPS引入了CA数字证书这套解决方案。服务端在正式对外提供HTTPS服务之前会先生成属于自己的公钥与私钥密钥对将公钥、网站域名、申请者身份等信息封装在证书申请文件CSR当中向权威的CA数字证书认证机构提交证书申请。CA机构会先审核服务端的真实身份信息审核通过之后就会生成一份完整数字证书这份证书由两大部分组成一部分是证书明文信息里面存放着服务端公钥、网站域名、证书发布机构、证书有效期、证书所有者等关键内容。另一部分就是CA机构生成的数字签名。数字签名的生成流程是CA机构对证书全部明文信息执行哈希散列运算计算出数据摘要再使用CA自身独有的私钥对这份哈希摘要做非对称加密加密之后的结果就是数字签名。当客户端向服务端发起网络连接请求的时候服务端返回给客户端的不再是裸露的单独公钥而是一整份经过CA签发的完整数字证书。客户端拿到证书之后会把证书拆分为证书明文信息和CA的数字签名两个部分。客户端操作系统或者浏览器内部已经预先内置了各个可信CA机构对应的公钥客户端就使用这份预装可信CA公钥去解密证书携带的数字签名解密之后可以得到CA当初计算出来的原始哈希摘要。与此同时客户端会采用和CA签名时完全相同的哈希算法重新对证书里面的明文信息做哈希运算本地计算出新的一份哈希摘要随后客户端将解密签名得到的哈希摘要与本地重新计算得到的哈希摘要进行对比。如果两份哈希摘要完全相等就能够证明证书传输途中没有被中间人篡改证书内携带的服务端公钥是真实可信的。这里的核心关键点在于数字签名只能由CA机构的私钥加密生成中间人即便劫持网络报文、篡改证书里的公钥或者其他明文内容中间人没有CA机构的私钥就无法伪造出合法有效的数字签名。篡改之后的明文经过哈希运算会得到完全不一样的摘要伪造的签名也无法被浏览器内置的CA公钥正常解密。一旦两份哈希摘要比对不一致客户端就可以判定证书已经遭到篡改当前存在中间人攻击风险会立刻终止本次通信连接并抛出安全告警。确认证书校验全部通过之后客户端才会从合法证书当中取出服务端真实公钥继续后续会话对称密钥的协商流程。依靠非对称加密、对称加密加上CA证书认证三者相结合的这套机制就可以从根源抵御中间人篡改公钥的攻击以此保障HTTPS整个通信过程的身份可信与数据完整安全。五、HTTPS完整通信流程客户端向服务器发送建立连接请求请求经过中间网络设备转发到达服务器。服务器收到连接请求返回携带证书的建立连接响应响应经过中间网络设备转发给到客户端。客户端拿到服务器返回的证书依次执行校验检查证书有效期检查证书发布机构是否在系统可信列表使用CA公钥解密证书签名得到hash1本地计算证书内容得到hash2对比hash1与hash2。证书全部校验通过客户端从证书中取出服务器公钥。客户端本地随机生成对称会话密钥使用服务器公钥加密该会话密钥发送密文请求报文经过中间网络转发至服务器。服务器使用自身私钥解密报文获取到客户端生成的对称会话密钥。后续通信客户端使用该对称密钥加密业务请求将密文发出服务器收到密文用相同会话密钥解密执行业务处理。服务器处理完毕使用这套对称密钥加密响应数据回传密文响应。客户端接收密文响应使用会话密钥解密获取服务器返回数据往复完成业务交互。
返回列表