https传输过程

HTTPS传输过程主要涉及到对称加密和非对称加密两种方式，对称加密用来加密数据内容，非对称加密用来加密对称加密的秘钥。

前置知识

对称加密

加密和解密使用相同的密钥

• 优点：简单、快速
• 缺点：在密钥发送的时候容易被截取

非对称加密

使用公钥进行加密，私钥进行解密；私钥加密的话就使用公钥解密

A向B发送消息 使用B的公钥进行加密 B收到密文后使用自己的私钥进行解密 反之亦然

• 优点：安全
• 缺点：慢

对称加密+非对称加密

https协议采用的就是这种加密方式

为了解决在对称加密/非对称加密中公钥被窃取的情况。

A先生成一个对话密钥，然后把对话密钥发送给B。但是这个对话密钥要经过B的公钥进行加密，B收到后用自己的私钥进行解密。这样就解决了对称加密时公钥容易被截取的缺陷。

实际上就是对称加密的密钥进行非对称加密

• 优点：安全、快

• 缺点：中间人攻击

中间人攻击

在非对称加密和对称机密+非对称机密的这两种方式的时候都需要使用B的公钥对传输的内容进行加密，那么B的密钥是哪里来的呢？

B的公钥是在最开始连接建立的时候发送给A的。假如这个时候有一个中间人截取了B的公钥，然后将自己的公钥发送给A。A在给B发送消息时，想用B的公钥进行加密。但实际上用的是中间人的公钥。中间人截取了A给B发送的消息，然后用自己的私钥解密。就可以随意读取消息的内容。
此外，中间人也可以使用B的公钥来加密一些消息传输给B，让B以为中间人就是A

数字证书

用于防止中间人攻击

数字证书是由专业的机构颁发的CA（Certificate Authority）机构

CA机构通过服务端提供的相关信息生成证书，证书的主要内容有：公钥（Public Key）、ISSUER（证书的发布机构）、Subject（证书持有者）、证书有效期、签名算法、指纹及指纹算法。

数字证书是如何保证公钥来自请求的服务器呢？数字证书上由持有人的相关信息，通过这点可以确定其不是一个中间人；但是证书也是可以伪造的，如何保证证书为真呢？

数字证书包括 公钥和数字签名 证书在发布之前，CA机构对证书的内容用指纹算法（一般是sha1或sha256）计算得到一个hash值，这个hash值就是指纹。为什么用hash值作为证书的身份代表呢？首先，hash值具有不可逆性，也就是说无法通过hash值得出原来的信息内容；其次，hash值具有唯一性，即hash计算可以保证不同的内容一定得到不同的hash值。数字证书在发布的时候，CA机构将证书的指纹和指纹算法通过自己的私钥加密得到的就是证书的签名了

检验时 首先通过机构的根公钥去解密证书的签名，解密成功的话会得到证书的指纹和指纹算法，指纹是一个hash值，它代表着证书的原始内容，此时再通过指纹算法计算证书内容得到另外一个hash值，如果这两个hash值相同，则代表证书没有被篡改过，否则就是被篡改了

浏览器接收到证书以后，就要开始进行验证工作了。首先从证书中得知证书的颁发机构，然后从浏览器系统中去寻找此颁发机构的根证书。上面我们也看到，世界上权威CA机构的根证书都是预先嵌入到浏览器中的，如果在浏览器系中没有找到对应的根证书，就代表此机构不是受信任的，那么就会警告无法确认证书的真假，比如以前打开12360网站就会提示，现在不会了

如果我们找到了证书颁发机构的根证书，那么就从根证书中取得那个根公钥，用根公钥去解密此证书的数字签名，成功解密的话就得到证书的指纹和指纹算法，指纹是证书内容通过指纹算法计算得到的一个hash值，这里我们称之为h1，h1代表证书的原始内容；然后用指纹算法对当前接收到的证书内容再进行一次hash计算得到另一个值h2，h2则代表当前证书的内容，如果此时h1和h2是相等的，就代表证书没有被修改过。如果证书被篡改过，h2和h1是不可能相同的，因为hash值具有唯一性，不同内容通过hash计算得到的值是不可能相同的

