HTTPS
HTTPS 是什么
HTTPS 是一个应用层协议,是在 HTTP 协议的基础上引入了一个加密层.
几个核心概念:
- 明文: 要传输的原始数据.
- 密文: 把明文进行加密之后得到一个让别人不能理解的数据.
- 加密: 明文 -> 密文.
- 解密: 密文 -> 明文.
- 秘钥: 进行加密和解密的重要数据/辅助工具.
两类加密算法:
- 对称加密: 加密和解密都使用同一个秘钥.
- 非对称加密: 是一对秘钥(从数学角度生成的一对数) A 和 B.
使用 A 加密,就使用 B 解密.
使用 B 加密,就使用 A 解密.
HTTPS 基本工作过程
HTTPS 只是在 HTTP 的基础上引入了加密机制.
通过 HTTP 进行传输:
可以看到,如果黑客入侵了路由器,那么黑客就可以对你的数据进行抓包,从而知道你传输了什么数据,甚至进一步的修改这里的数据.
很明显,这样的传输是不安全的.
为了解决上述问题:
-
引入对称加密
引入对称加密之后,即使数据被黑客截获,但是由于黑客不知道秘钥是啥,因此就无法解密,从而保证了数据安全.但实际上,事情没这么简单,我们知道,服务器在同一时刻会给多个客户端提供服务.这么多客户端,每个人用到秘钥必须是不同的(如果是相同的,那么秘钥也能被黑客拿到了~),因此服务器就需要维护每个客户端和每个秘钥之间的关联关系.这是一个麻烦的事情.
-
传输对称秘钥
有一个比较理想的做法,就是在客户端和服务器建立连接的时候,双方协商确定这次的秘钥是啥.
但是如果直接把秘钥明文传输,那么黑客也就知道了,因此秘钥的传输必须加密传输.
-
引入非对称加密
我们可以通过 非对称加密 来对 对称秘钥 进行加密.非对称加密,存在的目的不是取代对称加密,而是起到一个辅助对称加密的作用.
非对称加密只用来加密传输对称密钥.
因为非对称加密的运算开销比较大,很消耗性能~非对称加密,涉及到一对秘钥,公钥和私钥.
公钥随便公开(人人都知道),只要把私钥保护好.
客户端通过公钥加密 对称密钥,因为黑客没有私钥,所以无法解密.这样数据就安全了…吗?
-
中间人攻击
实际上,上述流程存在严重缺陷.黑客只需要让他的设备, 在客户端面前假扮服务器,在服务器面前假扮客户端.这样也能够获取到你的数据!!
-
引入证书
为了避免中间人攻击,于是引入了证书机制~出现中间人攻击问题的关键,在于客户端不知道自己拿到的公钥是不是正确的、合理的,不知道是不是黑客伪造的公钥.
此处,就需要引入第三方公证机构.
如果你想要搭建服务器,使用 HTTPS 就需要在公证机构这里申请证书(电子的,一串数据)
申请的时候,就需要提交一些资料(网站的域名,营业执照,备案号等等)CA认证_百度百科
这个证书包含以下信息:
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
- …
服务器申请到证书之后.后续客户端从服务器拿公钥,就不只是拿公钥,而是拿整个证书.
客户端拿到证书之后,就可以凭借证书中的签名,来对证书的合法性进行验证.客户端验证数字签名:
-
客户端把证书的各个字段,再算一次校验和,得到 checksum1
-
客户端使用公证机构的公钥,对数字签名进行解密,得到 checksum2
-
对比 checksum1 和 checksum2
如果相等,则视为当前证书的各个字段,就是和服务器发出来的证书是一模一样的,此时就可以认为这是合法证书.
如果不相等,意味着证书上的内容被黑客篡改过了,此时浏览器就会弹出警告页面来提示用户.到这里,你可能想问一个问题: 黑客可不可以篡改数据后,同时更新数字签名,让数字签名解密出来的 checksum2, 和篡改过的 checksum1 一致呢??
答: 这在理论上不可行! 黑客篡改了数据之后,要想重新生成数字签名,需要使用公证机构的私钥来加密(这个私钥,不是一般的黑客能拿到的).黑客如果自己生成一个私钥呢?
答: 这个时候客户端拿着公正机构的公钥,解密不了黑客的私钥,此时客户端解密出错,也可以认为是证书有问题,也会弹出大大的窗口~
再来想另一个问题: 客户端如何确定自己手里的公证机构的公钥是正确的,不是黑客伪造的呢?
答: 这个东西不是通过网络获取的,而是操作系统内置的.黑客难以下手.
Fiddle 等抓包工具,为啥能解析 HTTPS 的数据?
要想解析 HTTPS 的数据,你得拿到对称秘钥,才能够对数据解密.
你使用 Fiddle 的时候,Fiddle 就在对你进行中间人攻击(在开启 HTTPS 选项的时候,弹出来一个框,是否要信任 Fiddle 提供的证书,点击 Yes,表示你允许fiddle对你进行攻击了~).
更具体点:
最后来一道经典面试题:
你在浏览器输入 url 之后,到最终展示出页面为止,这个过程计算机都做了哪些事情?
