SSL和TLS-TLS 1.2

2008年,TLS 1.2(版本号是3.3)发布(RFC 5246)。
TLS 1.2最大的改变是它的扩展机制,允许不改变底层协议的情况下,增加附加功能。

TLS Extensions

客户端和服务器的hello消息里,可以增加一些扩展。这些扩展是向后兼容的。客户端可以调用一个TLS扩展,来扩展它的ClientHello消息,一个扩展了的ClientHello消息就是一个带附加的数据块(扩展列表)的普通的ClientHello消息。记住,这些附加的信息只能扩展ClientHello消息。这样的一个扩展了的ClientHello消息符合规范,不会破坏一个存在的TLS服务器。TLS服务器能接受这样的消息,即使它不理解这些扩展。如果服务器理解这些扩展,它就返回一个扩展了的ServerHello消息。
扩展了的ServerHello消息只能用来响应扩展了的ClientHello消息。
扩展列表的长度没有上限。
每个扩展的结构都相同,有两个属性,两个字节的type和变长的data(可以为空)。比如,一个客户端想初始化安全重新协商扩展,就在ClientHello消息后面附加五个字节(0xFF, 0x01, 0x00, 0x01和0x00)。前两个字节0xFF和0x01,是扩展的类型,接下来的两个字节0x00和0x01是扩展的长度,最后一个字节是扩展数据的内容0x00。
IANA维护TLS参数的注册。其中包括有效的TLS扩展类型。

TLS 1.2 Extension Types and Values

Extension Type Value Description
server_name 0 服务器名称
max_fragment_length 1 最大fragment长度协商
client_certificate_url 2 客户端证书URL
trusted_ca_keys 3 Trusted CA keys
truncated_hmac 4 截断的HMAC
status_request 5 证书状态请求
user_mapping 6 User mapping
client_authz 7 客户端认证
server_authz 8 服务器认证
cert_type 9 证书类型
elliptic_curves 10 椭圆曲线密码学
ec_point_formats 11
srp 12 SRP协议
supported_signature_algorithms 13 签名算法
use_srtp 14 SRTP的key建立
heartbeat 15 Heartbeat
application_layer-protocol_negotiation 16 协商应用层协议
status_request_v2 17 证书状态请求,版本2
signed_certificate_timestamp 18
client_certificate_type 19 原始公钥
server_certificate_type 20 原始公钥
encrypt_then_mac 22 使用EtA代替AtE
extended_master_secret 23 安全重新协商(revisited)
session_ticket 35 Session tickets
renegotiation_info 65281 安全重新协商

New TLS Alert Messages

Alert Code Description
unsupported_extension 110 发送者(总是客户端)通知接收方,ServerHello消息里有不支持的扩展。永远是fatal
certificate_unobtainable 111 发送者(总是服务器)通知接收方,不能读取CertificateURL里的证书(链)。可以是fatal
unrecognized_name 112 发送者(总是服务器)通知接收方,不认识ServerName扩展里的名称。可以是fatal
bad_certificate_status_response 113 发送者(总是客户端)通知接收方,收到了无效的证书状态响应。永远是fatal
bad_certificate_hash_value 114 发送者(总是服务器)通知接收方,证书hash与客户端提供的不匹配。永远是fatal

Server Name Indication

Virtual hosting技术是指同一台机器上部署多个服务,可能使用一个IP地址。假如一个用户在浏览器输入 www.esecurity.ch,一个DNS找到IP地址是88.198.39.16的机器。浏览器建立到该机器的80端口的TCP连接,然后客户端和服务器使用HTTP交流。因为浏览器想访问 www.esecurity.ch,客户端就发送带host头的HTTP请求消息(Host: www.esecurity.ch),服务器的机器就把这个HTTP请求传给目标web服务器。这样,HTTP运行得很好。
考虑一下调用SSL/TLS,使用HTTPS代替了HTTP会发生什么。在HTTP呢个被调用之前,必须建立SSL/TLS连接。它可能不清楚怎么在一台机器上区分不同的web服务。有很长时间,没有类似的HTTP Host头,于是,每个支持SSL/TLS的web服务只能使用唯一的IP地址。所以,要定义TLS服务器名称扩展,叫做server name indication (SNI),作用类似于HTTP Host header。使用SNI,客户端一个客户端可以发送一个带server_name扩展的ClientHello消息,告诉服务器,它想要连接的web服务的DNS主机名。这样就不需要唯一的IP地址了。因为SNI是后来才加到TLS的,所以,还有很多产品不支持它。