有人说假如证书上的指纹是不法分子伪造的，伪造是没有用的，因为你伪造的指纹不可能用CA机构的根私钥去加密（根私钥是CA机构绝对保密的），伪造者只能拿自己的秘钥去加密这个伪造的指纹，但当我们拿机构的根公钥去解密伪造指纹的时候是不可能成功的（加密内容只能由一对公钥私钥解密）

在证书没有被修改过的基础上，再检查证书上的使用者的URL（比如csdn.net）和我们请求的URL是否相等，如果相等，那么就可以证明当前浏览器链接的网址也是正确的，而不是一些钓鱼网之类的

但如果浏览器的连接被某个中间人截取了，中间人也可以发一个由权威的CA机构颁发的证书给浏览器，然后也可以通过证书没有被篡改的验证，但是在证书没有被篡改的前提下，通过对比证书上的URL和我们请求的URL是否相同，我们还是可以判断当前证书是不是服务器发的证书。可以这么理解，因为URL具有唯一性，所以中间人的证书的上的URL和我们的证书的URL是不可能相同的，如果中间人修改了自己证书上的URL，那么就通过不了证书没有被篡改的验证，所以中间人的证书也是欺骗不了我们的

到这里我们认证了三点信息：

1. 证书是否为受信任的权威机构颁发的

2. 证书是否被篡改

3. 证书是否为服务器发过来的，而不是第三方发的

HTTP协议存在的问题

• 信息明文传递，容易被窃取和篡改
• 无法验证对方身份

什么是HTTPS？

https就是在http和tcp之间加入了一层SSL层。https的安全基础就是ssl。

https协议就是由http+ssl组成的可以进行加密传输和身份认证的网络协议。https的作用：

• 对传递的数据进行加密
• 验证网站的真实性

http和https的区别

• http是超文本传输协议，信息是明文传递的。https是具有安全性的ssl加密传输协议

• https需要申请证书，一般免费的证书比较少，需要一定的费用。

• http的链接很简单是无状态的。而https则是http+ssl构建的可以进行数据加密和身份认证的网路协议，比http更安全

• http和https采用完全不同的链接，所以端口号不同，http是80，https是443

https的缺点

• https建立链接需要多次握手，导致页面的加载时间延长
• https证书需要一定的费用，功能越强大的证书费用越高
• https的缓存不如http高效（注意：这里依旧是可以缓存的，只要我们设置了正确的缓存头，https请求也是可以被缓存的）
• SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大

http传输过程（SSL握手）

• 客户端发送一个https的请求到服务器。包括支持的SSL/TSL协议的版本，客户端支持的加密方法和客户端生成的一个随机数
• 服务端确认支持的协议版本和加密方法，向客户端发送一个服务器生成的随机数以及网站的证书（证书中包含公钥）返回给客户端（证书可以自己制作也可以向专业机构申请，区别就是自己制作的证书需要客户端验证通过才可以使用）
• 客户端验证证书的有效性。（通过证书的公钥对签名进行解密得到指纹和指纹算法，通过指纹算法对证书的信息加密得到的结果与指纹进行对比是否一致）有效的话生成一个随机数并且用证书中的公钥对这个随机数进行加密，发送给服务器
• 服务器收到之后，用自己的私钥进行解密。获取发送过来的随机数。
• 客户端和服务器根据约定好的加密方法，使用前面生成的三个随机数，生成对话密钥，用来加密接下来的整个对话过程

所以在证书验证阶段使用的是非对称加密（即生成会话密钥的阶段），在内容传输的时候还是对称加密

私钥的作用

握手阶段我们需要注意三点：

• 生成会话密钥需要三个随机数
• 握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
• 服务器的公钥存放在服务器的数字证书中

从上面可以得知，整个会话过程中（包括握手以及之后的数据传输）服务器的公钥和私钥只用到了一次