传输层安全协议TLS/SSL

部分链接可能需要使用Google才能打开

描述：

传输层安全协议TLS(Transport Layer Security)是设计用来保护网络通信过程中信息的私密性的一种工业标准，允许客户机，服务器应用程序可以探测到安全风险，包括消息篡改（message tampering）,消息拦截（message interception）,消息伪造（message forgery），其前身是安全套接字层协议SSL（Security Socket Layer）,有时这两者都被成为SSL。作为计算机网络安全通信的协议，被广泛应用于网页浏览器，邮箱，网络传真，即时消息通信等。大部分的网站都是用TLS保护服务器和网页浏览器之间的所有通信。
传输层安全协议的最初目标是为两个应用程序提供通信的私密性和数据的完整性。是由SSL协议发展而来的，其历史:

Protocol	Year
SSL 1.0	N/A
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0	1999
TLS 1.1	2006
TLS 1.2	2008
TLS 1.3(draft)	TBD

SSL 1.0, 2.0 和3.0

Netscape 公司最初开发了SSL协议，1.0版本由于有严重的安全缺陷没有公开发布。2.0版本也有一些安全问题，所以最后发布了SSL 3.0, 3.0版本基于以前的版本几乎是做了重新设计。SSL 3.0由互联网工程任务组（IETF: Internet Engineering Task Force）在1996年起草发布，并保存进了网络通信协议发布常用的文档 RFC6101中。该协议由安全套接字记录协议（SSL Record Protocol）和安全套接子握手协议（SSL Handshake protocol）两部分组成。

Tacher Elgamal博士被认为是“SSL之父”，他在1995年到1998年担任Netscape公司的首席科学家。现在是salesforce.com的CTO，他在密码学领域和信息安全领域非常有成就。其中就有以他名字命名的Elgamal加密算法, 我另写一片文章来介绍Elgamal加密算法。

但是SSL3.0现在也已经是过时且不安全的协议，被暴露出安全问题。Google安全团队在2014年10月14号公布了“贵宾犬”攻击，即POODLE Attack（Padding Oracle On Downloaded Legacy Encryption vulnerability），利用该漏洞，黑客以中间人身份可以攻击支持SSL3.0协议的浏览器和支持SSL3.0协议服务器端的通信，使握手协议失败，实现降级攻击，由于SSL3.0使用的CBC块加密（Cipher Block Chaining mode encryption）实现存在漏洞，则攻击者可以破解SSL连接的加密信息，获取用户cookie数据，详细信息可以参考这里pdf。由于考虑到兼容性，在发现该漏洞之前很多浏览器都是向后支持SSL 3.0的，后来Chrome, Mozilla, IE，Safari等都相继禁止了对SSL 3.0的支持。

TLS 1.0, 1.1 ，1.2 和 1.3

TLS 1.0就是SSL 3.0的两位开发者开发出来的SSL3.0协议升级版，可以降级到SSL 3.0，但是由于采用的算法不同，两者之间不具备互操作性。TLS协议是互联网工程任务组为了规范和提高安全性提出的新的协议，写入RFC中。

TLS 1.1版本添加了针对CBC（cipher-block chaining）块攻击的保护。

TLS 1.2对加密套件和握手协议中的算法做了改进，用SHA-256代替原来的MD5-SHA-1，还做了一些扩展,支持经过身份认证的加密技术（authenticated encryption ciphers），高级加密标准加密(Advanced Encryption Standard)等，TLS 1.2版本还彻底移除了TLS会话中通过协商使用SSL 2.0不安全协议的支持。

TLS 1.3还没有正式的公布，互联网工程任务组（IETF）正在起草，与TLS 1.2相比，移除了一些加密比较弱，更少使用的加密算法(Elliptic curve cryptography, MD5, SHA-224)，弃用静态加密算法RSA,禁用SSL添加新的Ed25519更加安全的数字签名算法，添加新的秘钥交换协议等。

Note:
关于TLS 1.3协议中的改进也可以参考Tim Taubert的这篇博客：
MORE PRIVACY, LESS LATENCY, Improved Handshake in TLS version 1.3

数字签名

