blog/2022-06-04-https.md at main

gitea/blog

Archived

This repository has been archived on 2023-11-13. You can view files and clone it, but cannot push or open issues or pull requests.

git 6b53719306 [init] initial commit

2023-06-03 15:58:09 +08:00

11 KiB

Raw Permalink Blame History

layout, title, subtitle, date, author, catalog, header-img, tags

layout

title

subtitle

date

author

catalog

header-img

一、为什么要用https

http协议有很多优点，比如基于tcp/ip，保证了可靠传输；只负责收发，不记录状态；可发送任意格式报文数据，灵活可扩展；另外http还支持压缩传输，分段传输，支持国际化语言以及身份认证等。总的来说，相对于其他协议，http可以很骄傲地说：“我不是针对你们任何一个，我只是说在座的各位都是垃圾”，确实，http有这个实力，但也不是说它是完美的。至少在安全传输方面，http做的并不好，因为它使用明文传输的，很容易被抓包，如果传输的是银行卡密码之类的私密信息，被人获取后果更是不堪设想。https针对http的安全性，做了如下优化提升：

通信使用密文通信，内容不可能被窃听
证明了报文的完整性，防止第三方篡改
验证通信方的身份，拒绝伪装者发送的信息

二、https的全过程

https本质是一种带有身份认证的可信传输过程，中间涉及非常多的概念，比如对称加密，非对称加密，摘要信息完整性校验，数字签名，CA（权威证书颁发机构），证书校验等等，这些概念后续都有比较详细的记录，现在先看下https的一个完整通信过程：

1. 加密算法

从上图可以看出，https协议通信过程中使用了两种加密算法——对称加密和非对称加密。很自然的的一个问题就是为什么非要用两种加密算法，只使用其中一个是否可以呢？答案是可以，可以只使用非对称加密，但是代价很高，你的CPU可能会抗议！

对称加密算法

对称加密算法很好理解，以现实生活中的钥匙和锁为例，一般情况下，一把锁对应唯一一把钥匙。任何人只要拿到钥匙，都能打开这把锁，其特点是算法公开、计算量小、加密速度快、解密效率高，常用的对称加密算法有：AES、DES、Blowfish、CAST、IDEA、RC2、RC5等。

应用到https协议信息的传输过程中，就是服务器和客户端都使用同一个密钥进行加密和解密的，那么就要求通信双方都需要提前获得对称加密的密钥。如果要保证信息传输的安全性，我们就需要考虑怎么做到同时只让服务器和客户端知道密钥，任何其他设备都不能知道呢？这就需要非对称加密算法了！

非对称加密算法

非对称加密算法是单向加密算法，是密钥对的形式存在，一个公钥，可以分发给任何人，另一个是私钥，只能自己保存，绝对不可以泄露。公钥和私钥都可以实现加密信息的功能，但是如果信息被其中一个密钥加密了，就只能使用另一个密钥解密，这就是所谓的单项加密。到这里，就明白了非对称加密的结论性原理，即客户端可以使用公钥进行加密，并发送数据给服务器，即使数据被截获，中间人也无法破解，因为只有服务器有对应的私钥。常用的非对称加密算法有：RSA，DSA，ECC等。

现在看起来很完美，屏蔽了中间攻击，服务器和客户端可以愉快的安全通信了。但是又出现了其他的问题，我怎么确定我拿到的公钥就是服务器给我的？会不会是另一个人发给我的假公钥，我如果把信息以这个公钥加密并发送出去，我的信息就又泄露了。这个时候就需要有个极具公信力人或者机构告诉我们，你拿到的证书是真的，或者是假的，这个就是CA的作用。

2. 摘要信息——Hash

在正式介绍CA之前，还有一个概念需要了解，那就是摘要。所谓的摘要就是一种哈希算法，所谓的哈希算法是一种很神秘的算法，它可以将所有的东西转换成唯一的一个字符串，只要内容没有变化，哈希值就不会发生变化，反之，哈希值一定会发生变化。所以摘要算法可以作为信息完整性校验的工具，判断信息在传输过程中是否被篡改。常用的摘要算法有MD2、MD5、MDC2、SHA（SHA1）和RIPEMD等。

3. 数字签名

了解什么是证书之前，还需要了解签名的概念，因为证书就是由公钥，拥有者的其他信息，以及前两者内容的签名构成的。强烈推荐David Youd在1996年写的一篇文章——What is a Digital Signature?。签名的出现是为了解决“怎么证明Bob是Bob”的问题，Alice想要请求Bob的一个https网页，并收到了Bob的回信，回信中附带了一本证书，那Alice要怎么验证，才能相信这本证书确实是Bob发来的呢？救赎之道就是签名。

