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长度是2¹⁴。TLS也还是这样。有时候，因为带宽限制，需要较小长度的fragment。
max_fragment_length扩展（type等于1）可以由客户端告诉服务器，需要协商一个比较小的最大fragment长度。
实际的最大长度，由data属性确定。值分别是1（代表2⁹）、2（代表2¹⁰）、3（代表2¹¹）和、4（代表2¹²）。
该长度在一个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消息里发给服务器。然后，服务器解析和使用该数据。

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消息）。

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