朋友面试阿里，关于HTTPS被问了三道题，看看你能回答上几道题。
第一，为什么使用HTTPS之后，通信就安全了？
第二，HTTPS实现通信安全的原理是什么？
第三，使用了HTTPS就绝对安全了吗？
本篇文章就带大家一起聊聊HTTPS，顺便解答上面三个问题。
关于HTTPS
前面学习过HTTP协议的报文格式及交互模式，我们知道HTTP传输的内容本质上就是文本，HTTP/2采用了二进制字节的形式传输，但依旧可以进行反编译。也就是说，在通信的过程中只要拦截对应的请求，就可以获得通信的报文信息。从这个层面来讲，我们说HTTP协议是不安全的。
而HTTPS是身披SSL外壳的HTTP，利用SSL/TLS建立全信道，加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
在HTTPS通信过程中，会涉及到非对称加密和对称加密两种算法，从而满足了性能和安全的双重需要。
HTTPS的特点
HTTPS传输的是加密之后的数据，即使被拦截也很难获得明文。HTTPS有以下特点：
- 内容加密：采用混合加密技术（结合对称加密和非对称加密技术），中间者无法直接查看明文内容；
- 验证身份：通过证书认证客户端访问的是自己的服务器；
- 保护数据完整性：防止传输的内容被中间人冒充或者篡改；
关于这些特点，我们可以在原理层面进行逐步分析。
HTTPS协议实现原理
采用HTTPS通信的过程涉及到两部分：证书验证和数据传输。
第一阶段，证书获取及验证过程：
- 浏览器发起一个HTTPS的请求；
- 服务器接收到请求，返回一个HTTPS证书，该证书内包含服务器私钥对应的公钥信息；
- 浏览器验证证书是否合法，如果不合法（未经过CA认证或未添加信任）则进行提示。通常位于浏览器中URL地址左侧有的小锁图标处；
第二阶段，加密秘钥传输及加密报文传输，可以统称数据传输：
- 证书验证合法或可信任，则在浏览器端生成一个随机数，该随机数用于通信报文的对称加密；
- 通过公钥将随机数加密，传输给服务器；
- 服务器获得加密的随机数，使用私钥进行解密，并存储随机数。此时，双方都有了对称加密的秘钥（随机数）；
- 服务器使用随机数对要传输的数据进行对称加密，并将加密信息返回给客户端；
- 客户端获得加密数据，使用随机数作为秘钥，基于对称加密算法对报文进行解密，渲染呈现给用户；
关于HTTPS的实现原理总结一下就三步：
- 客户端向服务器端索要并验证公钥；
- 双方协商生成"对话密钥"；
- 双方采用"对话密钥"进行加密通信；
其中前两步又称作"握手阶段"（handshake）。
上述流程看似简单，但会延伸出来几个问题，我们来逐个看看。
如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。这也是为什么服务器返回的是证书，而不是单纯的公钥。
如何减少公钥加密耗时问题？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
这也是为什么在HTTPS通信过程中会生成一个随机数的原因，它就是“对话密钥”，用来数据通信的对称加密，提升算法性能。
另外，一对公私钥只能实现单向的加解密，所以HTTPS中内容传输加密采取的是对称加密，而不是非对称加密。
分析完整个HTTPS交互的流程，看似已经完美的方案中其实还有一个漏洞：数据在网络传输中如果被“中间人”掉包了怎么办？
“中间人”攻击
我们先来看一下，在基于HTTPS交互的过程中，在通信的过程中公钥被掉包了会发生什么情况。
在这里插入图片描述
在上图中，基本原理就是中间人通过网络劫持等，将通信过程中的公钥替换成自己的，然后假装自己是服务器与客户端进行通信。从而对信息进行窃取或篡改。
我们知道，公私钥及证书都是可以自己进行生成的，虽然发起了HTTPS的请求，但如果证书和公私钥无法保证是否被替换，传输的安全性就无法保证。此时，就需要拿出终极武器：SSL证书申购。也称作CA证书申购。
CA证书
CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure，PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。有这样一个权威机构来签发证书，就确保了证书的可信性（合法性）。
浏览器会对服务器返回SSL证书进行验证：
- 验证域名、有效期等信息是否正确；
- 判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
- 判断证书是否被篡改：需要与CA服务器进行校验；
- 判断证书是否已吊销，可用于第3步中，以减少与CA服务器的交互，提高验证效率。
上述条件完全满足时，才说明该证书合法。
此时，再回到“中间人”攻击的问题，会发现，当浏览器获取到假公钥时，通过比对验证就会发现不合法，进而在浏览器层面对用户进行风险提示。但浏览器只会进行风险提示，用户仍然可以授权信任证书继续操作。
使用了HTTPS就绝对安全了吗？
通过上面的学习我们已经知道HTTPS通信是加密的，常规抓包手段是无法获取报文内容的。但像上面所说的“中间人”攻击的情况，不顾浏览器的安全提醒，继续进行后续网页的访问，则会出现安全问题。
在客户端授权的情况下，可以组建中间人网络，而抓包工具便是作为中间人的代理。通常，HTTPS抓包工具会生成一个证书（类比的假证书），用户安装在客户端或添加信任。此时，客户端先与抓包工具通信，抓包工具再将请求转发到服务器，服务器返回的信息，抓包工具可进行处理或输出，然后再返回给客户端。
因此，HTTPS的安全性更多的体现在用户不知情的情况下进行的访问，如果用户已知情或主动授信，表明用户已经明确了风险，此时如果出现中间人攻击的问题，HTTPS还是不安全的。
本地随机数的安全
最后，还有一方面的安全需要我们留意，那就是本地随机数的安全。在HTTPS内容传输时采用的是对称加密，因此秘钥在客户端和服务器端均存储的有。针对本地存储是随机数，HTTPS并不能保证它的安全，HTTPS重点关注的是传输过程中的安全。
也就是说，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。
小结
最后，再来看看那三个问题：
第一，为什么使用HTTPS之后，通信就安全了？
HTTPS利用SSL/TLS建立全信道，加密数据包，保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。
第二，HTTPS实现通信安全的原理是什么？
HTTPS实现安全通信主要通过多种加密方式和身份验证实现，主要分三步：（1）客户端向服务器端索要证书并验证公钥；（2）双方协商生成"对话密钥"；（3）双方采用"对话密钥"进行加密通信；
其中，证书保证了公钥的可信与安全，公钥保证了“对话秘钥”传输的安全，“对话秘钥”保证了通信报文的安全。
第三，使用了HTTPS就绝对安全了吗？
HTTPS重点关注传输过程中的安全，在用户不知情的情况下进行网站访问，浏览器会给出安全提示。但如果用户继续访问或设置授信，则会发生“中间人”攻击的可能性。在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。中间人攻击常发生在公共WIF或路由上。
在本地随机数（秘钥）安全方面，HTTPS也无能为力，只能借助杀毒软件、漏洞升级等来防护。同时，在黑客攻击、拒绝服务攻击、服务器劫持等方面，HTTPS几乎起不到作用。
