(｡･∀･)ﾉﾞ嗨！你好这里是ky233的主页：这里是ky233的主页，欢迎光临~https://blog.csdn.net/ky233?type=blog
点个关注不迷路⌯'▾'⌯
http是明文的可以通过一些的工具获取到正文层，从而导致账号密码泄露，所以就有了https
一、安全的定义
世界上没有真正的安全，所谓安全就是你破解的所花费的成本，要远大于你的收益这就叫做安全
二、https的概况
1.概况
首先我们的应用层是http，socket是传输层OS给我们提供的接口，这样我们才能简单的写一个http，其中应用层中还有一个小的模块叫做TLS/SSL,这个模块主要负责加密和解密用的，如果我们的http直接通过这个模块进入传输层，这就叫做https
在接收方也是先通过TLS/SSL然后还原成http的，所以在网络中就是经过加密的https，不法分子也无法来获取到你的信息。
2.加密和解密
加密就是将明文转化成密文，解密则相反
三、https的工作过程探究
既然要保证数据安全,就需要进行"加密网络传输中不再直接传输明文了,而是加密之后的“密文"加密的方式有很多但是整体可以分成两大类:对称加密和非对称加密
方案一：只使用对称加密
引入对称加密之后,即使数据被截获,由于黑客不知道密钥是啥,因此就无法进行解密,也就不知道请求的真实内容是啥了
但事情没这么简单.服务器同一时刻其实是给很多客户端提供服务的.这么多客户端,每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,黑客就也能拿到了).因此服务器就需要维护每个客户端和每个密钥之间的关联关系,这也是个很麻烦的事情~
因此密钥的传输也必须加密传输!
但是要想对密钥进行对称加密就仍然需要先协商确定一个“密钥的密钥"这就成了"先有鸡还是先有蛋”的问题了.此时密钥的传输再用对称加密就行不通了
方法二：非对称加密
看似没问题，可是服务器给客户端发消息，这个过程就有可能被黑客拿走，就会被人看到！所以方案二也不行
方案三：双方非对称加密
1.服务端拥有公钥S与对应的私钥S，客户端拥有公C与对应的私钥C
2.客户和服务端交换公钥，客户端给服务端发信息:先用S对数据加密，再发送，只能由服务器解密，因为只有服务器有私销
3.服务端给客户端发信息:先用C对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥
这样貌似也行啊，但是
1.效率太低
2.依旧有安全问题
方案四：非对称加密+对称加密
服务端具有非对称公钥S和私钥S。
客户端发起https请求，获取服务端公钥S
客户端在本地生成对称密钥C,通过公钥S加密,发送给服务器.
由于中间的网络设备没有私钥,即使截获了数据,也无法还原出内部的原文,也就无法获取到对称密钥(真的吗?)
服务器通过私钥S'解密,还原出客户端发送的对称密钥C.并且使用这个对称密钥加密给客户端返回的响应数据.
后续客户端和服务器的通信都只用对称加密即可.由于该密钥只有客户端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义
由于对称加密的效率比非对称加密高很多,因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密.
虽然上面已经比较接近答案了，但是依旧有安全问题方案2，方案3，方案4都存在一个问题，如果最开始，中间人就已经开始攻击了呢?
四、中间人攻击-针对上面的场景
1..服务器具有非对称加密算法的公钥S，私钥S
2.中间人具有非对称加密算法的公钥M，私钥M'
3.客户端向服务器发起请求，服务器明文传送公钥S给客户端
4.中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M,并将伪造报文发给客户端
5.客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了)，自己形成对称秘钥X，用公钥M加密X，形成报文发送给服务器
6.中间人劫持后，直接用自己的私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
7.服务器拿到报文，用自己的私钥S解密，得到通信秘钥X
8.双方开始采用X进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的
但是只要已经交换密钥了，中间人就没有办法了，它只能在最开始的时候进行篡改
这个中间人攻击能够成功的本质是什么呢？本质是中间人能够对数据做篡改并且客户端无法验证收到的公钥是否是服务端发过来的
五、CA认证
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性
2.数据签名
签名是基于非对称加密算法的
当服务端申请CA证书的时候，CA机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如下
1.CA机构拥有非对称加密的私钥A和公钥A'2.CA机构对服务端申请的证书明文数据进行hash，形成数据摘要
3.然后对数据摘要用CA私钥A'加密，得至数字签名S
服务端申请的证书明文和数字签名S共同成了数字证书，这样一份数字证书就可以颁发给服务端了
如果这个时候，中间人再次替换我们的密钥，我们的客户端就可以拿着我们的CA机构的公钥对我们的明文数据进行hash，得出数据摘要，在取出数据签名对公钥对签名进行解密，如果相等则没被替换
中间人有没有可能篡改该证书?
中间人篡改了证书的明文
由于他没有CA机构的私钥，所以无法hash之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人
中间人整个掉包证书?
所以中间人只能向CA申请真证书，然后用自己申请的证书进行掉包
这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
永远记住:中间人没有CA私钥，所以对任何证书都无法进行合法修改，包括自己的