文章目录
概述
传输层安全性协议(Transport Layer Security,缩写:TLS)及其前身安全套接层(Secure Sockets Layer,缩写:SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。TLS协议采用主从式架构模型,用于在两个应用程序间透过网络创建起安全的连线,防止在交换数据时受到窃听及篡改。
TLS协议的优势是与高层的应用层协议(如HTTP、FTP、Telnet等)无耦合。应用层协议能透明地运行在TLS协议之上,由TLS协议进行创建加密信道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密,从而保证通信的私密性。
基本工作方式
TLS的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的密钥,然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信,不同的节点之间采用的对称密钥不同,从而可以保证信息只能通信双方获取。
握手过程
基于RSA握手和密钥交换的例子详解TLS/SSL握手过程:
1. client_hello
客户端发起请求,以明文传输请求信息,包含版本信息、加密套件候选列表、压缩算法候选列表、随机数、扩展字段等信息,相关信息如下:
- 支持的最高TSL协议版本;
- 客户端支持的加密套件cipher suites列表, 每个加密套件是四个功能的组合:认证算法Au(身份验证)、密钥交换算法KeyExchange(密钥协商)、对称加密算法Enc(信息加密)和信息摘要Mac(完整性校验);
- 支持的压缩算法compression methods列表,用于后续的信息压缩传输;
- 随机数random_C,用于后续的密钥的生成;
- 扩展字段extensions,支持协议与算法的相关参数以及其它辅助信息等,常见的SNI就属于扩展字段。
2. server_hello + server_certificate + sever_hello_done
server_hello,服务端返回协商的信息结果,包括选择使用的协议版本version、选择的加密套件cipher suite、选择的压缩算法compression method、随机数random_S等,其中随机数用于后续的密钥协商;
server_certificates,服务器端配置对应的证书链,用于身份验证与密钥交换;
server_hello_done,通知客户端server_hello信息发送结束。
3. 证书校验
客户端验证证书的合法性,验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下:
- 证书链的可信性trusted certificate path;
- 证书是否吊销revocation,有两类方式——离线CRL与在线OCSP,不同的客户端行为会不同;
- 有效期expiry date,证书是否在有效时间范围;
- 域名 domain,核查证书域名是否与当前的访问域名匹配。
4. client_key_exchange + change_cipher_spec + encrypted_handshake_message
client_key_exchange,合法性验证通过之后,客户端计算产生随机数字Pre-master,并用证书公钥加密,发送给服务器;
此时客户端已经获取全部的计算协商密钥所需要的信息(两个明文随机数random_C和random_S与自己计算产生的Pre-master),计算得到协商密钥;
change_cipher_spec,客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
encrypted_handshake_message,结合之前所有通信参数的hash值与其它相关信息生成一段数据,采用协商密钥session secret与算法进行加密,然后发送给服务器用于数据与握手验证。
5. change_cipher_spec + encrypted_handshake_message
服务器用私钥解密加密的Pre-master数据,基于之前交换的两个明文随机数random_C和random_S,计算得到协商密钥;
计算之前所有接收信息的hash值,然后解密客户端发送的encrypted_handshake_message,验证数据和密钥正确性;
change_cipher_spec,验证通过之后,服务器同样发送change_cipher_spec以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
encrypted_handshake_message,服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥session secret与算法加密并发送到客户端。
6. 握手结束
客户端计算所有接收信息的hash值,并采用协商密钥解密 encrypted_handshake_message,验证服务器发送的数据和密钥,验证通过则握手完成;
7. 加密通信
开始使用协商密钥与算法进行加密通信。
注意:
- 根据使用的密钥交换算法的不同,如ECC等,协商细节略有不同,总体相似;
- 服务器也可以要求验证客户端,即双向认证。可以在过程2中发送 client_certificate_request信息,客户端在过程4中先发送client_certificate与certificate_verify_message信息,证书的验证方式基本相同,certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据,服务器可以采用对应的公钥解密并验证;
- sever key exchange的作用是server certificate没有携带足够的信息发送给客户端以计算pre-master时(如基于 DH 的证书,公钥不被证书中包含),需要单独发送;
- change cipher spec实际可用于通知对端改版当前使用的加密通信方式;
- alter message用于指明在握手或通信过程中的状态改变或错误信息,一般告警信息触发条件是连接关闭、收到不合法的信息、信息解密失败、用户取消操作等,收到告警信息之后,通信会被断开或者由接收方决定是否断开连接。
算法
TLS 1.0–1.2 cipher suites:
Key exchange/agreement | Authentication | Block/stream ciphers | Message authentication |
---|---|---|---|
RSA | RSA | RC4 | Hash-based MD5 |
Diffie–Hellman | DSA | Triple DES | SHA hash function |
ECDH | ECDSA | AES | |
SRP | IDEA | ||
PSK | DES | ||
Camellia |
密钥交换和密钥协商(Key exchange or key agreement)
在客户端和服务器开始交换TLS所保护的加密信息之前,他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括:使用RSA算法生成公钥和私钥(TLS_RSA)、Diffie-Hellman(TLS_DH)、ephemeral Diffie–Hellman(TLS_DHE)、elliptic-curve Diffie–Hellman(TLS_ECDH)、ephemeral elliptic-curve Diffie–Hellman(TLS_ECDHE)、anonymous Diffie–Hellman(TLS_DH_anon)、pre-shared key(TLS_PSK)和Secure Remote Password(TLS_SRP)。
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户,因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
Cipher
参考
HTTPS加密协议详解(四):TLS/SSL握手过程
Wikipedia: Transport Layer Security