HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层.
为什么要引入加密层呢?
HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.
HTTPS就是在HTTP的基础上进行了加密,进一步的保证用户的信息安全。
其中S ====》SSL/TLS协议
HTTPS = HTTP + SSL/TLS
加密就是把 明文 (要传输的信息)进行一系列变换, 生成 密文 .
解密就是把 密文 再进行一系列变换, 还原成 明文 .
在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为 密钥
既然要保证数据安全, 就需要进行 “加密”.
网络传输中不再直接传输明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密
对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文.
一个简单的对称加密, 按位异或
假设 明文 a = 1234, 密钥 key = 8888
则加密 a ^ key 得到的密文 b 为 9834.
然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.
(对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)
当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.
引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了.
服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端,每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系
办法1:能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥。
问题2:
如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了
因此密钥的传输也必须加密传输!
但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 “密钥的密钥”. 这就成了 “先有鸡还是先有蛋” 的问题了. 此时密钥的传输再用对称加密就行不通了.
就需要引入非对称加密.
非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”.
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢,比对称加密要慢很多.
通过公钥对明文加密, 变成密文
通过私钥对密文解密, 变成明文
也可以反着用
通过私钥对明文加密, 变成密文
通过公钥对密文解密, 变成明文
第一次加密是通过非对称加密,来加密对称加密的密钥是什么【使用非对称加密开销成本大】
以后的请求和响应加密就使用第一次协商好的对称加密的密钥来进行加密了
但是仅仅是这样的混合加密还是让黑客存在可乘之机!!!
万一服务器的公钥是被黑客伪造的呢?比如经典的『中间人攻击』问题:
- 客户端发送的请求被中间人(黑客)劫持(如使用 DNS 劫持),所有请求均发送至中间人。
- 中间人假装自己是正规网站(服务器),向客户端返回自己的公钥 2 ,并索要正规网站的公钥 1。
- 客户端使用中间人的公钥 2 加密
会话密钥1
,并发送至中间人。- 中间人使用自己的私钥 2 解密得到
会话密钥1
,同时假装自己是客户端,使用正规网站的公钥 1 加密会话密钥2
(可以与会话密钥 1 相同)并发送至正规网站。- 客户端使用
会话密钥1
对数据进行加密,并发送至中间人。- 中间人使用
会话密钥1
对数据进行解密,得到明文数据!(实现了窃听)- 中间人使用
会话密钥2
对数据(可能是篡改的)进行加密,并发送至正规网站。此时,客户端与服务器的通信再无安全性可言!中间人不仅能够窃听到消息内容,还能够进行篡改!
客户端如何知道自己所拥有的公钥是来自于正规网站而不是中间人呢?这时候就需要数字证书了!
数字证书能解决如下问题:
- 客户端如何获取到公钥?
- 客户端如何确定这个公钥不是黑客伪造的?
数字证书的概念就像是我们的身份证一样,专门用于验证通信实体的身份。咱们的身份证是去派出所申请的,而数字证书则需要向认证中心(Certification Authority,CA)申请,而且是需要收费的!
在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书.
这个证书包含了刚才的公钥, 也包含了网站的身份信息.
当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的),客户端如何进行校验呢?
在客户端的操作系统上,已经提前内置好了相关CA机构的公钥,服务器在申请证书的时候就已经对证书使用CA机构的私钥进行加密,通过操作系统内置好的CA机构的公钥解密证书,如何验证证书的合法性,如果是合法的,就拿到证书里面服务器的公钥,再通过混合加密的方式来进行加密传输。
上面是比较简单的一个过程,下面是比较全面的过程,仅做了解即可:
通过数字证书解决中间人攻击的具体过程为:
私钥
对这个摘要进行加密,生成一串密文,密文也称为数字签名。数字证书即包含此数字签名和 .csr 中明文信息。CA 把这个证书返回给申请人。公钥
去解密签名,得到摘要 1,再利用摘要算法得到明文信息的摘要 2,对比摘要 1 和摘要 2,如果一样,说明证书是合法的,也就是证书里的公钥是正确的,否则说明证书不合法。浏览器如何得到认证中心的公钥呢?万一此公钥是被伪造的呢?为了防止套娃,实际电脑操作系统中会内置这些认证中心的公钥!因而无需担心认证中心公钥被伪造的问题。
Chrome 浏览器一旦发现一个网站数字证书无效,就会生成如下界面进行提示,如果用户强制访问,则存在一定的风险。
总结
HTTPS 工作过程中涉及到的密钥有三组.
**第一组(**非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公
钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的
签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.
第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥
传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解
密获取到对称加密密钥.
第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.
第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
密, 传输给服务器, 服务器通过私钥解
密获取到对称加密密钥.
第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.
第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