Maximum Fragment Length Negotiation

一个SSL记录的最大fragment长度是214。TLS也还是这样。有时候,因为带宽限制,需要较小长度的fragment。
max_fragment_length扩展(type等于1)可以由客户端告诉服务器,需要协商一个比较小的最大fragment长度。
实际的最大长度,由data属性确定。值分别是1(代表29)、2(代表210)、3(代表211)和、4(代表212)。
该长度在一个TLS session期间有效,包括恢复的session,不能动态修改。

Client Certificate URL

代替了客户端发送的Certificate消息。如果客户端想使用这个机制,就在ClientHello消息里带client_certificate_url扩展。
如果服务器想支持这个机制,就在ServerHello消息里返回相同的扩展。客户端和服务器然后知道,在随后的握手中,他们都可以使用客户端证书URL机制。
使用这个机制的时候,客户端可以发送Certificate(类型是11)消息,或者发送CertificateURL(类型是21)消息。从安全的观点看,客户端证书URL机制有一个问题,可能被引导到恶意网站。强烈建议,该机制在服务器侧生效之前,有一些保护机制,比如做一下数据内容检查。不应该默认生效。

Trusted CA Keys

SSL/TLS握手的时候,服务器发送Certificate消息时,不能预先知道客户端可以接受的根CA。如果客户端不接受服务器提供的证书,就得重新握手。如果客户端的ClientHello消息包含了trusted_ca_keys,服务器就能知道客户端可以接受的根CA。服务器返回的ServerHello消息里可以带上空的trusted_ca_keys,告诉客户端,它支持该扩展。客户端支持的实际的证书,还是放在Certificate消息里。

Truncated HMAC

HMAC构造器的输出,与使用的hash函数输出一样长(MD5是128位,SHA-1是160位,SHA-256是256位)。如果在一个受限制的环境里使用HMAC构造器,HMAC的输出会被截断,比如是80位。此时要用truncated_hmac扩展。如果客户端和服务器都支持该机制,就可以使用截断的HMAC代替完整的值。
注意,只影响认证使用的HMAC计算,不影响TLS PRF里的HMAC构造器(用于master secret和key计算)。
不推荐使用truncated_hmac。

Certificate Status Request

SSL/TLS握手的时候,收到证书的一方,会验证证书的有效性。可以在证书撤销清单(CRL)里检索,如果没找到,就是有效的。或者使用在线证书状态协议(OCSP)做验证。
如果证书的接收方是一个受限的客户端,CRL检查和OCSP查询太昂贵了。这种时候,服务器可以替代客户端做验证。客户端向服务器发status_request信号,说明它希望得到一些证书的状态信息,比如一个OCSP响应(这些附加信息放在data属性里)。如果服务器将提供请求的证书状态信息,它会返回一个CertificateStatus消息(类型22)。
由于证书状态信息和OCSP密切相关,这个扩展也叫OCSP stapling。status_request扩展打开的OCSP stapling只支持一个OCSP响应,能用于检查一个服务器证书的撤销状态。RFC 6961开始,有了新的扩展类型status_request_v2,支持多个OCSP响应。

User Mapping

这基于一个通用机制,用来在TLS握手时交换补充数据。这个机制和消息流见下表。
客户端和服务器在他们能使用SupplementalData消息发送补充数据前,交换扩展的hello消息。使用这个机制,当调用客户端认证的时候,TLS扩展的user_mapping和SupplementalData格式的载荷能把用户映射到他们的帐号。客户端能在ClientHello消息里发送该扩展,服务器能在ServerHello消息里确认。然后,客户端把用户映射数据放在SupplementalData消息里发给服务器。然后,服务器解析和使用该数据。
The TLS handshake protocol supporting the exchange of supplemental application data

