为什么Https是安全的（简单介绍）
0X00 没有什么用的开头
众所周知https是安全加密的协议，那么https究竟是如何保证数据传输的安全性的呢？这里来简单介绍一下https的安全机制。
0X01 简介
HTTPS全称是 Hypertext Transfer Protocol Secure 也就是传统的HTTP加上了S Secure，也可以叫 HTTP over TLS，总之就是加了密的HTTP嘛。
最常见的加密就是通信双方共有一个密钥，使用这个密钥对原文进行加密和解密，简单粗暴。但是万一密钥泄露了，那么任何人都可以用这个密钥解密你们通信的所有内容，甚至通信双方都是无感知的。（想象一下你和小姐姐的聊天记录被一个扣脚大汉一行行的看完还嘿嘿傻笑是不是贼恐怖）
这种加密方式有一个严肃的问题就在于通信双方得有一个约定密钥的机会，还要保证传输密钥的信道是绝对安全的。（想象一下你想跟小姐姐聊天的话需要先私下悄悄碰面，然后再一个没有人的地方悄咪咪的交换密钥，然后再用这个密钥进行加密通信）这还不是重点，重点就是你俩明明已经有了一个可以保证绝对安全的通信方法（在没有人的地方悄咪咪地通信）了，那为啥还非要交换密码然后加密通信呢，是不是觉得贼蠢。
HTTPS就能解决这种问题，下面我们来开始吧。我们假设一个场景就是客户端（你）和一台web服务器（小姐姐）通信的场景，在这个场景下描述HTTPS。
0X02 HTTPS的前提条件
HTTPS通信有两个重要前提条件，没有这些条件的话HTTPS是没有实际作用的
- 使用非对称加密算法对内容进行加密，目前我们使用的RSA算法就是非对称加密算法
- 存在一个绝对安全的第三方机构，我们称之为CA（Certificate Authority），我们认为它不会被攻击，他发布的信息都是可靠的
非对称加密：与对称加密的一个密钥用来加密解密不同，非对称加密有一对密钥，分为“公钥”和“私钥”。使用密钥对中的公钥对原文进行加密之后再次使用公钥解密是行不通的，必须使用对应的私钥才能对密文进行解密；
CA：CA是一个被认为绝对安全且诚实的第三方机构，服务器将自己密钥对中的公钥交由CA管理。客户端访问服务器时候可以从CA处取得服务器的公钥；
0X03 开始吧
无论客户端还是服务器，所有人的公钥都是可以对外公开的，私钥都是绝对绝对不能公开的，要保证私钥绝对安全，一旦私钥泄露即可造成HTTPS加密失效
首先你打算以安全的方式联系小姐姐，从你这里开始整个流程。
- 首先你知道小姐姐的住址，然后通过小姐姐的住处前往CA去取得小姐姐的公钥；
- 你把想给小姐姐说的话用小姐姐的密钥加密好，连同自己的公钥一起发送给小姐姐；
- 小姐姐收到了你的密文，使用自己的私钥解密得到了你发送的原文；
- 小姐姐写好了给你的回复，使用你提供的公钥对原文加密，并传输给了你；
- 你收到小姐姐的密文后使用私钥将内容解密，得知了小姐姐的心意；
- 重复上面的操作。
0X04 如果被截取
我们假设在上面任意地方数据被黑客截取了，那他能获取你和小姐姐的消息内容吗？
截取了你和CA的通信
黑客截取了你和CA的通信，那么他能得到的信息就是：“你要和哪个小姐姐通信，小姐姐的公钥是什么”。虽然你也泄露了一点点信息（你要和谁通信），但是这些并非敏感数据，黑客并不能对这个做什么。小姐姐的公钥就更不重要了，任何人都能获得；
截取了你第一次发给小姐姐的内容
如果黑客截取了你发送给小姐姐的内容，那内容中只有：“你发给小姐姐的密文，你自己的公钥”。密文由于他没有小姐姐的私钥，所以无法解密；你自己的公钥也是所有人都可以获取的，也没有用；
截取了小姐姐回复给你的内容
假设黑客截取了小姐姐回复给你的内容，那内容中只有：“小姐姐给你的密文”。由于黑客并没有你的私钥，所以他并不能知道小姐姐给你发送了什么内容。
0X05 总结
总结下来，黑客即使截取了所有的数据，那也只有下面这些：
- 客户端访问的服务器地址
- 客户端request携带的加密数据
- 服务端response携带的加密数据
- 客户端服务端双方的公钥
其中加密数据由于没有对应的私钥所以无法解密，而双方的公钥本来就是公开的所以并没有什么用。