写点什么

HTTPS 协议

用户头像
IT视界
关注
发布于: 19 小时前

什么是 HTTPS 协议呢?如果大家还没有深刻理解 HTTP 协议,请查找一下我的 HTTP 协议的文章。

HTTP 协议是一个明文传输的协议,也就是说在整个链路中传输的话,可以理解问数据在“裸奔”,在任意一个节点上数据都有可能被人截取,串改。最明显的表现就是访问一个网页的时候,明明网页没有广告,但是在浏览器打开后却又很多广告,这就是串改了响应报文,如果是请求报文被串改那就更严重了,如果操作是银行转账请求,你们的钱可能就会被转到别人的钱包了。

所以 HTTPS 协议就是在 HTTP 协议上加了个安全层。

HTTPS 协议

由于 HTTP 天生“明文”的特点,整个传输过程完全透明,任何人都能在链路中截取、修改或者伪造请求/响应报文,数据不具有可信性。因此就诞生了为安全而生的 HTTPS 协议。

以前使用 HTTP 协议的时候,应用程序往往直接通过内核提供的一些 API 去完成数据的传输,和 TCP 进行交互。

HTTPS 并没有对 HTTP 协议进行任何的修改,而是应用程序不直接和 TCP 进行交互了,变为和 SSL/TSL 安全套接层进行交互,然后安全层在和 TCP 进行交互。

SSL/TSL

SSL 即安全套接层(Secure Sockets Layer),由网景公司于 1994 年发明,IEIF 在 1999 年把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,到今天 TLS 已经发展出了主流的三个版本,分别是 2006 年的 1.1、2008 年的 1.2 ,2018 的 1.3,每个新版本都紧跟密码学的发展和互联网的现状,持续强化安全和性能,已经成为了信息安全领域中的权威标准。

HTTPS 是利用了几个算法来完成加密通道的一个建设的,下面来看一下都有哪些算法

摘要算法

摘要算法能够把任意长度的数据“压缩”成固定长度,而且独一无二的“摘要”字符串,就好像是给这段数据生成了一个数字“指纹”。任意微小的数据差异,都可以生成完全不同的摘要。所以可以通过把明文信息的摘要和明文一起加密进行传输,数据传输到对方之后再解密,重新对数据进行摘要,在对比就能发现数据有没有被篡改。这样就保证了数据的完整性。

加密算法

对称密钥加密算法:

编、解码使用相同密钥的算法,如(AES,RC4,ChaCha20)。

非对称加密算法:

它有两个密钥,一个叫“公钥”,一个叫“私钥”。两个密钥是不同的,公钥可以公开给任何人使用,而私钥必须严格保密。非对称加密可以解决“密钥交换”问题。网站秘密保管私钥,在网上任意分发公钥,你想要登录网站只要用公钥加密就行了,密文只能由私钥持有者才能解密。而黑客因为没有私钥,所以无法破解密文。非对称密钥加密系统通常需要大量的数学运算,比较慢。如(DH,DSA,RSA,ECC)。

私钥和公钥都部署在服务器上,但是私钥不参与网络传输,公钥加密的数据只能用私钥解密,私钥加密的数据只能用公钥解密,所以浏览器给服务器发送用公钥加密的数据是安全的,但服务器给浏览器发送用私钥加密的数据是不安全的,因为公钥是可以被人窃取到的。

TLS 里使用的混合加密方式,即把对称加密和非对称加密结合起来,两者互相取长补短,既能高效的加密解密,又能安全的密钥交换。大致流程如下:

  1. 通信开始的时候使用非对称加密算法如 RSA,ECDHE 先解决密钥交换的问题

  1. 用随机数产生对称算法使用的“会话密钥”,再用公钥加密。会话密钥很短,所以即便使用非对称加密算法也可以很快完成加解密

  1. 对方拿到密文后用私钥解密,取出会话密钥。完成对称密钥的安全交换,后续就使用对称算法完成数据传输

身份验证

数字证书组成:

CA 信息,公钥用户信息,公钥,权威机构签名,有效期

数字证书作用:

  1. 通过数字证书向浏览器证明身份

  2. 数字证书里面包含了公钥

数字证书的申请和验证:

如何申请:

  1. 生成自己的公钥和私钥,服务器自己保留私钥

  2. 向 CA 机构提交公钥,公司,域名信息等待验证

  3. CA 机构通过线上,线下多种途径验证你提交信息的真实性,合法性

  4. 信息审核通过,CA 机构则会向你签发认证的数字证书,包含了公钥,组织信息,CA 信息,有效时间,证书序列号,同时生成一个签名

签名步骤:

hash(你用于申请证书所提交的明文信息)= 信息摘要,CA 再使用私钥对信息摘要进行加密,密文就是证书的数字签名

浏览器如何验证呢?

有了 CA 签名过的数字证书,当浏览器访问服务器时,服务器会返回数字证书给浏览器,浏览器收到证书后会对数字证书进行验证。

首先浏览器读取证书中相关的明文信息,采用 CA 签名时相同的 hash 函数计算得到信息摘要 A,再利用对应的 CA 公钥解密数字签名数据得到信息摘要 B,如果摘要 A 和摘要 B 一致,则可以确认证书是合法的。

下面我们来解析一下这张图:

首先服务器上面会部署公钥和私钥,浏览器和服务器进行数据交互的时候,会先进行三次握手,三次握手完成之后,会进行安全层的握手也就是 HTTPS 的握手。

那么什么是 HTTPS 的握手呢?

客户端会发送请求给服务器,会发送客户端支持的加密套件列表,也就是客户端支持哪些加密算法,服务端同样的,在进行加密通道构建的时候,一定是双方都要支持才能进行加解密,所以服务器端会看一下本地的实现,看客户端提供的加密算法服务器都支不支持,支持的话会从中选择最安全的一个算法,然后告诉客户端选择了哪个加密套件,并且会把公钥数字证书发送给客户端,客户端验证证书合法性,生成一个随机密钥(用于对称加密密钥),并用传过来的公钥进行加密,发送给服务器端,服务器端就可以用私钥进行解密,这样就安全的拿到了对称加密的密钥,这时就可以使用对称加密算法完成数据的双向传输。

到这大家是不是有这样一个疑问,为什么要使用数字证书呢,直接传公钥不行吗?

现在我来解释一下,在之前 TCP 三次握手的时候我说过,客户端要去拿到服务器端的 ip,那如果在拿服务器端 ip 的时候被人截获了我们的 DNS 信息,修改了 DNS 中的 ip 地址,指向了一个黑客自己的服务器,这时候请求和数据就都到达了黑客的服务器,因此要去验证访问的服务器是真的我们要访问的那台服务器,这时候数字证书就派上了用场。

发布于: 19 小时前阅读数: 8
用户头像

IT视界

关注

还未添加个人签名 2021.04.02 加入

致力于帮助所有选择IT行业的人们,希望能通过我的文章使大家少走弯路,踏上坦途

评论

发布
暂无评论
HTTPS协议