HTTPS加密原理

今天我们学习一下https加密原理，首先了解一下前置知识

什么是对称加密

用同一个密钥，他可以加密一段信息，也可以对加密的信息解密

什么是非对称加密

就是有两把密钥，一把公钥，一把私钥，用公钥加密的内容必须由私钥进行解密，用私钥加密的内容必须用公钥进行解密

如果https使用对称加密是否可以呢

非对称加密，是必须有双方持有同一个密钥，且不能别别人知道，这样才能保证双方的通讯是安全的

但是这个密钥如何传输呢，比如浏览器和网站，浏览器必须通过网路传输给网站，网站才能得到密钥，同时这个网络传输就有可能别中间人劫持，修改，导致不安全

如果https使用非对称加密是否可以呢

举例还是浏览器和网站之间交互

1. 网站服务器先把自己的公钥传输给浏览器(此时中间人拦截了公钥)
2. 浏览器拿到之后，浏览器向服务器传输数据用公钥解密，此时中间人没有私钥是无法解开的
3. 但是网站服务器再用自己的私钥加密内容，传给浏览器的时候，此时就有问题
4. 由于网站服务器的公钥被中间人已经获取，此时中间人在得到网站服务器的加密内容，直接用拦截的公钥就可以解密，这样还是会导致安全问题

此时就人说可以用2对公钥和私钥解决，我们看看用改良的非对称加密方案，比如

1. 网站服务有自己的私钥A1和公钥A2，浏览器有自己的私钥B1和公钥B2
2. 网站服务器用自己的公钥A2传给浏览器
3. 浏览器把自己的公钥B2传给网站服务器
4. 浏览器传输数据使用公钥A2加密，此时只有网站服务器有私钥A1能解开
5. 同理网站服务器回传的时候用公钥B2假面，此时只要浏览器有私钥B1解开

但是https是没有使用这个加密方式的，原因是因为非对称加密是非常耗时的，此时就要人提出是不是可以用非对称加密和对称加密结合使用

1. 网站服务器有自己的私钥C1和公钥C2
2. 浏览器向网站服务器发送请求，网站服务器把自己的公钥C2传给浏览器
3. 浏览器在用这个公钥C2加密自己的对称加密密钥，传输给网站服务器，只有网站服务器才能解开这个信息
4. 网站服务器通过自己的私钥C1进行解密，获取到对称加密密钥，然后就是用这个密钥进行加密需要传输的信息

上面看上去是没有问题的，但是有大意了，还是有漏洞，比如

1. 网站服务器有自己的私钥D1和公钥D2
2. 浏览器向网站发起请求,网站服务器把公钥D2传给浏览器
3. 中间人把这个公钥D2拦截了，保存下来，然后用自己的公钥E2交给了浏览器
4. 浏览器此时不知道他是中间人伪造的公钥，此时用这个公钥E2，进行加密，传给了网站服务器
5. 此时中间人拦截到了这个用公钥E2加密的内容，然后中间人用自己的私钥E1解密，然后再用之前拦截的公钥D2,进行加密，然后发送给网站服务器

所以上面还是有问题，问题的原因是浏览器无法判断网站传过来的公钥是否是真，此时就出现了数字签证

数字签证

网站在使用https之前，都会向一个CA机构申请一个证书，这个证书包含了持有者的信息，比如公钥，然后服务器把这个公钥传给浏览器就可以了，然后浏览器会验证这个证书是否被篡改的

首先我们看看数字签证的制作过程

数字签名的制作过程

1. CA机构拥有自己的私钥和公钥
2. CA机构对证书的明文进行hash加密
3. hash值后用自己的私钥加密，得到数字签名S

此时证书和数字签名组成了数据证书，这样一份数据证书就可以给网站服务器了

浏览器验证过程

1. 浏览器解析拿过来的证书，获取到明文T和签名S
2. 然后用公钥进行解密签名S，获取到hash值
3. 然后浏览器在把数据进行证书指定的hash算法进行加密，
4. 然后比对两者是否相等，如果相等就是没有被篡改

中间有可能修改整数吗

不能，因为他没有CA机构的公钥，因此无法解密签名，如果中间人修改了明文，最终浏览器会发现和自己加密的hash不一样，就认为是被篡改了

中间是不是可以把整个整数换了

不可以，假设中间人也可以申请一个CA机构的证书，然后拦截网站传给浏览器的证书，用自己的证书，在传给浏览器，这里是不是还有问题呢

其实不是的，因为证书包含了网站的信息，包括域名，浏览器会对这个域名和自己请求的域名进行比对，看看是否一致，如果不一致，就说明被掉包了

为什么之前签名还要进行一次hash呢

其实是为了性能，因为一般非对称加密是非常耗时的，字符串越长就越耗时，因此进行hash加密，就会减少字符串长度，这样加密就会快很多