HTTPS详解

这两天面试被问HTTPS细节问骂了，记录一下。

HTTP和HTTPS概述

网络请求方式通常分为两种，分别是HTTP请求和HTTPS请求，其中HTTP的传输属于明文传输，在传输的过程中容易被人截取并且偷窥其中的内容，而HTTPS是一种在HTTP的基础上加了SSL/TLS层（安全套接层）的安全的超文本传输协议，其传输的内容是通过加密得到的，所以说是一种安全的传输。

HTTP协议：超文本传输协议，明文传输，客户端与Web服务器间的应用层通信协议。

HTTPS协议：HTTP+SSL/TLS，即HTTP下加入SSL层，使用SSL加密，用于安全的HTTP传输，https默认使用端口443。

SSL：安全套接字层，位于可靠的面向连接的网络层协议。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。具有数据加密和身份验证的功能。

TLS：安全传输层协议、对SSL扩展和优化，提供数据安全的同时，确保数据的完整性。

加密方式

一、对称加密

私钥加密，信息的发送方和接收方使用同一个密钥加密和解密数据。

二、对称加密

生成两把密钥公钥和私钥。私钥自己保存，公钥用于公开。可以用公钥和私钥中任何一个进行加密，另一个解密。

具体有两种情形：

（1）对方用你的公钥加密信息，你收到后用私钥解开。

只有你有私钥，所以只有你能解开，换句话说，有私钥才能看到信息，很安全。

（2）你拿私钥加密信息，对方收到后用你的公钥解开。

公钥是公开的，所以其他人也可以看到你的信息，不保密。

私钥加密，只有对应公钥能解开。既然用你的公钥能解开，说明加密一定是你的私钥。私钥只有你有，所以一定是你发送的，你不可抵赖。

但是这样存在一个身份伪造问题，即窃听者也可以冒充Bob给Alice送信，因为Alice的公钥是公开的，这样就无法分辨哪个是真Bob的送信。因此需要一种签名认证方式来确认身份。

三、数字签名

为了表明信息没有收到伪造，确实是信息拥有者发出。可以使用数字签名。

Bob用自己的私钥对消息加密作为签名，再与消息一起发送，接收者用Bob的公钥验签。

窃听者窃取冒充Bob的签名篡改内容也没用，因为内容发生改变时，对应的签名也要重新计算，签名的生成必须使用私钥，只要私钥不泄露，签名就不会被冒充。

但是数字签名只是能验证发送方身份，未对报文进行加密。窃听者截取到密文并指定发送者的身份时，可通过查阅手册即可获得发送者的公钥PKA，就可以窃听报文的内容。

四、数字证书（公钥的数字签名）

发送方可以去证书中心CA为公钥做认证，证书中心用自己的私钥，对需要加密的公钥和一些相关信息一起加密，生成"数字证书"。这样接收方就可以防止收到假的公钥，接收方收到带有数字证书的消息后，用CA的公钥先解开数字证书，就可以拿到发送方真实的公钥了。

五、非对称数字签名

发送者使用私钥对消息加密作为签名，再使用接收方的公钥对消息进行加密，接收方使用自己的私钥进行解密后，再对签名进行验签。保证了消息不会被窃听和发送方不会被第三方伪装。

六、hash算法的数字签名（摘要+数字签名）

一般而言，不会直接对数据本身计算数字签名，因为数字签名属于非对称加密，非对称加密依赖于复杂的数学运算，耗时久。所以使用摘要，并且摘要最好是不可逆转的，一般使用开头MD5作为Hash函数，MD5输出的结果固定位128位。

但是若是窃听者将自己的公钥换走了发送方的公钥，再冒充发送方给B发送消息，用自己的私钥做成假的签名，此时接收方无法判断哪个是真正的消息。

HTTPS流程

HTTPS的流程即客户端请求服务端公钥，检验是否合法，再用服务端公钥加密客户端公钥发送给服务端的过程。

1. 客户端发送HTTPS请求。 服务器收到请求后，返回数字证书（数字签名+公钥）。
2. 客户端验证证书是否合法（用服务端的公钥验签），不合法则提示警告。
3. 验证合法后，本地生成密钥（对称加密密钥）并用服务端的提供的公钥加密后发送给服务端。
4. 服务端用自己的私钥对数据解密，得到客户端密钥（对称加密密钥），再用客户端密钥对要发送的数据进行加密后发给客户端。

问题总结

为什么数据传输是用对称加密?

答：HTTP的应用场景中通常端与端之间存在大量的交互，非对称加密的加解密效率非常低。
另外，在 HTTPS的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密

为什么需要证书?
答：防止“中间人”攻击，同时可以为网站提供身份证明。

使用 HTTPS 会被抓包吗?
答：会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。