Authorization

TLS协议只提供授权(authorization),不提供认证(authentication)。
TLS扩展client_authz是指客户端支持的authorization数据格式,和server_authz是指服务器支持的authorization数据格式。该扩展可以在hello消息里发送。类似用户映射的机制,实际的authorization数据放在SupplementalData消息里。也可以不直接提供数据,而是提供一个URL做在线检索。
可能有很多种authorization数据格式。比如属性证书(attribute certificates)和安全断言标记语言(SAML)。AC是一个数字签名的数据结构,证明它持有的一些属性(代替公钥),它使用通用的subject属性链接到一个公钥证书。SAML断言类似AC,但是语法不一样。

Certificate Types

有两种相互竞争的公钥证书标准:X.509和(Open)PGP,SSL/TLS协议只支持X.509证书。X.509证书无效或者有更合适的非X.509证书的时候,可以使用扩展cert_type。
cert_type的data属性是支持的证书类型列表,目前只支持X.509(0)和OpenPGP(1)。服务器收到消息,选择证书需要的加密套件,或者选择客户端支持的证书类型,或者使用unsupported_certificate告警结束连接。对于第一种情况,服务器必须编码选择的证书类型,放到ServerHello消息的cert_type扩展内。
协商的证书类型也会影响Certificate消息内的证书。如果协商使用X.509证书,证书就是这个类型的。如果协商使用OpenPGP证书,证书就是这个类型的。这时候,服务器发给客户端的CertificateRequest消息(服务器能接受的CA类型),必须是空的(OpenPGP证书是通信实体发布的,而不是CAs)。

Elliptic Curve Cryptography

ECC技术允许使用短key(安全级别相同)。TLS可以使用五种基于ECC的key交换算法,他们都使用elliptic curve version of the Diffie-Hellman (ECDH) key交换算法,他们的区别仅在于ECDH keys的使用寿命不同。第五种算法是匿名的,不能用于认证。

  • ECDH_ECDSA:使用长期ECDH keys和ECDSA签名的证书。服务器的证书必须包含一个长期的ECDSA签名的ECDH公钥,不需要发送ServerKeyExchange消息。客户端用与服务器长期公钥相同的椭圆曲线生成ECDH key对,使用ClientKeyExchange发送自己的公钥。然后,客户端和服务器执行ECDH key交换,生成pre master secret。
  • ECDHE_ECDSA:使用短暂的ECDH keys和ECDSA签名的证书。服务器的证书必须包含一个使用ECDSA签名的ECDSA公钥。服务器使用ServerKeyExchange消息发送它的短暂的ECDH公钥和相应的椭圆曲线规范。参数是使用ECDSA签名的,使用服务器证书里的公钥对应的私钥。客户端使用相同的椭圆曲线生成另一个ECDH key对,使用ClientKeyExchange消息把公钥发给服务器。然后,客户端和服务器执行ECDH key交换,生成pre master secret。
  • ECDH_RSA:使用长期ECDH key和RSA签名的证书。key交换算法除了服务器证书使用RSA做签名以外,和ECDHE_ECDSA相同。
  • ECDHE_RSA:使用短暂的ECDH key和RSA签名的证书。key交换算法和ECDHE_ECDSA有以下不同:服务器证书必须包含一个RSA公钥的授权签名,ServerKeyExchange消息里的签名必须由对应的私钥签名,服务器证书使用RSA签名。
  • ECDH_anon:使用匿名的ECDH key交换,没有认证。使用ServerKeyExchange和ClientKeyExchange交换ECDH公钥。

ECDHE_ECDSA和ECDHE_RSA key交换算法提供PFS,其他的不提供。五种算法里的每一个能被组合任何加密和hash函数形成加密套件。
有两种TLS扩展使用ECC:elliptic_curves和ec_point_formats。当一个客户端想支持ECC,就在ClientHello消息里包括一个或这两个扩展。

  • elliptic_curves:客户端通知服务器,它能支持椭圆曲线。
  • ec_point_formats:客户端通知服务器,想压缩某些曲线参数。实践中不好用。

