通俗讲解 HTTPS

为什么要用 HTTPS

HTTP 是明文传输,任何人都能窃听到,甚至篡改。

HTTPS 可以有效防止窃听和篡改,能极大提高网站的安全性。

HTTPS 如何保障安全性

加密传输数据

HTTPS 会先将数据进行加密再传输,在网络中传输的时候任何人都只能捕获到加密后的数据。而只有拥有相应的秘钥才能解开数据。

那这里就有了新的问题:数据要怎么加密,用哪种加密方法来加密,客户端和服务端怎么协商确定秘钥,同时保证秘钥不被第三方所知道。

对称加密与非对称加密

先简单介绍两种加密的方式:对称加密和非对称加密。

顾名思义,对称加密就是加密和解密时使用的是相同的秘钥,优点是速度快。缺点是任意两个通信的实体之间都要维护他们彼此间通信的秘钥,而维护这么多的秘钥的成本太大了。

非对称加密就是加密和解密使用的是不同的秘钥,分别称之为公钥和私钥。公钥可以公开出来让所有人知道;私钥必须保存好,不能让其他人知道。非对称加密的特点是用公钥加密的数据只能用私钥解密,用私钥加密的数据只能用公钥解密。缺点是速度慢。

于是,我们可以这样操作:

客户端随机生成一个秘钥 A,使用服务端的公钥加密后发送给服务端。
服务端收到后,用自己的私钥进行解密获得 A。
服务端告诉客户端自己已经获得了 A。
这样客户端和服务端就都得到了一个秘钥 A,且不为其他人所知。
秘钥 A 只在本次通信过程中有效。

随后客户端每次发送数据前,都用秘钥 A 进行对称加密,服务端收到后都用秘钥 A 进行解密。
服务端发送数据给客户端时,也采用类似的操作。
复制代码

通过这样的操作,我们利用非对称加密来达到协商和确定好对称加密的秘钥 A,同时又利用了对称加密速度快的特点。

实际上 HTTPS 协商秘钥 A 的过程会比这个更复杂。但本质都是利用非对称加密来达到协商的目的。

这里实际上就有了一个新的问题:客户端怎么拿到服务端的公钥,同时确保这就是服务端的公钥而不是其他人伪造的。

HTTPS 证书

当我们访问一个 HTTPS 的网站时,服务端会下发一个 HTTPS 证书给我们。证书里面就包含了服务端的公钥,同时还有其他信息:证书所属的域名、颁发的机构、何时生效、何时过期等。

那现在问题就是我们如何确认一个证书是不是有效的,而且是不是我们访问的服务端发给我们的。

这里就牵扯到了 HTTPS 证书的生成。

简单说明一下 CA(证书颁发机构),CA 专门管理证书的申请和颁发。

申请证书的过程如下:

服务端向 CA 申请自己的 HTTPS 证书,
CA 审核通过后,就会将服务端的域名、公钥、证书的有效期等信息写到证书里。
同时 CA 会对证书里的信息做一个哈希获得一个哈希值,
用自己的秘钥对这个哈希值进行加密获得一个加密串,
并把加密串也写到证书里。这一过程称之为签名。
(签名就是证明这证书的确是 CA 发的,CA 为证书进行背书。)

现在,当我们访问网站后收到一个证书时,
首先用 CA 的公钥对加密串进行解密,得到加密前的哈希值。
再对证书本身的数据做一个哈希,如果这两个哈希值是一致的说明证书有效。
同时还要注意证书是否在有效期内。
通过以上校验,我们就可以认为这的确是我们期望的服务端下发的证书。

假设有人伪造了证书,假装自己是服务端,
由于他没有 CA 的秘钥,也就无法构造出与伪造数据吻合的加密串。
我们只要用 CA 的公钥对加密串一解密,发现哈希值不一致,就可以认定这是伪造的。
复制代码

这里又牵出了新的问题:我们怎么拿到 CA 的公钥。

全球只有为数不多的几个顶级 CA 有资格进行 HTTPS 证书的颁发。

所以操作系统和浏览器会预装这些 CA 的证书(包含了 CA 的公钥)。也就省去我们获取 CA 公钥的步骤和获取过程可能存在的伪造。

这里也可以看出 CA 证书是多么重要。如果我们电脑中安装了恶意的 CA 证书,而这个 CA 又故意或无意签发了大量恶意服务端的证书,那我们即便使用了 HTTPS 也无法保证安全通信。

客户端证书

大部分时候,我们都是从服务端拿数据,所以主要保证服务端是我们要访问的,也就是服务端要配置 HTTPS 证书。

如果为了让服务端确认客户端的确是谁,在大多数情况下使用“账号+密码”或“手机号+短信验证码”已经足够了。

为每个客户端都配置 HTTPS 证书,一个是申请证书本身需要费用;一个是申请的门槛较高,不是每个用户都能做到。

也因此,只要服务端配置了 HTTPS 证书,在大多数情况下已经足够安全了。

但是,对于某些对安全性要求极高的网站来说,他们也会要求客户端要安装 HTTPS 证书。

比如银行网上转账就是一个十分敏感的操作。通常在我们申请银行卡的时候会得到一个 U 盾。

U 盾里面实际上也是一个 HTTPS 证书,用于证明“我就是我”。

只是这个证书是由银行自己颁发的。(实际上要像 CA 那样发布证书是很容易的,但是只有少数权威的 CA 才被操作系统和浏览器所认可。)

当我们要进行网上转账的时候,就必须把 U 盾插入到电脑上,访问银行的相关网站时,就会把 U 盾中的证书带上去。

银行的服务端在收到我们的证书,就用自己的私钥进行解密,也就能确认我们的身份了。

Ref

深入浅出 HTTPS

转载于:https://juejin.im/post/5ae324fa518825671d204d30

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
三次握手是TCP建立连接的过程。为了确保通信的可靠性,需要进行三次握手。第一次握手,客户端发送一个请求连接的报文段给服务器,并且等待确认。第二次握手,服务器收到请求后,确认连接,并发送一个响应报文段给客户端。第三次握手,客户端收到服务器的确认后,再次确认连接。这样,双方都确认了对方可以接收和发送数据,建立了可靠的连接。 四次挥手是TCP关闭连接的过程。为了保证数据的完整传输,需要进行四次挥手。第一次挥手,当一方决定关闭连接时,发送一个带有FIN标志的报文段给对方。第二次挥手,对方收到关闭请求后,发送一个确认报文段给发起关闭的一方。第三次挥手,对方发送一个带有FIN标志的报文段给发起关闭的一方。第四次挥手,发起关闭的一方收到对方的关闭请求后,发送一个确认报文段给对方,完成关闭连接的过程。 所以,简单来说,三次握手是为了建立连接,四次挥手是为了关闭连接,确保数据的可靠传输。 [2 [3<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *3* [TCP三次握手与四次挥手的通俗解释](https://blog.csdn.net/qq_34533957/article/details/108856020)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] - *2* [三次握手于四次挥手.docx](https://download.csdn.net/download/u013769717/12815580)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT3_1"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值