共计 2258 个字符，预计需要花费 6 分钟才能阅读完成。
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 的握手过程了:
客户端向服务端发出加密通信请求. 向服务端发送协议版本号, 支持的加密和压缩方法, 以及一个随机数
random-client.服务端响应, 确认使用的协议版本号, 加密及压缩算法以及随机数
random-server和服务端证书.- 客户端根据证书的签发者和数字签名确认服务端可信. 确认证书可信之后, 客户端向服务端发送:
- 由服务端公钥加密过的随机数
pre-master-key, 服务端公钥包含在服务端证书中 - 编码变更通知, 表示下一条消息开始客户端将使用对称加密通信. 会话密钥
session-key根据随机数random-client,random-server和pre-master-key生成.
- 服务端解密得到随机数
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 值是否正确, 判断数据是否被篡改.
数字证书
认证原理
现在介绍一下数字证书和认证过程, 数字证书中通常包含几个主要数据:
签发者 和 持有人 (服务端) 的机构, 域名等信息
服务端公钥
证书到期时间
证书使用的加密算法和 Hash 算法
证书的数字签名: 首先由证书正文生成 hash 值, 然后使用签发者的私钥进行加密得到数字签名
客户端在校验服务端证书时会首先检查是否信任签发者以及证书是否过期等信息. 随后根据证书正文生成 hash 值, 并用签发者的公钥解密签名. 若解密得到的 hash 值与生成的 hash 值相同则说明证书有效.
若攻击者想要冒充服务端进行通信, 必须拥有一个密钥对且公钥包含在可信的证书中. 但是签发者只会签发包含真正服务端公钥的证书, 攻击者无法得到包含自己公钥的证书.
若攻击者试图伪造证书, 攻击者无法得到签发者的私钥也就无法生成合法的数字签名, 无法伪造可信的证书.
也就是说除了服务端私钥和签发者私钥保密外, 签发者必须可靠(不会为攻击者签发证书) 才能保证不会有人冒充服务端.
不可靠的签发者
TLS/SSL 协议需要客户端判断是否信任签发者, 用户在判断是否信任签发者时需十分谨慎. 信任了不可靠的签发者, 可能对通信安全造成严重威胁:
不可靠签发者 C 为攻击者 A 伪造了网站 B 的证书(证书的信息是网站 B 的, 但却包含攻击者 A 的公钥).
当用户试图与网站 B 进行 HTTPS 通信时, 攻击者 A 通过 DNS 劫持等手段使客户端认为 A 是网站 B(此时客户端并不信任与它通信的服务端).
若用户信任了签发者 C, 则会信任其为 A 签发的假证书(C 当然能生成合法的数字签名), 即把攻击者 A 当做网站 B. 此时攻击者 A 可以获得客户端向网站发送的密码等敏感信息,
A 也可以冒充用户与网站 B 通信, 在用户不知情的情况下继续监听加密通信. 这就是所谓的中间人攻击.
本文永久更新链接地址：http://www.linuxidc.com/Linux/2018-01/150355.htm