不管如何,这些扩展告诉服务器选择椭圆曲线,和决定是否压缩,返回的选择包含在ServerHello消息内。然后,客户端和服务器就可以使用ECC了。

SRP Protocol

由于其易受MITM攻击,Diffie-Hellman key交换必须总是做认证。使用密码最简单明了,所以有很多密码认证的Diffie-Hellman key交换提案,这些提案很容易遭到字典攻击。后来提出了加密的key交换(EKE)概念,至少有一方使用password加密一次性的公钥,然后送给另一方,然后解密,用来协商共享的key。password不容易遭受字典攻击,因为它是一个加密的随机值。
secure remote password (SRP)协议就是这样一个实现。TLS握手的时候,可以使用SRP协议实现客户端认证。它补充了使用公钥证书,预共享密钥或Kerberos进行客户端身份验证。SRP协议是Diffie-Hellman key交换的一个变种,可以和任何加密和hash函数组合,形成加密套件。
如果客户端想使用the协议执行key交换,它使用带srp扩展的ClientHello消息,如果服务器也支持,就在ServerHello消息里返回这个扩展。客户端和服务器然后交换SPR的ServerKeyExchange和ClientKeyExchange消息,计算master secret。
SRP的使用并不广泛。

Signature Algorithms

有很多hash和签名算法。不同的客户端支持的也不同。supported_signature_algorithms是可选的,客户端用来告诉服务器,它支持哪些hash和签名算法。如果不使用该扩展,服务器假定支持SHA-1,并从客户端提供的密码套件中推断出支持的签名算法。
hash算法包括none (0), 26 MD5 (1), SHA-1 (2), SHA-224 (3), SHA-256 (4), SHA-384 (5)和SHA-512 (6)。
签名算法包括anonymous (0), RSA (1), 27 DSA (2)和ECDSA (3)。

Heartbeat

客户端和服务器都可以使用heartbeat扩展,确认之后,能互相发送heartbeat请求/响应。heartbeat(消息type是24)是又一个TLS子协议。
客户端能发送Heartbeat载荷,服务器返回相同的载荷。

Application-Layer Protocol Negotiation

TLS之上,有两种应用层协议的堆放策略:独立端口的或者向上协商的。第一种策略需要每种应用层协议有独立的端口,第二种策略需要应用层协议支持向上协商特性。如果一个TCP或者UDP端口上需要支持多个应用层协议,而这些协议又不支持向上协商特性,就可能在TLS握手结束的时候做应用层协议协商。这就需要application-layer protocol negotiation (ALPN),以前叫next protocol negotiation (NPN)。使用application_layer_protocol_negotiation扩展打开ALPN,支持ALPN,443端口上的支持TLS的服务也能默认支持HTTP1.0,也允许协商其他应用层协议,比如HTTP2.0和SPDY3.3。客户端可以在ClientHello消息里带application_layer_protocol_negotiation扩展,提交它支持的应用层协议列表。服务器然后在ServerHello消息里使用相同的扩展,告诉客户端他的决定。

Certificate Transparency

Google有一个项目叫Certificate Transparency (CT),用来解决Internet PKI的一些问题。CT项目的一个机制是,允许CA把它发布的每一个证书提交给公开的日志服务,返回一个提交证明-signed certificate timestamp (SCT)-它能提供给依赖方。

Raw Public Keys

有时候,需要原生的公钥,而不是复杂的公钥证书。
在握手的时候,可以使用client_certificate_type和server_certificate_type,实现认证。
key可能是RSA, DSA或者ECDSA,

EtA Instead of AtE

目前的SSL/TLS,合适的认证和加密的组合是EtA,而不是AtE。有些实现支持改变认证和加密操作的顺序,所以,可以在交换hello消息时,用encrypt_then_mac扩展协商这个顺序。
使用CBC加密以后,这个扩展是重要的。

