-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
yangjin
committed
Jan 7, 2020
1 parent
ebc6deb
commit e57c428
Showing
1 changed file
with
90 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# https | ||
|
||
http 数据提交给 tcp 之后,数据经过用户、路由器、运营商和目标服务器,在这中间的每个环节,数据都有可能被窃取和篡改。 | ||
|
||
https 在协议栈来看,在 TCP 和 HTTP 之间插入了一个安全层,经过安全层的数据都会加密或者解密。所以要搞清楚 https 是如何工作的,就要弄清楚安全层是怎么工作的。 | ||
|
||
总的来说,安全层有两个职责:**对发起 HTTP 请求的数据进行加密操作和对接收到 HTTP 的内容进行解密操作**。 | ||
|
||
## 1. 使用对称加密 | ||
|
||
提到加密,最简单的方式是使用对称加密。所谓**对称加密是指加密和解密都使用的是相同的密钥**。 | ||
|
||
为了让加密更难以破解,让服务器和客户端同时决定密钥,具体过程如下: | ||
|
||
1. 浏览器发送它支持的加密套件(指的就是加密方法)列表和一个随机数 client-random。 | ||
2. 副会起会从加密套件中选取一个加密套件,然后还会生成一个随机数 server-random,并将随机数和加密套件列表返回给浏览器。 | ||
|
||
这样,浏览器和服务器都有相同的随机数,client-random 和 server-random,然后使用相同的方法将 client-random 和 server-random 混合起来生成一个密钥 master-secret。**有了密钥和加密套件之后,就可以进行数据的机密传输了**。 | ||
|
||
第一版 HTTPS 方法虽然能很好的工作,但是随机数 client-random 和 server-random 传输确实明文,这意味这黑客可以拿到协商的加密套件和随机数,由于利用随机数生成密钥的算法是公开的,所以黑客拿到随机数之后,也可以生成密钥,这样数据依然可以被破解。 | ||
|
||
## 2. 使用非对称加密 | ||
|
||
第二版 HTTPS 可以解决这个问题。 | ||
|
||
**非对称加密相当于有 A,B 两把密钥,如果你用 A 来加密,那么只能用 B 来解密;反过来,如果你用 B 来加密,那么只能用 A 来解密。** | ||
|
||
在 HTTPS 中,服务器会将一个密钥以明文的方式发送给浏览器,把这个密钥叫作公钥,服务器自己留下来的叫做私钥。顾名思义,公钥是每个人都能获取到的,而私钥只有服务器才能知道,不对外公开。 | ||
|
||
使用非对称加密的协商过程是: | ||
|
||
1. 浏览器给服务器发送加密套件列表; | ||
2. 服务器选择一个加密套件,因为公钥是给浏览器加密用的,所以会将加密套件和公钥一起发送给浏览器,服务器自己留着私钥。 | ||
|
||
这样浏览器就有了服务器的公钥,在发送数据的时候,可以使用公钥来加密。由于公钥加密的数据只有私钥可以解密,所以即使黑客截获了数据和公钥,他也是无法解密的。 | ||
|
||
因此采用非对称加密,**就能保证浏览器发给服务器的数据是安全的**,看上是很完美,但是会存在两个问题: | ||
|
||
- **非对称加密的效率太低**。这就严重影响了加解密数据的速度,进而影响到用户打开界面的速度; | ||
- **无法保证服务器发送给浏览器的数据是安全的**。因为公钥是通过明文发送的,所以黑客可以劫持,这样服务器使用私钥加密的数据可以被解密,无法保证安全。 | ||
|
||
## 3. 对称加密和非对称加密搭配 | ||
|
||
**数据传输的过程使用对称加密,但是对称加密的密钥使用非对称加密的方式来传输**。client-random + server-random + pre-master = master-secret,三组随机数才生成对称密钥。 | ||
|
||
浏览器生成随机数 pre-master 之后,已经有了公钥,可以通过非对称加密的方式传给服务器的。这样服务器可以使用私钥来解密,并和随机数一起生成相同的 master-secret。 | ||
|
||
**pre-master 是使用公钥加密之后传输的,所以黑客无法获取到 pre-master,这样黑客就无法生成密钥了,也就保证黑客无法破解传输中的数据。** | ||
|
||
## 4. 添加数字证书 | ||
|
||
通过对称和非对称混合的方式,完美的实现数据的加密传输。但是依然存在问题,比如我要打开淘宝,但是黑客通过 DNS 劫持将这个网站的 ip 地址替换成了黑客的 IP 地址,这样访问的其实是黑客的服务器,黑客可以在自己的服务器上实现公钥和私钥。而对于浏览器来说,它完全不知道现在访问的是一个黑客的站点。 | ||
|
||
通过一个例子理解 DNS 劫持: | ||
|
||
一般而言,用户上网的 DNS 服务器都是运营商分配的,所以,在这个节点上,运营商可以为所欲为。 | ||
例如,访问 `http://jiankang.qq.com/index.html`,正常 DNS 应该返回腾讯的 ip,而 DNS 劫持后,会返回一个运营商的中间服务器 ip。访问该服务器会一致性的返回 302,让用户浏览器跳转到预处理好的带广告的网页,在该网页中再通过 iframe 打开用户原来访问的地址。 | ||
|
||
**所以我们还需要服务器想浏览器提供证明“我就是我”**,那怎么证明呢? | ||
|
||
证书,就比如买房子,你需要房管局这个**权威机构**,它给你发一个**证书**:房产证。 | ||
|
||
同理,淘宝哟啊证明这个服务器是淘宝,也需要使用权威机构办法的证书,这个权威机构称为 **CA**(Certificate Authority),颁发的证书称为**数字证书**(Digital Certificate)。 | ||
|
||
对于浏览器来说,数字证书有两个作用:一个是通过数字证书向浏览器证明服务器的身份,另一个是数字证书里面包含了服务器的公钥。 | ||
|
||
相对于第 3 版的 HTTPS,这里有两点改变: | ||
1. 服务器没有直接返回公钥给浏览器,而死返回数字证书,而公钥是包含子在数字证书中的; | ||
2. 在浏览器过一个证书验证的操作,验证了证书之后,才继续后续的流程。 | ||
|
||
通过引入数字证书,就实现了对服务器的认证功能,这样即使黑客伪造了服务器,但是证书是无法伪造的,所以依然无法欺骗用户。 | ||
|
||
### 如何申请证书 | ||
|
||
淘宝向权威机构生成数字证书,通常需要: | ||
- 准备好材料,向 CA 提供公钥、公司、站点等信息,待认证,认证过程可能收费; | ||
- CA 通过线上、线下对材料进行验证; | ||
- 如果审核通过了,CA 就会向淘宝签发数字证书,包含公钥、组织信息、CA 的信息、有效时间、证书序列号等,这些信息都是明文的,同时包含一个 CA 生成的签名。 | ||
|
||
最后那里,CA 通过 **Hash 函数**计算对淘宝提交的信息,并得出**信息摘要**,然后 CA 使用它的**私钥对信息摘要进行加密**,**加密后的密文就是 CA 颁给淘宝的数字证书**。这就相当于房管局在房产证上盖的章。整个章是可以验证的。 | ||
|
||
### 浏览器如何验证数字证书 | ||
|
||
有了 CA 签名过的证书,当浏览器向淘宝发出请求时,服务器会返回数字证书给浏览器。 | ||
|
||
浏览器接收到数字证书之后,首先要读取证书中的明文信息,采用 CA 签名时相同相同的 Hash 函数来计算**信息摘要 A**,燃火在利用 CA 的公钥解密签名数据,得到**信息摘要 B**;对比信息摘要 A 和信息摘要 B,如果一致,则可以确定是合法的证书。 | ||
|
||
## 参考 | ||
|
||
- [HTTPS:让数据传输更安全](https://time.geekbang.org/column/article/156181) |