【呆萌の笔记】初识HTTPS

前言

我就是那块迟钝の糕同学，我一直都只知道HTTPS是HTTP+SSL/TLS两种协议共同构成的，但是对于其中的机制，可以说是很多环节都充满了各种疑问。这个学期我们开了信息安全课，可惜老师只是讲了一些加密的算法，加上教材的语言真的太深奥了，于是我自己去借了一些书籍查看，最后终于弄清楚了自己的一些疑问。噗！必须要推荐《图解密码技术》这本书啊~（本文也是缓慢补坑）

为什么会出现HTTPS

那当然是因为HTTP有很多缺点，我们可以例举一些（来自图解HTTP这本书142页）：

• 通信不加密，内容可能会被窃听。
• 不验证通信双方身份，可能遭遇伪装。
• 无法证明报文的完整性，可能遭到篡改。

我们的目标当然就是尽力去弥补这几个缺陷，所以我们针对1号缺陷，我们就对通信进行加密。针对2号缺陷，我们就想办法能确定双方的身份。针对3号缺陷，我们就想办法确定报文没有被修改过。

情景假设

下面，我们来假设有两个孩子在通信，一个是Alice小姑娘，还有一个是Bob小男孩（看书上这个例子也是密码学上举例惯用的姓名啊）。

1号：通信の加密

常见加密方式

说到加密，我们就必须先了解一下常用的加密方法：对称加密和非对称加密。
对称加密简单来说就是我用A口令去加密，同样用这个A口令来进行解密。
目前市面上常用的对称加密方法有：DES，AES。

而非对称加密就是我用A口令来加密，但是可以用B口令来进行解密。
目前市面上常用的非对称加密方法有：RSA。

这里的口令其实就是我们所说的密钥啦~

报文应该用什么加密方法

我们首先来分析HTTP的报文格式：报文头+内容主体。报文头一般是比较短的，内容主体内容可能会很长。

刚才介绍到的对称加密方法，我们很容易发现只要我们有那个口令，就能完成加密和解密，所以Alice用口令加密消息后给Bob，Bob拿口令进行解密。但是问题是，口令也要安全传给Bob呀！所以可知，这样其实解决不了根本的问题。

而非对称加密的方法就可以解决这个问题，Alice用A口令进行加密传给Bob，假如Bob自己本来就有A口令对应的B口令，Bob就可以进行解密，这样Alice就不用把口令传给Bob了。

但是我们用脑子想想也知道，很明显非对称加密的方式比对称加密的方式要复杂一些，如果要计算肯定是花费很大。

报文头的内容很短，我们也可以把消息加密的密钥存在这里啊！这样我们可以用非对称方式加密报文头，对称方式加密报文体，这样一来，就很好的保证了安全性，又减少了开销。

公钥和私钥

相信很多童鞋都知道，HTTPS会有公匙和私匙这两个东西的存在。这其实也是一种非对称加密方式里面的实现。

Q：私钥和公钥是什么？
A：公钥很明显，意思就是公共的钥匙，意思是每个人都可以拿到这个钥匙。私钥则是自己的钥匙，永远都不能给别人。

Q：私钥和公钥怎么加密来传输信息的？
A：首先，Alice用Bob的公钥加密了一句我把100块放在你的第一个抽屉里了，随后Bob就用自己的私钥去解开这个加密的消息，得到这个消息。也就是说公钥在这里充当着加密的角色，而私钥才能对应去解密。
如果黑客拿到了Bob的私钥，那么一切都没戏了，但是黑客拿到的是Bob的公钥的话，那他做的就是加密自己写的消息给Bob罢了。

Q：咦？真的会有这种奇怪的加密方法吗？能举个例子吗
A：最常见的公钥密码算法就是RSA加密方法了。

密文 = 明文^E mod N （RSA加密）
E和N的组合是公钥。

密文 = 明文^D mod N （RSA解密）
D和N的组合就是私钥。

2号：身份の确认 & 3号：报文の保护

以上，我们解决了消息加密的问题。但是我们无法确定，和Alice在进行交流的真的是Bob吗？和Bob交流的又真的是Alice吗？
如果一开始Bob在发布自己的公钥的时候，来了一个攻击者Mallory把这个公钥换成了自己的公钥给Alice，那么Alice就会用Mallory的公钥来加密，那么信息就会暴露了。
所以我们必须要进行身份的确认。

补充知识：单向散列函数

情景假设：Alice熬夜几天辛苦的把代码写完了，倒头就睡。但是第二天她起来要上交代码的时候，如何判断程序是不是被人更改过了什么地方呢？

单向散列函数拥有：一个输入（消息）、一个输出（散列值）。
无论这个输入有多长，输出的长度总是固定的。

