HTTPS 相关原理浅析

移动互联网时代，网民每天都会使用网络浏览大量信息，从而会留下诸多访问痕迹，这样就会导致严重的信息泄露。与此同时，当网民浏览网页时，被“劫持”到其他网页的现象也时有发生，这往往会导致网民浏览直接被打断，而对企业最直接的影响就是体验度差。如何防止移动端网页遭遇劫持和恶俗小广告?这就需要服务提供者主动加强安全防范。

目前，对付移动端网页遭遇劫持最好的方法就是启用安全级别最高的全站HTTPS来连接网页，全站https可以保证在传输数据过程中，数据是加密的。就如同开车被人在车窗塞小广告，现在把窗关紧，他人自然再也无法插足。

什么是HTTPS？

HTTPS安全超文本传输协议 它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版，是使用 TLS/SSL 加密的 HTTP 协议。

HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。

TLS/SSL 全称安全传输层协议， 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

丨HTTP协议面对的安全威胁主要有三类：

·冒充身份：客户端和服务端需要认证对方的身份， 确认自己不是在与冒充者通信。 比较典型的攻击方式有中间人攻击等。

·窃听风险：通信协议需要保证敏感的数据不会被未授权的第三方获取。明文通信的HTTP协议很容易被窃取数据。

·数据篡改：通信双方需要验证来自对方的消息是完整的， 没有丢失片段或被篡改。 攻击者很容易拦截HTTP数据包， 修改数据后代替原包发送到目标地址。 比如非常恼人的HTTP流量劫持。

丨安全通信原理

握手过程

传输层安全协议(Transport Layer Security， TLS)及其前身安全套接字层(Secure Sockets Layer， SSL)都旨在为WEB通信提供安全性和数据完整性保障。

TLS/SSL采用 非对称加密握手-对称加密通信 的方式来减少保密通信的计算量。 下面可以开始介绍TLS/SSL的握手过程了：

1.客户端向服务端发出加密通信请求。 向服务端发送协议版本号， 支持的加密和压缩方法， 以及一个随机数random-client。

2.服务端响应， 确认使用的协议版本号， 加密及压缩算法以及随机数random-server和服务端证书。

3.客户端根据证书的签发者和数字签名确认服务端可信。 确认证书可信之后， 客户端向服务端发送：

·由服务端公钥加密过的随机数pre-master-key， 服务端公钥包含在服务端证书中

·编码变更通知， 表示下一条消息开始客户端将使用对称加密通信。 会话密钥session-key根据随机数random-client， random-server和pre-master-key生成。

4.服务端解密得到随机数pre-master-key生成对话密钥， 向客户端返回编码变更通知。 此后服务端使用同样的会话密钥进行对称加密通信。 至此握手阶段结束， 安全信道建立。

通常情况下只需要客户端验证服务器端身份， 但是网银等应用中服务端需要验证客户端身份。 这种情况下客户端会在步骤3中发送自己的证书， 交由服务端验证。

此前介绍过的SSH协议密钥协商原理与TLS/SSL非常类似。 不过SSH协议需要客户端自行判断是否信任服务端， 这对于WEB应用来说显然是不合适的。

注意到在上述密钥交换方案中random-client和random-server都是明文交换的， 只有pre-master-key是加密传输的。

为了进一步提高安全性， HTTPS协议开始使用更安全的Diffie-Hellman算法把交换pre-master-key改为交换DH算法所需要的参数。

握手阶段结束后， 双方确认对方身份不是冒充者且建立起安全的对称加密信道。

通信过程

加密信道难以窃听或篡改数据(指有目的性的篡改)， 但是删除数据片段就容易得多。 因此， HTTPS在通信过程中需要采取措施验证数据的完整性。

在HTTPS握手过程中除生成sessio-key外， 还会用类似的方法生成hash-key用于鉴证数据完整性。

HTTPS通信中， 双方会用hash-key生成一个MAC(Message Authentication Code)附在HTTP报文后， 然后用session-key加密HTTP报文和MAC码。

接收方在解密后会验证MAC值是否正确， 判断数据是否被篡改。

数字证书及认证原理

现在介绍一下数字证书和认证过程， 数字证书中通常包含几个主要数据：

1.签发者 和 持有人(服务端)的机构， 域名等信息

2.服务端公钥

3.证书到期时间

4.证书使用的加密算法和Hash算法

5.证书的数字签名： 首先由证书正文生成hash值， 然后使用签发者的私钥进行加密得到数字签名

客户端在校验服务端证书时会首先检查是否信任签发者以及证书是否过期等信息。 随后根据证书正文生成hash值， 并用签发者的公钥解密签名。 若解密得到的hash值与生成的hash值相同则说明证书有效。

若攻击者想要冒充服务端进行通信， 必须拥有一个密钥对且公钥包含在可信的证书中。 但是签发者只会签发包含真正服务端公钥的证书， 攻击者无法得到包含自己公钥的证书。

若攻击者试图伪造证书， 攻击者无法得到签发者的私钥也就无法生成合法的数字签名， 无法伪造可信的证书。

也就是说除了服务端私钥和签发者私钥保密外， 签发者必须可靠(不会为攻击者签发证书) 才能保证不会有人冒充服务端。

不可靠的签发者

TLS/SSL协议需要客户端判断是否信任签发者， 用户在判断是否信任签发者时需十分谨慎。 信任了不可靠的签发者， 可能对通信安全造成严重威胁：

1.不可靠签发者C为攻击者A伪造了网站B的证书(证书的信息是网站B的，但却包含攻击者A的公钥)。

2.当用户试图与网站B进行HTTPS通信时， 攻击者A通过DNS劫持等手段使客户端认为A是网站B(此时客户端并不信任与它通信的服务端)。

3.若用户信任了签发者C， 则会信任其为A签发的假证书(C当然能生成合法的数字签名)， 即把攻击者A当做网站B。 此时攻击者A可以获得客户端向网站发送的密码等敏感信息，

4.A也可以冒充用户与网站B通信， 在用户不知情的情况下继续监听加密通信。 这就是所谓的中间人攻击。

——END——