HTTPS是怎么保证安全传输的？

安全传输要解决什么问题？

1.窃听问题

A与B传输明文过程中，能被中间人获取到传输的内容

2.篡改风险

A与B传输明文过程中，中间人修改了内容再传输给B

3.冒充风险

A与B传输明文过程中，中间人拦截内容，修改后传给B，B传输给A内容时，修改后再传给A，此时，中间人已经冒充为B，A以为在与B通信，其实是在与中间人通信

如何解决上述问题？

要解决明文传输的问题，要先了解两种加密方式
1.对称加密
双方商量好一个密钥，传输的之前对内容进行加密，收到内容后先解密后再使用
2.非对称加密
非对称加密即加解密双方使用不同的密钥，一把作为公钥，可以公开的，一把作为私钥，不能公开，公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。

注：私钥加密其实这个说法其实并不严谨，准确的说私钥加密应该叫私钥签名，因为私密加密的信息公钥是可以解密的，而公钥是公开的，任何人都可以拿到，用公钥解密叫做验签

1.对传输的内容进行加密

对传输的内容加密是很容易的，直接采用对称加密，这样就能保证双方的内容不会被窃听、修改、冒充，但这个时候又存在一个问题，对称加密密钥怎么传输，如果采用明文传输那么密钥被获取到，中间人获取到了密钥，那这样跟没有密钥一样，这个时候就可以理解为，解决了对称加密密钥的传输问题就解决了上述三个问题，没解决之前跟裸奔一样。

2.对对称密钥进行加密

对对称密钥怎么安全传输？首先会想到对密钥再加密，那密钥的密钥怎么传输？显然这样是不行的。那么我们想起非对称加密的方式，首先B把自己的公钥发给A，A使用公钥加密自己的密钥传输给B，B解密后双方就有了相同的对称密钥，双方拿着对称密钥进行对传输，传输的的内容保证不会被窃听、修改，但这样有被冒充的风险。假设B把自己的公钥发给A时被篡改，那么中间人可以保存B的公钥，并生成自己的公钥私钥，把自己的公钥传给A，现在中间人有自己的私钥和B的公钥，那么就可以冒充B与A通信。那现在的问题就变为怎么保证公钥来自B？保证了这一点，明文传输的三个问题就可以解决了。

3.对公钥进行验证

A去请求B的公钥，B在返回公钥的过程中可能被拦截，这个时候A拿到的公钥就有可能是中间人的公钥。怎么保证公钥来自B？显然现在无法保证。拿到现实生活我们怎么办？显然需要有一个权威机构背书，B拿着自己的身份证和自己的密钥来有关机构开个证明，内容包括姓名：B，公钥：XXX，然后盖章（盖得章上会包含一个验证码），那么只要我们能确认章不是假的，那么就能确认这个就是A的公钥，因为有关部门已经通过身份证确认过B的身份。问题就变为了怎么确认证明上的章是真的，有关部门会给你一个验证的方式，就假设为f（f是不可逆的，采用非对称加密就可以实现），只需要f(B+公钥)=盖章上的验证码，就能证明这就是A的公钥。
https是怎么解决的开证明的问题？
1.把上述的有关部门换成CA机构
2.把盖章的方式改为非对称加密
3.把验证的方式改为非对称解密
这样是不是就安全了，其实这里还有一个风险点，有关部门会给你一个验证的方式（也就是非对称解密方式）怎么传输给你，如果通过网络传输还是可以被冒充，一旦被冒充，就可以伪造一个CA机构，显然我们不能让CA证书的非对称解密方式从网络获取（这里不是风险不在公钥被泄漏，在于被替换调），所以在你安装系统的时候，各ca机构的非对称解密方式已存在于你的电脑中了。