百度图片识别在线识图_网页设计素材分析_seo推广教程_2345浏览器

https概念

一、什么是https

https也是一个应用层协议，在 HTTP 协议的基础上引入了一个加密层

二、为什么要有https

因为http是明文传输的，这会导致在传输的过程中被别人篡改数据，有安全风险。所以有https对数据进行加密，降低安全风险。

加密：明文经过一系列变换，变成密文
解密：密文经过一系列变换，变成明文

在加密和解密的过程中，需要一个或者多个中间数据辅助这个过程，这个数据叫密钥。

我们的请求的数据是如何被篡改的？
客户在浏览器要下载一个音乐播放器，点击下载，服务端会发送音乐播放器的下载链接给客户，但是在发送的过程中，可能会被中间人劫持，然后中间人将音乐播放器的下载链接换成其他软件的下载链接，最后到达客户那的链接，就成了其他软件的下载链接。

三、常见的加密方式

1️⃣对称加密
用同一个密钥完成加密和解密
常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2 等
特点：算法公开、计算量⼩、加密速度快、加密效率⾼

对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文

栗子：

2️⃣非对称加密
需要两个密钥来进行加密和解密，一个叫公钥，另一个叫私钥
常见非对称加密算法(了解)：RSA，DSA，ECDSA
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快
公钥和私钥是配对的，缺点是运算速度非常慢

配对：

• 通过公钥对明文加密, 变成密文
• 通过私钥对密文解密, 变成明文

反着用：

• 通过私钥对明文加密, 变成密文
• 通过公钥对密文解密, 变成明文

总结：
对称加密：同一个密钥进行加密和解密，特点：快
非对称加密：用两个密钥(公钥和私钥)分别进行加密和解密，特点：慢

四、数据摘要

数据摘要（也可以叫数据指纹）的原理是利用单向散列函数(Hash 函数)对信息进行运算，生成一串固定长度的数字摘要。数字摘要并不是一种加密机制，但可以用来判断数据有没有被篡改。

用于进行数据对比：

https实现过程

一、只使用对称加密

只使用对称加密，加密和解密用的是同一个密钥。客户端要发送一个数据给服务端，如果只是明文传输，那么数据就会被中间人窃取，所以用密钥R加密。但是又有一个问题，加密后变成密文传过去，服务端要对密文解密，是不是要有密钥R；既然如此，那把密钥R也传过去。问题来了，密钥R直接传，相当于是明文传输，这样不就会被别人窃取了吗，然后再把密文窃取，用窃取的密钥R解密窃取的密文，跟前面一样是不行的。那好，把密钥加密下，也就是密钥的密钥，可是，密钥的密钥，是不是也要密钥的密钥来解密，那还要传密钥的密钥，传密钥的密钥，不就又被窃取了吗。跟前面的思路是一样的，因为密钥的密钥也是明文传输，以此类推，密钥的密钥的密钥。。。也是一样的。这就变成了先有鸡还是先有蛋的问题了，所以该方案不合理。

二、只使用非对称加密

非对称加密的特点是用两个密钥配对使用，进行加密和解密。服务端有公钥S和私钥S’ ，客户端发起请求，服务端响应并发送给客户端公钥S，客户端用公钥S对明文进行加密处理，然后发送给服务端，服务端用私钥S’ 进行解密，拿到明文数据。注意，这段过程看似是安全的，其实并非一定安全，后面再分析。服务端也想给客户端发送消息，用私钥S’ 对明文进行加密处理，然后发送给客户端，客户端再用公钥S解密获取明文数据。这段过程很明显是不安全的，因为公钥S在前面是明文传输的，容易被窃取，再窃取这个密文，信息不就泄漏了吗。

所以该方案从客户端->服务端是貌似安全的，从服务端->客户端是不安全的；非对称加密效率较低。

三、双方都使用非对称加密

客户端有公钥C和私钥C’，服务端也有公钥S和私钥S’；客户端发起请求，并且给服务端公钥C，服务端响应并给客户端公钥S；客户端发送一个消息，将明文数据用公钥S加密后变成密文发送给服务端，服务端用私钥S’ 解密获取明文数据；同理，服务端给客户端发送消息，将明文数据用公钥C加密后变成密文发送给客户端，客户端用私钥C’ 解密获取明文数据。

从上面两端过程来看，似乎是安全的；但是，效率太低了。

四、非对称加密+对称加密