使用公钥加密技术实现的用于鉴别数字信息的方法，由信息的发送者产生的别人无法伪造的一段数字串，放松方用一个哈希函数从报文中生成报文摘要（Digest）,然后使用自己的私钥对该摘要加密，加密后的摘要即时该报文的数字签名。接收方需要用和加密是一样的哈希函数从接收到的报文中算出报文摘要，然后再用发送发的公钥来对报文中的数字签名进行解密，对比两个摘要，如果相同，则该数字签名就是发送发的。

数字证书

数字证书是通信双方中持有公钥和个人唯一信息的由信任的第三方权威机构CA（Certificate Authority）颁发的授权证书，通信中的另一方可以利用其中的签名和声明来识别对方身份，生成相对应的秘钥，验证有效期等。

Note:
关于数字签名和数字证书比较通俗的理解可以参考这两篇博客，里面有插图说明：
* 英文原文：What is a Digital Signature?
* 中文翻译：数字签名是什么？

类似的一个证书如下：


Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org Validity Not Before: Nov 20 05:47:44 2001 GMT Not After : Nov 20 05:47:44 2002 GMT Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org Subject Public Key Info: Public Key Algorithm: rsaEncryption  RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a: 9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36: b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4: 7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86: 08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd: 94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25: da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e: 42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a: 6c:14:e2:ae:62:e7:6b:30:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated CertificateX509v3 Subject Key Identifier:FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F X509v3 Authority Key Identifier:keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org serial:00Signature Algorithm: md5WithRSAEncryption34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd: aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57: 2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96: 34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62: e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5: 0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06: ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE-----

TLS 握手协议

TLS 握手协议包含以下几个步骤：

客户机端发送一条“Client Hello”消息到服务器端，同时发送客户机端生成的一个随机数和客户机端支持的加密算法
服务器端回应“Server Hello”到客户机端，同时回应服务器端生成的随机数
服务器端发送他的数字证书到客户机端进行身份验证，同时有可能请求客户机端的证书以验证客户机身份。服务器端发送“Server Hello done”消息
如果上一步服务器端请求了客户机端的证书，则客户机发送它的证书到服务器端接受验证
客户机端用刚才的随机数生成一个预主密钥（Pre-master Secret）,并使用来自服务器数字证书中的公钥加密该预主密钥，然后发送到服务器端
服务器接收到预主密钥，通过私钥解密后得到该预主密钥，同时服务器端和客户机端都使用该预主密钥采用加密算法生成主密钥（Master Secret）和会话密钥
客户机端发送“Change cipher spec”通知服务器端将采用新的会话密钥和哈希函数加密消息，并发送“Client finished”消息
服务器端接收到“Change cipher spec”消息，切换TLS记录协议到使用新生成的会话密钥的对称加密中，并发送“Server finished”消息到客户机端
客户机和服务器开始使用新的会话密钥加密的安全通道交流应用程序发送的数据

时序图如下：

Client Hello:

握手协议的第一条信息，由于是客户机请求通信，所以该消息涉及一些客户机准备使用的和服务器通信的选择，有TLS版本，客户机能支持的加密套件，客户机使用的压缩方法。还有为确立安全通信生成的32字节的随机数，还有一个空的会话ID。即五部分内容：

可支持的TLS版本	可支持的加密算法	可用的压缩方法	32字节的随机数	空的Session ID

Server Hello:

握手协议的第二条信息，在该信息中，服务器基于第一条Client Hello中的信息作出选择，选择TLS版本，填上会话ID, 随机数中的前4字节被日期和时间戳取代，剩下的28字节被密码安全随机数生成的随机数取代。

选定TLS版本	选定加密算法	选定压缩算法	4字节时间戳+28字节随机数	特定Session ID

TLS 记录协议

TLS记录协议是使用TLS握手协议中生成的会话密钥，TLS记录协议负责加密应用程序的数据和验证其完整性。主要管理：

划分输出消息为可管理的数据块，整合输入消息
压缩输出的消息块和解压缩输入消息块（可选择）
应用消息认证代码（MAC: Message Authentication Code）到输出消息，使用MAC验证输入消息
加密输出消息，解密输入消息。

当TLS 记录层完成加密，加密的数据发送到下一层的传输控制层（TCP: Transmission Control Protocol）传输