HTTP与HTTPS的对比

HTTP和HTTPS的对比

结构对比

http：80

https：443

加密过程

对称加密的一种典型方式比如异或加密。但是问题在于server端如何获取密钥，密钥的安全无法保证，密钥没有加密存在被劫持可能。解决方法是先采用非对称加密。

https密钥协商过程:client请求->获得公钥->用公钥加密client的对称密钥->server->解密->server拿到client的对称密钥。至此，双方通信采用对称密钥进行。

为什么不直接采用非对称加密进行传输呢？

原因：非对称加密，效率比较低；对称加密比较快。

密钥协商的过程是SSL/TLS处理的。

因此，简单来说：出于安全考量，先是非对称加密，出于效率考量，再是对称加密。防止数据篡改使用数据摘要和数据签名技术，认证对方服务器可以使用证书。具体的细节在《图解HTTP》。

中间人攻击

中间人攻击的核心思路：中间人没法解开服务器的公钥加密，那中间人就将服务器的公钥替换成自己的公钥，从而用自己的私钥进行解密

考虑如下场景(中间人攻击)：client端的公钥被替换，导致中间服务器获得对称密钥。同时中间服务器帮助client向server端发送cilent的消息并加密。但是整个中间的各种信息中间服务器都是知道的。

机器本身知道访问了中间服务器，再访问server，而用户不知道。

举个例子，我们现在用的Fiddler就相当于这里的中间服务器，不过数据并没有做修改。假如有人注入病毒，这个病毒功能和Fiddler功能类似，但是多做一件事情把请求目标主机换成病毒指定主机，消息经过指定主机效应回来后再把请求的指定主机给改回来。对我们来说是透明的就看不到了。

中间人攻击的解决办法

这里的解决方案就涉及到了两个问题。

1. 远端服务器的身份认证问题。
2. 中间信息被篡改问题。

远端服务器身份认证

客户端发起请求时不是先发数据，客户端发起请求，服务器给ca证书。

有了证书之后，当你的浏览器在访问某个HTTPS网站时，会验证该站点上的CA证书（类似于验证介绍信的公章）。如果浏览器发现该证书没有问题（证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期），那么页面就直接打开。

远端服务器身份认证的关键：公钥证书的摘要和CA公钥解开数字签名一致

中间信息被篡改问题

此时中间人是否还可以伪造证书，将证书上的公钥替换成自己的公钥，自己生成一份呢？此时是没有办法的。

我们来看CA是如何解决中间信息（数字签名）被篡改的问题?

数据摘要=文本->hash->定长的字符序列。该种哈希算法能保证一旦篡改两者的最终字符序列结果不同。但是单纯这么做也能被篡改数据摘要。

光有这样的数据摘要还不够，需要数字签名。也就是在进行哈希加密后对数据摘要再使用私钥进行加密形成数据签名。而此时的私钥是CA私钥。想要替换成中间人自己的公钥就要保证中间人公钥经过hash形成摘要后能通过CA的私钥进行加密，这样中间人的公钥摘要和CA公钥解中间人的数据签名出来的value才能一致。而发生这样的情况除非CA私钥泄漏。

虽然中间人也能获得CA的公钥对摘要进行解密，拿到的只是摘要，但是摘要的原始信息是拿不到的。因此中间人能拿到数字签名但是不能改，一改摘要就会变化，一变发送给客户端客户端就能识别到中间人。

这里的密钥加密使用的是用私钥进行加密，公钥进行解密。

总结

公钥加密，私钥解密。通常用来进行正常的数据通信。

私钥签名，公钥验签。通常用来数据签名认证。

ssl加密流程:

1. 身份验证—通过第三方权威机构（客户端与服务端都信任的机构）颁发CA证书（包含机构信息）
2. 数据加密—混合加密
   1. 生成非对称秘钥（公钥+私钥），通信前将公钥发送给对方，对方使用公钥加密要传输的数据，自己收到后使用私钥进行解密（缺点是效率太低）
   2. 生成对称秘钥，通信前将秘钥交给对方，加解密使用相同秘钥，（缺点是秘钥被劫持就完蛋）

​ 因此使用混合加密，先使用非对称加密，保护对称秘钥的协商过程，协商完毕后，使用协商的对称秘钥加密传输过程。
​ 而ssl加密就是这些的合并，需要被验证身份的一方，生成一对秘钥后，拿着公钥去机构颁发证书，证书中就包含了公钥信息，通信前，将证书发送给对方，对方对证书进行解析，去权威机构进行身份验证，验证通过后，使用公钥加密