Session Tickets

SSL握手协议可以恢复一个session。要调用这个1-RTT机制,服务器需要保存每个客户端的session状态。如果同时有大量的客户端,会消耗服务器的大量资源。可以把session状态信息当作一个session ticket发给客户端,在以后的某个时刻返回服务器以恢复session。这个思想有点类似HTTP cookies。
session_ticket扩展就是为此目的设计的,如果客户端支持session tickets,它的ClientHello消息里带上这个扩展发给服务器,
如果客户端不支持,该扩展为空。如果服务器不支持,它会忽略该扩展。如果服务器也支持该扩展,它返回一个带空的session_ticket的ServerHello消息(因为session状态还没确定)。服务器在结束握手之前,发送ChangeCipherSpec和Finished之前,发送一个NewSessionTicket的消息。
session ticket包含加密的session状态,可能还有加密套件master secret和ticket生存时间(单位是秒)等。
客户端接收到该消息,它缓存该session ticket。如果后来想恢复该session,就在ClientHello消息里带上session_ticket扩展(不为空),服务器解密和验证该ticket,恢复session。如果服务器想恢复该session,就在ServerHello消息里带一个空的session_ticket,紧接着发送一个NewSessionTicket的消息。如果服务器不想恢复该session,使用以前的办法握手(没有session_ticket扩展或者没有NewSessionTicket消息)。
The message flow of the TLS handshake protocol issuing a new session ticket

The message flow for an abbreviated TLS handshake protocol using a new session ticket

Secure Renegotiation

即使在使用renegotiation_info扩展的时候,人们仍然可以使用三次握手攻击(triple handshake attack)实现重协商攻击(renegotiation attack)。现在有了另一个扩展,extended_master_secret,他3确保每个TLS连接有一个不同的唯一的master key,这样能防止未知的key共享攻击(key-share attack)。

Summary

TLS 1.2的大部分扩展,都在ClientHello和ServerHello消息内。
NewSessionTicket(type是4)、CertificateURL(type是21)、CertificateStatus(type是22)和SupplementalData(type是23)消息是新的消息类型。

Cipher Suites

TLS 1.2协议规范里删除了使用DES和IDEA技术的加密套件。保留的加密套件是采用3DES或者AES的块加密或者采用RC4的流加密。
一些加密套件扩展了,以支持SHA-256。和以前的版本类似,TLS 1.2还支持默认的加密套件TLS_RSA_WITH_AES_128_CBC_SHA。

RFC 5116介绍了authenticated encryption with additional data (AEAD)算法,定义了注册这样的算法的接口。
AEAD对TLS 1.2很重要,对TLS 1.3更重要,因为TLS 1.3需要AEAD加密。AEAD算法在一次密码转换中,组合了加密(机密性)和认证(完整性)。AEAD是密码学研究中一个相对较新的领域,比如,可以使用块加密产生AEAD加密。AEAD加密可以认证没有加密的附加数据。这些附加数据可以是不能被默认加密的头信息。
在TLS里,附加信息包含TLSPlaintext结构或者TLSCompressed结构的顺序号,type、version和length属性。因为AEAD加密不包含separate MAC生成和验证,它不需要respective keys。它只使用encryption keys(client_write_key和server_write_key),没有MAC key。AEAD加密的输出是一个密文,只能被相同的值解密。
有时候,使用公钥太昂贵或者存在其他管理缺陷。这种时候,可能使用对称key更有利,在通信双方之间提前共享,建立TLS连接。
TLS协议规定了基于preshared keys (PSKs)支持认证的三种加密套件集:

  • 第一种加密套件(PSK key交换算法)只使用secret key算法,用于受限环境
  • 第二种加密套件(DHE_PSK key交换算法)使用PSK认证,暂时的Diffie-Hellman key交换
  • 第三种加密套件(RSA_PSK key交换算法)服务器使用基于RSA的认证,客户端认证使用PSK
展开阅读全文

没有更多推荐了,返回首页