javaee-HTTPS

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

加密：就是把明文通过一系列变化变成密文

解密：就是把密文通过一系列变化变成明文

加密和解密过程中，往往需要一个或者多个中间的数据，辅助这个过程进行，这样的数据称为密钥

HTTPS的工作过程

①对称密钥：只有一个密钥，加密解密使用同一个密钥

明文+key（密钥）=> 密文

密文+key（密钥）=> 明文

通过对称密钥对传输的内容进行加密和解密

存在的问题：

当客户端通过网络向服务器发送密钥时，会有中间攻击人会截取到这个密钥，此时客户端和服务器在对接下来的传输内容进行加密和解密也不安全，因为中间攻击人也拿到了密钥，也可以对数据进行解密，即能够看到发送的内容，此时是不安全的。所以引入了非对称加密

②非对称加密：用到两个密钥，一个公钥（pub），一个私钥（pri）

明文+pub=>密文；密文+pri=>明文

明文+pri=>密文；密文+pub=>明文

服务器有一对非对称密钥：pub公钥，pri私钥，此时客户端可以生成一个对称密钥key。

1.客户端通过网络询问服务器公钥，此时服务器通过网络将公钥发送给客户端。

2.客户端收到公钥，则通过公钥对自己的对称密钥进行加密并传输给服务器

3.服务器通过自己保留的密钥对该密文进行解密得到了对称密钥key

4.此时服务器和客户端要传输的内容，可以通过key进行加密和解密

存在的问题：

当服务器把公钥（pub1）通过网络传输时，中间攻击人也可以获取到公钥（pub1），记住了这个公钥是什么，并可以自己生成一对非对称密钥（pub2，pri2），将当前服务器发送的公钥（pub1）纂改成自己生成的公钥（pub2）发送给客户端。当客户端收到当前公钥（pub2）时，通过这个公钥（pub2）对自己的对称密钥（key）进行加密，发送给服务器，此时中间攻击人通过自己的密钥（pri2）对该密文解密得到了客服端的对称密钥（key），并且将该密钥再次通过当时保留的服务器的公钥（pub1）进行加密发送回去给服务器，服务器可以通过自己保留的密钥（pri1）将该密文解密获取到客户端的对称密钥（key），此时中间攻击人获取到了客户端的对称密钥，当客户端和服务器再使用这个密钥key加密传输的数据内容时，中间攻击人也能对加密的内容进行解密，也是不安全的。所以引入了证书

③证书：

1.服务器需要向权威机构申请证书

证书里面包含的内容有：①证书颁布的机构；②证书有效期；③证书所有者；④公钥（服务器的公钥）；⑤签名（被权威机构的pri1加密的签名，即校验和）等

证书的签名：

权威机构通过算法计算证书的各种属性得到的签名，使用自己的私钥对他进行加密

2.服务器把证书发送给客户端，每个系统内都有自带公钥（pub1）可以对证书中的签名进行解密，客户端可以解密，中间攻击人也可以

3.客户端按照同样的算法对证书的各种属性进行计算也得到一个签名，比较两个签名是否相同，若相同则说明当前数据没有被纂改，若不相同，则当前数据被纂改了

4.当计算的两个签名相同时，则客户端使用该证书中的公钥对自己的对称密钥进行加密，发送给服务器，服务器通过自己保留的私钥将其解密得到对称密钥

问题：中间攻击人也可以拿到证书，可以通过自己操作系统内自带的公钥pub1对证书的签名进行解密，通过纂改其中的属性，也可以通过计算得到一个签名，为什么说客户端拿到的公钥就是服务器的公钥。

因为当中间攻击人对证书进行解密并且对其属性进行纂改时，需要对其进行加密发送给服务器，但是服务器是通过权威机构的公钥pub1也就是客户端操作系统内自带的公钥pub1对进行解密的，而公钥pub1只能解被私钥pri1加密的。此时私钥pri1是权威机构保留的，而中间攻击人并没有获取得到。所以当中间攻击人进行解密想要再加密时并没有权威机构的私钥pri1，所以此时中间攻击人纂改内容也无济于事。