HTTPS原理浅析

HTTPS(Hypertext Transfer Protocol Secure)协议用于提供安全的超文本传输服务. 其本质上是SSL/TLS层上的HTTP协议, 即所谓的"HTTP over SSL/TLS".

越来越多的WEB应用需要在网络上传输交易支付等敏感信息, 使用明文通信HTTP协议显然无法满足对安全性的要求, 因此正逐步被更安全的HTTPS所替代.

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通信, 在用户不知情的情况下继续监听加密通信. 这就是所谓的中间人攻击.