所以我们可以让Alice给她的代码用这个单向散列函数来生成一个输出，这样保留好这个输出值。第二天只要再用函数生成一个输出，对比一下就知道是不是有变化了。

消息验证码

简称为MAC，是一种确认完整性并进行认证的技术。
完整验证码的操作需要任意长度的消息、发送者与接收者之间的共享密钥（可以输出固定长度的数据，即MAC值）。
它的机制与单向散列函数比较类似，所以在上面我们先引入了这个概念。我们可以理解为:

消息认证码是一种与密钥相关的单项散列函数

所以两者区别在于：
消息---（单项散列函数）------>散列值
消息---（消息认证码+密钥）--->MAC值

下面插一个我自己画的消息验证码小剧场：

消息验证码存在的问题:
重放攻击
假设Mallory去Alice银行向自己在Bob银行的账号存100块。
Alice把这个消息算出MAC值后把消息一起给了Bob银行，然后Bob银行发现是Alice银行发的，且内容也是正确的。
假如Mallory把这个消息重复发N次，那Bob每次肯定都会给Mallory的账号打钱啊。

解决方法:

1. 序号：每次发送消息赋予一个递增的序号，计算MAC值时这个序号也包括在其中。
2. 时间戳：每次发送消息包含当前时间。

第三方证明
Bob收到了Alice的消息，但是无法证明这条消息来自Alice，如果有一个第三方证明Victor的话就好了。但是他要介入就必须知道这个共享密钥，这样一来消息验证码的安全性也会遭到威胁。所以消息验证码无法弥补这个缺陷。

否认
Bob收到了Alice的消息“我Alice于今日向借了Bob100块”，但是Alice否认这条消息是她发的，因为她可以说这个消息是Bob自己生成的。而由于没有第三个人能知道这个事情，所以Bob证明不了这个消息就是Alice发的，而第三者也无法判断真假。

数字签名

消息验证码出现缺陷就是因为使用了只有两个人之间才知道的密钥，这样无法通过第三方来验证。
数字签名的机制其实和密钥与公钥的机制非常类似，相当于是“反过来用”的。Alice用签名密钥生成消息签名，Bob要验证数字签名，而第三方也和Bob一样可以对签名进行验证，所以Bob和第三方都拥有验证密钥。
两种生成和验证数字签名的方法:

1. 直接对消息签名：也就是上面讲的那个意思。
2. 对消息的散列值签名：就是Alice要先算出消息的散列值，用私钥对散列值进行加密，再把消息和签名发给Bob。

反过头来，我们可以发现数字签名能解决“否认”这个问题。
SSL/TLS在认证服务器的身份是否合法的时候，就是加上了数字签名的公钥来验证。

中间人攻击
Alice和Bob在通信的时候，黑客介入它们之中，面对Alice的时候伪装成是Bob，面对Bob的时候又装作是Alice，这样能够在不破解签名算法的前提下进行攻击。
破解方法是确认自己的公钥是不是真的属于自己的目的对象（比如：Alice打电话直接问Bob）。但是往往确认的内容会很多，我们可以生成散列值来确认。而实际上，公钥密码的软件可以显示公钥的散列值，即指纹。

证书

证书可以解决让Alice知道自己拿到的钥匙到底是不是Bob得，这样就可以防御中间人攻击。

证书实质是一个数据结构，是一种由一个可信任的权威机构签署的数据集合。

而证书本身也分为很多种，常见的比如：PKI证书、PGP证书等。
数字证书举例（模拟教材画的图，其中CA是指签证机构）：

Q：那么Alice怎么确定手上的公钥匙Bob的呢？
A：Alice可以向Bob/证书机构索要公钥证书，然后Alice拿签证机构（CA）的公钥去验证这个签名，就可以获得Bob真实的公钥。

SSL/TLS协议

SSL/TLS协议在网络层次中的位置：

Q:SSL协议和TLS协议的关系
A：TLS是SSL 3.0版本上的升级而来的。

Q:SSL协议和TLS协议只能搭配HTTP使用吗
A：显然不是的，它们可以搭配很多协议。比如搭配发送邮件的SMTP协议和接受邮件的POP协议来使用。

SSL/TLS提供通信密码框架

在前文中我们讲到的一些技术，搭配起来就能够增加HTTP协议的安全性，但是这些技术里面也有很多不同的加密算法，比如分享公钥我们可以用公钥算法也可以用Diffie-Hellmanfan方法，这个是我们自己可以自由搭配选择的，哪个部分的方法很弱，我们就可以再替换那个部分的方法。
但是如果完全客户自定义了，很可能会出现沟通的障碍，因为接收方和发送方的加密解密方法应该是配套的。所以官方提供了一些加密套餐组合，叫做密码套件，供我们选择。