JavaEE--网络编程 https 加密

HTTPS是什么

HTTPS也是⼀个应用层协议.是在HTTP协议的基础上引入了⼀个加密层.

HTTP协议内容都是按照文本的⽅式明文传输的.这就导致在传输过程中出现⼀些被篡改的情况. 臭名昭著的"运营商劫持" 下载⼀个天天动听 未被劫持的效果,点击下载按钮,就会弹出天天动听的下载链接。

已被劫持的效果,点击下载按钮,就会弹出QQ浏览器的下载链接

由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器,交换机等),那么运营商的⽹ 络设备就可以解析出你传输的数据内容,并进⾏篡改.

点击"下载按钮",其实就是在给服务器发送了⼀个HTTP请求,获取到的HTTP响应其实就包含了该 APP的下载链接.运营商劫持之后,就发现这个请求是要下载天天动听,那么就⾃动的把交给⽤⼾的响应 给篡改成"QQ浏览器"的下载地址了

在互联网上,明文传输是比较危险的事情!!!

HTTPS就是在HTTP的基础上进行了加密,进⼀步的来保证用户的信息安全~

"加密"是什么

加密就是把明文(要传输的信息)进⾏⼀系列变换,⽣成密⽂. 解密就是把密⽂再进行⼀系列变换,还原成明文

在这个加密和解密的过程中,往往需要⼀个或者多个中间的数据,辅助进行这个过程,这样的数据称为密 钥(正确发音yue四声,不过大家平时都读作yao四声).

HTTPS的工作过程

既然要保证数据安全,就需要进行"加密". 网络传输中不再直接传输明⽂了,而是加密之后的"密文". 加密的方式有很多,但是整体可以分成两大类:对称加密和非对称加密

引入对称加密

对称加密其实就是通过同⼀个"密钥",把明⽂加密成密文，并且也能把密文解密成明文

⼀个简单的对称加密,按位异或 假设明⽂a=1234,密钥key=8888 则加密a^key得到的密⽂b为9834. 然后针对密⽂9834再次进⾏运算b^key,得到的就是原来的明⽂1234. (对于字符串的对称加密也是同理,每⼀个字符都可以表⽰成⼀个数字) 当然,按位异或只是最简单的对称加密.HTTPS中并不是使⽤按位异或

引⼊对称加密之后,即使数据被截获,由于⿊客不知道密钥是啥,因此就无法进行解密,也就不知道请求 的真实内容是啥了.

但事情没这么简单.服务器同⼀时刻其实是给很多客户端提供服务的.这么多客户端,每个⼈⽤的秘钥都 必须是不同的(如果是相同那密钥就太容易扩散了,黑客就也能拿到了).因此服务器就需要维护每个客户 端和每个密钥之间的关联关系,这也是个很⿇烦的事情~

⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~

但是如果直接把密钥明文传输,那么黑客也就能获得密钥了~~此时后续的加密操作就形同虚设了. 因此密钥的传输也必须加密传输!

但是要想对密钥进行对称加密,就仍然需要先协商确定⼀个"密钥的密钥".这就成了"先有鸡还是先有 蛋"的问题了.此时密钥的传输再用对称加密就行不通了.

就需要引⼊非对称加密.

引入非对称加密

非对称加密要用到两个密钥,⼀个叫做"公钥",⼀个叫做"私钥". 公钥和私钥是配对的.最大的缺点就是运算速度⾮常慢，比对称加密要慢很多.

• 通过公钥对明⽂加密,变成密文
• 通过私钥对密⽂解密,变成明文 也可以反着用
• 通过私钥对明文加密,变成密文
• 通过公钥对密文解密,变成明文

• 客户端在本地⽣成对称密钥,通过公钥加密,发送给服务器.
• 由于中间的网络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密 钥
• 服务器通过私钥解密,还原出客⼾端发送的对称密钥.并且使⽤这个对称密钥加密给客⼾端返回的响 应数据.
• 后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其 他主机/设备不知道密钥即使截获数据也没有意义

中间人攻击

⿊客可以hi有中间人攻击,获取到对称密钥

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进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚 ⾄修改，都是可以的

引入证书

服务端在使用HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信 息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端 公钥的权威性

基本说明：CA认证_百度百科

这个证书可以理解成是⼀个结构化的字符串,⾥⾯包含了以下信息:

• 证书发布机构

• 证书有效期

• 公钥

• 证书所有者

• 签名

• .....

需要注意的是：申请证书的时候，需要在特定平台生成查，会同时生成⼀对儿密钥对儿，即公钥和私 钥。这对密钥对儿就是⽤来在网络通信中进行明文加密以及数字签名的。

理解数据签名

签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞 混了

当服务端申请CA证书的时候，CA机构会对该服务端进⾏审核，并专⻔为该⽹站形成数字签名，过程如 下：

1. CA机构拥有⾮对称加密的私钥A和公钥A'

2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要

3. 然后对数据摘要⽤CA私钥A'加密，得到数字签名S 服务端申请的证书明⽂和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了

通过证书解决中间人攻击

在客户端和服务器刚⼀建⽴连接的时候,服务器给客⼾端返回⼀个证书. 这个证书包含了刚才的公钥,也包含了⽹站的⾝份信息

当客⼾端获取到这个证书之后,会对证书进⾏校验(防⽌证书是伪造的)

• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到⼀个hash值(称为数 据摘要),设为hash1.然后计算整个证书的 hash 值,设为 hash2 .对⽐ hash 1 和 hash2 是否相等.如 果相等,则说明证书是没有被篡改过的.

查看浏览器的受信任证书发布机构

Chrome浏览器,点击右上角的

选择"设置",搜索"证书管理",即可看到以下界⾯：

中间⼈有没有可能篡改该证书？

• 中间⼈篡改了证书的明⽂
• 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后 的证书形成匹配的签名
• 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改， 证书不可信，从而终止向服务器传输信息，防⽌信息泄露给中间人

中间⼈整个掉包证书？

• 因为中间人没有CA私钥，所以⽆法制作假的证书(为什么？)
• 所以中间⼈只能向CA申请真证书，然后用自己申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整 体掉包，客户端依旧能够识别出来。
• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的

完整流程

左侧都是客户端做的事情,右侧都是服务器做的事情.