签名的过程也很简单，就是将Bob的一些私人信息比如，姓名，地址，国籍以及有效期等，和公钥信息一起做哈希，这样就得到了相应的摘要信息，然后在用私钥（这里的私钥是上一层CA机构的私钥，不要理解成自己的私钥）加密摘要信息，得到签名。将签名附在公钥以及个人信息文档中，就得到了一个被数字签名的证书。Alice拿到这个被签了名的证书之后，再通过校验，就能验证这个公钥是不是Bob发来的。

4. 什么是证书

上一小节数字签名中就说过，证书就是由公钥，拥有者的其他信息，以及前两者内容的签名构成的。证书是数字签名是一种身份认证手段，它能保证发过来的公钥内容是能和签名对应上的，却不能保证一定是真的Bob发过来的。如果要验证这本证书是否真的是Bob发来的，还需要使用CA根证书。既然有根证书，就有子证书，首先粗略了解一下证书的层级：

从最左边的图片可以看到rustle.cc的证书处于最下面，最上一层是根证书（Sectigo AAA），两者之间的都是中间证书颁发机构。中间以及右面的图片是浏览器内置的中间CA机构证书，以及CA根证书。除了根证书之外，所有的证书都是由上一级CA机构颁发的，所以rustle.cc的证书是由上一级CA颁发的，上一级CA证书是由它的上一级颁发的，以此类推，一直到CA根证书，CA根证书是自己颁发的，而且其私钥是绝对保密的。所有的一切都基于CA根证书是绝对可信，也是整个信任链的起始，所以说如果某个CA根证书颁发机构的私钥被泄露了，那也就意味着整个信任体系的崩塌。

5. CA——权威证书颁发机构

CA认证中心是负责签发，管理，认证数字证书的机构，是基于国际互联网平台建立的一个公正，权威，可信赖的第三方组织机构。世界上的CA认证中心不止一家，他们之间的关系在第四小节也有所介绍，可以用如下树状结构来表示：

因为世界上CA机构不止一家，所以还有很多如上所示的树状结构。以rustle.cc这个域名为例，正常情况下申请证书的流程如下：

step 1: 在服务器生成公私钥密钥对，且要保证私钥只有客户端自己拥有
step 2: 在服务器端以自身的信息(国家、机构、域名、邮箱，摘要/加密算法等)为输入，生成证书请求文件csr
step 3: csr包括公钥以及信息，用指定的摘要算法获得csr的哈希值，并用私钥加密得到签名信息
step 4: 把csr证书请求文件以及签名信息给到CA机构，CA会首先校验其签名，然后审核客户端的信息
step 5: 签名以及信息校验没有问题之后，CA会使用自己的私钥生成签名，并和csr一起生成证书文件，下发到客户端

6. 证书校验

至此了解了加密算法，摘要，数字签名，证书以及CA的概念，那么回到第三节《数字签名》部分的问题，Alice应该怎么确认自己接收到的证书确实是Bob发来的？当时说了是使用签名，但是第四节《什么是证书》又说签名本身只能保证文件是正确的，并不能保证确实是Bob发的，也可能是Susan发的，只不过用的是Bob的名字而已。要解决这个问题，还得回到证书本身的构成，我们反复说证书是由公钥，信息以及签名构成，其中信息中有一些加密算法和摘要算法就是为了验证证书有效性而设计的。

为了更清晰的解释如何验证证书的有效性，Bob发来的证书总一般有2级，即中间CA证书和Bob的证书。Alice首先用中间证书的公钥去解密签名，得到Bob证书公钥和信息的哈希值A1，再独单用信息中指定的摘要算法去计算Bob证书的公钥和信息，得到哈希值A2，对比A1和A2是否相等，如果相等则说明Bob的证书确实是由其中间CA证书颁发的；然后再验证Bob的中间CA证书的有效性，同样用浏览器内置的CA根证书的公钥去解密Bob中间证书的签名，会得到中间CA证书的公钥和信息的哈希值B1，再用中间证书中指定的摘要算法，重新单独计算公钥和信息的摘要，得到哈希值B2，比较B1和B2是否相等，如果相等，则证明中间CA证书是可信的。

最后到了浏览器内置的CA根证书，我们之前说过，信任链的起始位置就是CA根证书绝对可信，所以如果验证了Bob发过来的域名证书和中间CA证书都没问题，则完全可以说Alice收到的Bob给过来的证书，确实是Bob发送的。

三、一次https访问完整的抓包过程

（划掉）如下是用wireshark对https的一次抓包过程，不是很完美的地方是，始终抓不到服务器给客户端发证书的报文（划掉）。23年4月13日，将域名绑定IP进行访问，在IP对应的机器上开启tcpdump抓包，拿到完整的过程如下：

11 KiB Raw Permalink Blame History Unescape Escape