服务端有公钥S和私钥S’，客户端发起请求，服务端响应并发送给客户端公钥S，然后客户端本地生成对称密钥R，用公钥S对密钥R进行加密生成密文数据，客户端将这个密文数据发送给服务端，然后服务端用私钥S’ 对密文数据进行解密，获取密钥R。后面就都可以使用对称密钥进行加密发消息了，然后通过密钥R解密获取数据。密钥R不会被窃取，因为前面只有通过服务端的私钥S’ 才能解密获取，这样客户端和服务端两边都有密钥R，就可以用对称加密的方式进行消息传递，而且对称加密效率高。

效率方面，因为只在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密，所以效率快很多。

但是，仍然有安全问题，而且与方案二、方案三的问题一样。假如在最开始，中间人就已经开始攻击了呢。

五、中间人攻击

服务端有公钥S和私钥S’，中间人有公钥M和私钥M’，客户端发起请求，服务端响应并发送给客户端公钥S，中间人劫持了公钥S，然后将公钥S换成自己的公钥M，发送给客户端。客户端不知道是谁的公钥。然后客户端本地生成密钥R，用获取的公钥(M)对密钥进行加密，生成密文数据，然后发送给服务端。中间人劫持这个密文数据，因为它是用公钥M加密的，所以可以用私钥M’ 进行解密，中间人就这样获取了密钥R。为了不被发现，中间人再用前面劫持的公钥S对密钥R进行解密，生成密文数据发送给服务端，服务端用私钥S’ 进行解密，获取密钥R。

此时，除了客户端和服务端有私钥R，中间人也有私钥R，那么后续不管是谁给谁发送数据，中间人劫持了这个数据，都可以用私钥R进行解密，这个数据也就能被中间人随意获取，然后中间人想干啥就干啥了。

根本问题出在：最开始，客户端无法确定收到的公钥的数据报文（公钥、私钥其实是数据）是目标服务器发来的。

六、数据签名和证书

签名：
数据通过散列函数形成散列值，用签名者的私钥对散列值进行加密，变成签名；签名附加到数据上，就是数字签名的证书。

验证：
数字签名的证书分为数据和签名，数据通过散列函数，形成一串散列值；签名则是用签名者的公钥解密，获取散列值。如果两个散列值不相同，就说明数据有被篡改过，这份证书就不是有效的。

签名者有非对称加密的公钥和私钥，注意，这两个公钥和私钥与前面的服务端的公钥和私钥不是同一个东西。中间人篡改数据，散列值对比不相同，证书无效；中间人把签名一起改了呢，也就是说，中间人也有自己的公钥和私钥，然后用自己的私钥伪造一份。这是不行的，验证时，不认这份签名。因为进行验证时都必须内置式的使用签名者的公钥，才能接下来进行认证。而配对签名者的公钥只有签名者的私钥，所以只有签名者的私钥才有对数据签名的能力，即没有该签名者的私钥，伪造的签名也没用。再进一步说，谁持有大家都认的公钥对应的私钥，谁就可以进行签名。

这里的签名者一般是CA机构，所以只有CA机构有签发证书的能力。

客户端发起第一次请求，实际上，得到的是一份证书，从证书里获取服务端的公钥。证书=明文数据+签名。

CA认证：
服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了。

申请信息（域名、申请者、服务端的公钥）就是数据，用散列函数形成散列值，然后用CA机构的私钥对散列值进行签名，数据+签名=证书。服务端成功申请到证书，把它发送给客户端，客户端要进行验证。用内置的CA机构的公钥进行解密，看证书是否合法。

客户端获取的公钥是否合法，只要看证书是否合法就行。而证书只有CA机构的私钥才能进行加密签名。

七、非对称加密+对称加密+证书认证

整体过程：

服务端先申请证书，客户端发起请求后，服务端把证书给客户端，服务端的公钥就在证书里。客户端只需要验证证书是否合法就行，合法，获取公钥，接下来就是正常发送数据；不合法，终止向服务端发送数据。

关于安全性问题：
证书是明文传输的，所以中间人是可以劫持到证书，但是，篡改不了数据。

• 修改数据：客户端验证后，发现散列值对比是不同的，所以不行
• 修改签名：无法修改，因为没有CA机构的私钥
• 替换证书：中间人在申请证书时，同样也要提交自己的信息，包括域名，把替换后的证书给客户端，客户端发现这个证书的域名怎么跟我请求的目标服务器不一样啊，所以就能发现这个证书不是合法的。

总结：

HTTPS 工作过程中涉及到的密钥有三组

第一组(非对称加密)：用于校验证书是否被篡改。服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得)，客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥)。服务器在客户端请求时，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。

第二组(非对称加密)： 用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。

第三组(对称加密)：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。