【Bugly干货分享】“HTTPS”安全在哪里？

背景

最近基于兴趣学学习了下 HTTPS 相干的知识，在此记录下学习心得。

在上网获得信息的进程中，我们接触最多的信息加密传输方式也莫过于 HTTPS 了。每当访问1个站点，阅读器的地址栏中出现绿色图标时，意味着该站点支持 HTTPS 信息传输方式。我们知道 HTTPS 是我们常见的 HTTP 协议与某个加密协议的混合体，也就是 HTTP+S。这个 S 可以是 TLS（安全传输层协议）、也能够是 SSL（安全套接层），不过我更认可另外一个抽象概括的说法，HTTP+Security。不过要谈论 HTTPS 为什么安全，还得从 HTTP 为什么不安全说起。

假定你现在正坐在教室里上课，现在你非常想和走道旁的迷人的 TA 说1些话，1般这个时候你会用“传纸条”的方式来交换。而这个方式和 TCP/IP 协议基本的工作模式10分相像：

1. 通太小动作引发对方注意；
2. 对方以多种可能的方式（注视、肢体语言等）回应于你；
3. 你确认对方感知到你后，将纸条传给对方；
4. 对方浏览纸条；
5. 对方给予你浏览后的反应；

怎样样，这个流程是否是很熟习？

如果你要传递纸条的 TA 距离你很远怎样办？HTTP 协议就是指你在纸条上写明你要传给的 TA 是谁，或 TA 的坐位在哪，接着只需要途径的同学拿到纸条后根据纸条上的唆使顺次将纸条传过去就 OK 了。

这个时候问题来了：途径的同学完全可以观看并知道你在纸条上写了甚么。

这就是 HTTP 传输所面临的问题之1：中间人攻击，指消息传递的进程中，处在传递路径上的攻击者可以嗅探或窃听传输数据的内容。

加密

HTTPS 针对这个问题，采取了“加密”的方式来解决。最著名原始的加密方法就是对称加密算法了，就是双方约定1个暗号，用甚么字母替换甚么字母之类的。现在1般采取1种叫 AES（高级加密算法）的对称算法。

对称加密算法既指加密和解密需要使用的密钥 key 是1样的。

AES 在数学上保证了，只要你使用的 key 足够长，破解几近是不可能的（除非光子计算机造出来了）

我们先假定在没有密钥 key 的情况下，密文是没法被破解的，然后再回到这个教室。你将用 AES 加密后的内容噌噌噌地写在了纸条上，正要传出去的时候你突然想到，TA 没有 key 怎样解密内容呀，或说，应当怎样把 key 给TA？

如果把 key 也写在纸条上，那末中间人照样可以破解窃听纸条内容。或许在现实环境中你有其他办法可以把 key 通过某种安全的渠道送到 TA 的手里，但是互联网上的实现难度就比较大了，毕竟不管怎样，数据都要经过那些路由。

因而聪明的人类发明了另外一种加密算法——非对称加密算法。这类加密算法会生成两个密钥（key1 和 key2）。凡是 key1 加密的数据，key1 本身不能解密，需要 key2 才能解密；凡事 key2 加密的数据，key2 本身不能解密，只有 key1 才能解密。

目前这类算法有很多中，最经常使用的是 RSA。其基于的数学原理是：

两个大素数的乘积很容易算，但是用这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因确切比较困难，特别是当这个大数足够大的时候（通常使用2的10次方个2进制位那末大），就算是超级计算机，解密也需要非常长的时间。

现在就把这类非对称加密的方法利用在我们教室传纸条的场景里。

• 你在写纸条内容之前先用 RSA 技术生成了1对密钥 k1 和 k2。
• 你把 k1 用明文传了出去，路经或许有人会截取，但是没有用，k1 加密的数据需要 k2 才可以破解，而 k2 在你自己手中。
• k1 传到了目的人，目的人会去准备1个接下来准备用于对称加密（AES）的传输密钥 key，然后用收到的 k1 把 key 加密，传给你。
• 你用手上的 k2 解出 key 后，全教室只有你和你的目的人具有这个对称加密的 key，你们俩就能够纵情聊天不怕窃听啦~

这里或许你会有问题，为何不直接用非对称加密来加密信息，而是加密 AES 的 key 呢？
由于非对称加密和解密的平均消耗时间比较长，为了节省时间提高效力，我们通常只是用它来交换密钥，而非直接传输数据。

但是使用非对称加密真的可以防范中间人攻击吗？
虽然看上去很安全，但是实际上却挡不住可恶的中间人攻击。

假定你是 A，你的目的地是 B，现在要途径1个歹意同学M。

中间人的歹意的地方在于它会假装成你的目标。

• 当你要和 B 完成第1次密钥交换的时候，M 把纸条扣了下来，伪装自己是B并捏造了1个 key，然后用你发来的 k1 加密了 key 发回给你。
• 你以为你和 B 完成了密钥交换，实际上你是和 M 完成了密钥交换。
• 同事 M 和 B 完成1次密钥交换，让 B 以为和 A 你完成了密钥交换。
• 现在整体的加密流程变成了A（加密链接1）->M(明文)->B(加密链接2)的情况了，这时候候 M 仍然可以知道A和B传输的全部消息。

这个时候就是体现 HTTPS 和传纸条的区分了。在教室里，你是和1位与你身份几近对等的的对象来通讯；而在访问网站时，对方常常是1个比较大（或知名）的服务者，他们有充分的资源，也许他们可以向你证明他们的合法性。

此时我们需要引入1个非常权威的第3方，1个专门用来认证网站合法性的组织，可以叫做 CA（Certificate Authority）。各个网站服务商可以向 CA 申请证书，使得他们在建立安全连接时可以带上 CA 的签名。而 CA 得安全性是由操作系统或阅读器来认证的。

你的 Windows、Mac、Linux、Chrome、Safari 等会在安装的时候带上1个他们认为安全的 CA 证书列表，只有和你建立安全连接的网站带有这些CA的签名，操作系统和阅读器才会认为这个链接是安全的，否则就有可能遭到中间人攻击。

1旦某个 CA 颁发的证书被用于的非法途径，那末这个 CA 之前颁发过的所有证书都将被视为不安全的，这让所有 CA 在颁发证书时都10分谨慎，所以 CA 证书在通常情况下是值得信任的。

总结

使 HTTP 后面增加1个S（Security）的技术，正是 对称加密 + 非对称加密 + CA 认证 这3种技术的混合体。固然这个主要是 HTTPS 的基本原理，真正实际中的 HTTPS 的协议是比以上的描写更加复杂1些的，并且其中任何1步稍有闪失，全部流程都将不再安全。

这也是为何 HTTPS 协议从 SSL 1.0升级到 SSL 3.0，再被 TLS 1.0 现在被 TLS 1.3取代，其背后都是1个个细节上的优化，以防有任何闪失。

TLS 协议相比 SSL 协议增加了传输层的安全保证。

更多精彩内容欢迎关注Bugly的微信公众账号：

腾讯 Bugly是1款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上利用崩溃的情况和解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，逐日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解利用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！