一、什么是SSL/TLS
SSL: (安全套接字层), 位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层. SSL通过互联网互相认证、使用数字签名确保
完整性、使用加密确保私密性,以实现客户端和服务器之间的安全通讯. 该协议由两层组成: SLL记录协议和SSL握手协议.
TLS: (传输层安全协议), 用于两个应用程序之间提供保密性和数据完整性. 该协议由两层组成: TLS记录协议和TLS握手协议.
SSL是TLS的前身, SSL 1.0没有对外发布, SSL 2.0由于漏洞原因, 紧接着发布了SSL 3.0.
1999年基于SSL 3.0版本, 发布了TLS 1.0版本(虽然TLS 1.0在SSL 3.0基础上的改动不太大,但是这些改动都是非常重要的).
目前TLS的版本为:TLS 1.0(1999年)、TLS 1.1(2006年)、TLS 1.2(2008年)、TLS 1.3(2018年).
目前TLS 1.3还尚不成熟. SSL 2.0和SSL 3.0分别在2011年和2015年被弃用.而TLS 1.0和TLS 1.1也被证明极不安全.
二、TLS1.0和TLS1.1协议版本为什么要废弃
时间上, TLS 1.0协议已经有20年历史了, 确实要退出历史舞台.
目前TLS协议主流的版本是 TLS v1.2, 和TLS 1.0和TLS 1.1版本相比, 有一定优势:
1、性能: TLS 1.2有更快的密码学算法, 比如支持AEAD类的加密模式. 当然更重要的是安全性. TLS 1.0是SSL 3.0的一个简单升级, TLS 1.1在安全性方面又了
很大的提升, 并且引入了TLS扩展, 这是非常重要的改革; TLS 1.2版本是比较大的一个改造, 加强了密码套件的扩展性.
安全是相对的, 理论上TLS 1.0和TLS 1.1协议是安全的, 即使历史上出现一些安全问题, 也已经被TLS实现(OpenSSL)或客户端(比如浏览器)修复了, 但是在某种
程度上这二个版本仍然有安全风险, 主要原因在于某些密码算法已经被认为是不安全了(比如SHA1, RC4算法).
从安全性角度看V1.0和v 1.1版本确实可以宣告死亡了, 但依然存活的原因是兼容性问题, 很多社保(比如XP/IE8)不支持现代化的密码算法(比如GCM) ,所以HTTPS
服务器部署者不能强制使用V1.2版本, 这是在用户体验和安全性上的一个折中.
大部分浏览器使用V1.2版本连接我的网站, 为了兼容老设备, 服务器同时也支持V1.0和V1.1, 由于安全性,只要服务器存在该版本, 攻击者就会强制降级到老版本,从而
带来安全风险.
2、另外一个原因如果想支持HTTP/2协议, 必须构建于TLS 1.2协议, 它不支持TLS 1.0和TLS 1.1版本.
三、SSL/TLS协议介绍
SSL/TLS协议仅保障传输层安全. 同时, 由于协议自身特性(数字证书机制), SSL/TLS不能被用于保护多跳(multi-hop)端到端通信, 而只能保护点到点通信.
SSL/TLS协议能够提供的安全目标主要包括:
(1) 认证性 ----- 借助数字证书认证服务器和客户端身份, 防止身份伪造.
(2)机密性 ----- 借助加密防止第三方窃听.
(3)完整性 ----- 借助消息认证码(MAC)保障数据完整性, 防止消息篡改
(4)重放保护---- 通过使用隐式序列号防止重放攻击
为了实现这些安全目标, SSL/TLS协议被设计为一个两阶段协议, 分为握手阶段和应用阶段.
握手阶段: (也称为协商阶段), 在这一阶段, 客户端和服务器端会认证对方身份(依赖于PKI体系, 利用数字证书进行身份认证), 并协商
通信中使用的安全参数、密码套件以及MasterSecret. 后续通信使用的所有密钥都是通过MasterScecret生成.
握手阶段完成后, 进入应用阶段. 在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信.
SSL/TLS协议有一个高度模块化架构, 分为很多子协议:
Handshake协议: 包括协商安全参数和密码套件、服务器身份认证(客户端认证可选) 、密钥交换;
ChangeCipherSpec协议: 一条消息表面握手协议已经完成.
Alert协议: 对握手协议中一些异常的错误提醒, 分为fatal和warning两个级别, fatal类型的错误会直接中断SSL连接, 而warning级别的错误SSL链接仍可
继续, 只会给出错误警告.
Record协议: 包括对消息的分段、压缩、消息认证和完整性保护、加密等.
四、SSL/TLS协议流程详解
如下图是典型的TLS 1.0协议交互流程:
(1) Client Hello: 客户端向服务端打招呼, 携带各种信息(支持的密码套件种类、最高SSL/TLS协议版本以及压缩算法、随机数)提供服务端选择.
(2) Server Hello: 服务端回应客户客户端的招呼信息; 服务器从客户端在ClientHello中提供的密码套件、SSL/TLS版本、压缩算法列表里选择它所支持
的项,并把选择告知客户端. 另外ServerHello也包含一个随机数.
(3) Certificate: 客户端和服务器都可以发送证书来证明自己的身份, 但是通常客户端不被使用. 服务端向客户端发送自己的数字证书(此证书包含服务端的公钥),
以实现客户端验证身份;
SSL中使用的证书通常是X.509类型证书, X.509证书内容, 如图所示:
在用X.509证书包含Version 1和Version 3两种版本, 其中V1版本的证书存在安全隐患, 同时不支持TLS扩展, 被逐渐弃用. 现在大多数在用是V3版本.
同时证书会附带与协商好的密钥交换算法对应的密钥. 密钥交换算法以及他们所要求的密钥类型如下表所示:z
(4) Server Key Exchange: 服务端向客户端发送基于选择的加密套件生成的公钥( 此公钥是经过私钥签名认证的); 该消息仅当以下密钥交换算法被使用时
由服务器发出:
RSA_EXPORT(仅当服务器公钥大于512bit时)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon. 使用其他密钥交换算法时,
服务器不能发送消息.
ServerKeyExchange消息会携带这些密钥交换算法所需要的额外参数, 以在后续步骤中协商PreMasterSecret. 这些参数需要被签过名.
(5) Server Hello Done: 服务端向客户端表示响应结束.
(6) Client Key Exchange: 客户端向服务端发送经过公钥加密的Pre-Master.
如果选择的密钥交换算法是RSA，那么消息包含的参数为用服务器RSA公钥(包含在之前证书中的或者是ServerKeyExchange中的)加密过的PreMasterSecret，
它有48个字节，前2个字节表示客户端支持的最高协议版本，后46个字节是随机选择的。
如果选择的密钥交换算法是DH或者DHE，则可能有两种情况：
隐式DH公开值：包含在Certificate消息里;
显示DH公开值：公开值是本消息的一部分.
(7) CertificateVerify: 这条消息用来证明客户端拥有之前提交的客户端证书的私钥.
(8) Finished: 基于协商生成的密钥, 加密握手信息让服务端/客户端进行认证, 双方认证无误开始通信; 这是一条用协商的算法和密钥保护的消息.
同时Finished消息包含一个verify_data域, 可以用来校验之前发送和接收的信息.
Verify_data域是一个PRF函数的输出, 这个伪随机函数的输入为: 1、两个hash值: 一个SHA-1, 一个MD5, 对之前握手过程中交换的所有消息做
哈希 ; 2、the MasterSecret, 由预备主密钥生成; 3、finished_label, 如果客户端发送的则是“client finished", 服务器发送的则是“server fininshed",
此外finished消息不能够在ChangeCipherSpec前发送.
五：从SSL到TLS
本节介绍SSL/TLS协议的版本变迁，不同版本的区别以及安全特性等。
SSL 1.0由于从来没有被公开过，并且存在严重安全漏洞，我们就不讨论了。
SSL 2.0：SSL 2.0于1995年4月被发布。SSL 2.0中主要存在的问题如下：
MAC不能覆盖填充长度域，攻击者可能利用这点破坏消息完整性;
缺乏握手认证，攻击者可以篡改密码套件列表，诱骗通信双方使用较弱的密码套件;
使用较弱的或有问题的密码算法(如MD5，RC4等)，或者使用不安全的分组模式(如CBC模式);
对于不同的密码学基元使用相同的密钥，违背基本安全常识。
由于以上安全问题，RFC 6176已经明确提出避免使用SSL 2.0，但是现实生活中还有少量客户端和服务器支持SSL 2.0.
SSL 3.0：SSL 3.0引入了一些新的特性和机制解决了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子协议。SSL 3.0向后兼容SSL 2.0，相对于SSL 2.0，它的主要改变包括以下几点：
支持更多的密码套件(支持更多的密码算法如DSS，SHA-1)
在握手阶段支持密钥协商(DH和FORTEZZA)
支持密码学参数的重协商
增加了消息压缩选项
MAC能够覆盖填充长度域了，同时MAC可以使用MD5或者SHA-1
不同的密码学基元使用不同的key
Alert子协议能对任何错误给出两种提示：Warning和Fatal
中止链接的时候会用一个close_notify警告通知通信双方
支持证书链，而非单个证书
通过Finished消息认证所有发送和接收的消息
加密了的PreMasterSecret包含当前使用的协议版本，防止协议回滚
TLS 1.0：TLS 1.0和SSL 3.0差别非常小。实际上，TLS 1.0是SSL 3.1，在IETF接手后改名为TLS。TLS 1.0版本是目前使用最广泛的SSL/TLS协议版本。
TLS 1.0不再支持使用FORTEZZA的密码套件。
TLS 1.0中MAC被替换成HMAC。
之前提到ChangeCipherSpec消息必须在Finished消息前发送，在TLS 1.0中，如果消息序列不符合这个要求，会产生FATAL警告并终止链接。
TLS 1.1：这个版本相比之前改动也很小。最重要的改动是预防了针对CBC分组模式的一些攻击。现在的填充错误变的和非法MAC错误不可区分了，防止攻击者利用可区分错误
响应建立解密预言机对密文进行攻击。
在每次加密过程中，使用CBC分组模式时，都需要显示给出IV，而不用再密钥生成时使用PRF生成IV。
此外，TLS 1.1禁止为适应之前出口限制而使用弱化的密码套件。
TLS 1.2：这是最新的版本，部署的还比较少。这个版本禁用了PRF中的MD5和SHA-1，而用一个可配置的hash函数取代了它们，这样的修改简化了计算过程。修改后的PRF风格如下：
此外，TLS 1.2的一个重要变化是支持认证加密模式(支持GCM等)。但是由于一些AEAD(Authenticated Encryption with Associated Data)密码算法要求IV为隐式的，所以IV又恢复到由MasterSecret生成，即TLS 1.0以前的风格。
TLS 1.2支持使用GCM、CCM的新密码套件。
同时SSL 2.0被宣布放弃，不再向后兼容SSL 2.0.
六、SSL/TLS流行实现库
常见的SSL/TLS实现:
OpenSSL: 这是非常流行的开源SSL/TLS实现.
OpenSSLim完全用C语言实现, 支持SSL 2.0/3.0, TLS 1.0/1.1/1.2以及DTLS 1.0
OpenSSL近年来出现了很多的安全漏洞. 比如2014年的Heartbleed漏洞.
OpenSSL包括三方面组件: (1)openssl :多用途的命令行工具包 (2)libcrypto: 加密算法库, 包括openssl-libs (3)libssl: 加密算法实现模块库, 包括nss
JSSE : 这是用java实现的, 支持SSL 3.0, TLS1.0, TLS1.1, TLS 1.2
Bouncy Castle：它不仅仅支持SSL/TLS，它是一个完整的密码学库，支持各种密码学算法和协议。不过它仅仅支持TLS 1.0版本。安卓平台主要使用这个密码库.
GnuTLS：这是另一个用C语言实现的库，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同时以各种安全漏洞多而闻名。
其他还有一些常用的SSL实现库, 如cryptlib、CyaSSL、MatrixSSL、PolarSSL等. 市场占用率不高.