type
status
date
slug
summary
tags
category
icon
password
HTTPS 的前世今生
什么是 HTTPS？
超文本传输协议安全 (HTTPS) 是 HTTP 的安全版本，HTTP 是用于在 Web 浏览器和网站之间发送数据的主要协议。HTTPS 经过加密，以提高数据传输的安全性。当用户传输敏感数据（例如通过登录银行账户、电子邮件服务或健康保险提供商）时，这一点尤其重要。
为什么需要加密？
因为 http 的内容是明文传输的，明文数据会经过路由器，代理服务器，wifi 热点等节点传输，如果在数据传输的过程中被劫持了（中间人劫持），那么传输的内容就完全的暴露。劫持这还可以修改其中的数据并且不会被传输双方发现。所以我们需要对传输的数据进行加密。我们来看一个例子：
加密前（HTTP 明文传输）：
加密后（HTTPS 加密传输）：
对称加密算法和非对称加密算法
在具体解释 https 是如何进行加密的我们先需要知道什么是对称加密算法和非对称加密算法
什么是对称加密算法？
简单的来说就是加密的时候使用的密钥和解密的时候使用的密钥是相同的这就是对称加密算法。
对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。
什么是非对称加密算法？
非对称加密就是加密和解密使用的不是相同的密钥：只有同一对公钥-私钥对才能正常加解密。
非对称机密算法的的特点是更加安全，但是加密解密的过程花费的资源更多
HTTPS 加密剖析
了解完加密的算法后我们将一步一步来剖析 https 加密的过程
使用对称加密算法是否可以？
如果只有通信双方持有加密的密钥并且通信过程是绝对安全那么对称加密算法是可以的。但是，加密的密钥只能通过通信的某一方生成并传输给另一方。但是在传输的过程中密钥被劫持了（中间人攻击），劫持人通过劫持的密钥就能肆无忌惮解密传输的数据或者修改数据内容在传递给另一方。所以只使用对称加密算法是行不通的。
目前存在问题的地方是因为加密解密使用了同一密钥如果被劫持了，劫持人就能通过密钥进行对数据的操作。如果加密解密的密钥不是同一个呢？所以我们这里就会想到是不是可以使用非对称加密算呢？
使用非对称机密算法是否可以？
使用非对称加密算法的第一步也是需要服务器将公钥传输浏览器（这里为了解释更加明了，所以通信双方设定为浏览器和服务器），然后在传输数据的时候浏览器通过服务器的公钥对数据进行加密，然后服务器通过自己的私钥进行解密。但是在这个过程中只解决的浏览器发送给服务器的数据加密问题。服务器发送给浏览器的数据要怎么办呢？到这里我们自然会想到如果一对公钥私钥解决不了那么我们是否可以使用两对呢？所以接下来我们就描述下两队公钥密钥的加密过程。
改良版的非对称机密算法，似乎可以？
- 浏览器拥有 公钥A && 私钥A， 服务器拥有 公钥B && 私钥B
- 浏览器将自己的公钥A传输给服务器， 服务器将自己的公钥B传输给浏览器
- 浏览器通过公钥B对数据进行加密传输给服务器然后服务器通过私钥B进行解密。因为只有服务器拥有私钥B，所以这条数据传输安全
- 服务器通过公钥A对数据进行加密传输给浏览器然后浏览器通过私钥A进行解密。因为只有浏览器拥有私钥A，所以这条数据传输安全
似乎可以！（抛开中间人劫持替换密钥漏洞，下文会讲）为什么 HTTPS 没有使用这种加密方式？没有使用这种加密的方式是因为非对称加密算法是非常耗时的（对比与对称加密算法）非对称加密算法安全耗时，对称加密算法快速又不安全。我们是不是考虑可以将他们结合起来使用呢？
非对称加密算法 && 对称加密算法
- 服务器拥有 公钥A && 私钥A
- 浏览器对服务器发起请求，服务器将公钥A传输给浏览器
- 浏览器生成密钥x然后通过公钥A进行加密在传输给服务器
- 服务器通过私钥A对浏览器加密的数据解密获取到密钥x，这样浏览器和服务器就都获取到了密钥x且其他人不知道，之后就能安全通过密钥x加密进行通信了
非常完美的加密过程，HTTPS也基本使用这个方式来进行加密。但是这样就没有问题了吗？不，还是有漏洞的。常见的中间人攻击就是利用了这个漏洞来进行攻击的。
中间人攻击
- 中间人拥有 公钥A && 私钥A， 服务器拥有 公钥B && 私钥B
- 浏览器对服务器发起请求，服务器将公钥A传输给浏览器，但是在传输过程中中间人将公钥A劫持然后将自己的公钥B传输给浏览器
- 浏览器生成密钥x之后用公钥B加密继续传输
- 中间人使用私钥B对数据进行解密，然后在使用公钥A对包含密钥x的数据进行加密传输给浏览器
这样在通信双方不知情的情况下劫持者就获取到了通信的密钥x，这样劫持者就能通过密钥x就可以为所欲为。造成这个问题的根本原因是因为浏览器不知道自己获取的公钥是不是目标网站的。怎么解决这个问题呢？
数字证书 && 数字签名
如何证明公钥是目标网站的，这个问题就像问我们的毕业证书是不是真是有效的呢？我们是如何证明的，我们只需要去学信网这个国家的可信机构去查询即可。所以说如果有一个地方能查询到浏览器获取的公钥是请求网站的就可以了。有没有一个这样的机构呢？那是当然的，这就是 CA 机构，CA机构颁发的就是
数字证书。所以当我们需要使用 https 时候首先需要在 CA 机构申请数字证书，数字证书中包含了公司信息以及服务器的公钥等信息。那这样就是安全的了吗？当然不是，如果中间人修改了数字证书中的内容那就和上面说的没有数字证书的结果一样了，所以我们需要对数字证书进行一个签名来保证数字证书内容的正确性。
数字签名的制作过程：
- CA机构拥有非对称加密的私钥和公钥
- CA机构对证书明文数据x进行hash
- 拿到证书，得到明文x，签名A
- 用CA机构的公钥对A解密，得到 hashA
- 用证书里指明的hash算法对明文x进行hash得到 hashB
- 之后判断 hashA == hashB，这样就证明了证书是否被修改 以上就是 https 是怎么保证传输数据的安全性，接下来我们在总结下 https 的整个处理过程。
总结
简单的概述下 https 的流程
- 浏览器对服务器发起请求
- 服务器将数字证书，数字签名等信息发送给浏览器
- 浏览器对数字证书进行校验（就是为了校验公钥是否可以信任），如果校验没有问题那么浏览器生成密钥x然后使用公钥对密钥等信息就行加密传输给服务器
- 服务器接收到相关数据使用私钥对其进行解密，这样服务器就接收到密钥x
- 接下来浏览器就可以和服务器通过密钥x进行安全的通信了
- Author:iLikeBug
- URL:http://ilikebug.blog/NetWork/https
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!