浅谈HTTPS/TLS

HTTPS 协议(Hyper Text Transfer Protocol Secure),是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的,也是用 TCP 作为底层协议,并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443.

HTTPS 协议中,SSL 通道通常使用基于密钥的加密算法,密钥长度通常是 40 比特或 128 比特。

SSL 和 TLS 的区别?

SSL 和 TLS 没有太大的区别。

SSL 指安全套接字协议(Secure Sockets Layer),首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本,SSL 1.0 从未面世,SSL 2.0 则具有较大的缺陷(DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption)。很快,在 1999 年,SSL 3.0 进一步升级,新版本被命名为 TLS 1.0。因此,TLS 是基于 SSL 之上的,但由于习惯叫法,通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

TCP三次握手和四次挥手

image-20220325171059895

HTTPS如何保证安全?

使用TLS来加密传输,来看传输图

tls

如图先经历TCP三次握手,然后在进行TLS握手

  1. 浏览器向服务器发起请求,服务器在接收到请求之后,返回证书和密钥

  2. 浏览器向第三方证书机构验证证书是否合法,如果不合法浏览器将会弹出警告页面,让用户选择是否继续访问

  3. 如果证书合法浏览器生成随机串,使用公钥加密发送给服务器,服务器使用私钥解密出随机串,服务器使用随机串加密内容返回给客户端

  4. 之后客户端和服务器端都将通过随机串进行对称加密

抓包查看

image-20220325162417484

总的来说,难点在于第一次 传送公钥的安全性(使用CA来解决)

为什么需要证书认证机构(CA)?

首先,我们消息是使用对称加密 但是秘钥A(对称加密使用的秘钥)传输就成了问题,于是我们用非对称加密去加密秘钥A,但是非对称加密的公钥需要给客户端,这个时候存在公钥被篡改问题(黑客抢先一步发送给客户端),但是如果使用CA的证书(证书捆绑公钥)给客户端,客户端就知道谁才是真正的服务器了。

image-20220325165118813

简单来说 CA的出现是为了能准确的把服务器公钥传递给客户端,客户端接收的一定是服务器的公钥!

数字签名

数字签名要解决的问题,是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖,就是靠数字签名技术。

数字签名,是 CA 在给服务器颁发证书时,使用散列+加密的组合技术,在证书上盖个章,以此来提供验伪的功能。具体行为如下:

CA 知道服务器的公钥(就是我们要给客户端的公钥),对该公钥采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密,并附在证书下方,发送给服务器。现在服务器将该证书发送给客户端,客户端需要验证该证书的身份。客户端找到第三方机构 CA,获知 CA 的公钥(获取CA公钥是不安全的,具体看下一节),并用 CA 公钥对证书的签名进行解密,获得了 CA 生成的摘要。

客户端对证书数据(也就是服务器的公钥)做相同的散列处理,得到摘要,并将该摘要与之前从签名中解码出的摘要做对比,如果相同,则身份验证成功;否则验证失败。

那浏览器是如何保证证书验证的过程是安全的呢?

浏览器在向证书认证中心验证证书的过程使用的也是非对称加密,这里想要让公钥能够安全的转交给客户端,是非常困难的。

所以浏览器的开发商通常会在浏览器内部植入常用认证机构的公开密钥

如果删除证书,那么浏览器将把网站识别为不安全

image-20220325170108685

image-20220325170123597

image-20220325170231591

版权声明:
作者:乘风归去
链接:https://www.lightr.cn/archives/1385.html
来源:乘风小栈
文章版权归作者所有,未经允许请勿转载。

THE END
分享
二维码
打赏
< <上一篇
下一篇>>
文章目录
关闭
目 录