背景

传输层安全性协议(英语:Transport Layer Security,缩写:TLS)及其前身安全套接层(英语:Secure Sockets Layer,缩写:SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。网景公司(Netscape)在1994年推出首版网页浏览器-网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。IETF将SSL进行标准化,1999年公布TLS 1.0标准文件(RFC 2246)。随后又公布TLS 1.1(RFC 4346,2006年)、TLS 1.2(RFC 5246,2008年)和TLS 1.3(RFC 8446,2018年)。在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中,广泛使用这个协议。许多网站,如Google、Facebook、Wikipedia等也以这个协议来创建安全连线,发送资料。目前已成为互联网上保密通信的工业标准。

SSL包含记录层(Record Layer)和传输层,记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证,之后利用非对称加密演算来对通信方做身份认证,之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的资料做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。

发展历史

  • 1.0版本从未公开过,因为存在严重的安全漏洞。
  • 2.0版本在1995年2月发布。2011年,RFC 6176 标准弃用了SSL 2.0。
  • 3.0版本在1996年发布,是由网景工程师保罗·科切、Phil Karlton和Alan Freier完全重新设计的。2015年,RFC 7568 标准弃用了SSL 3.0。
  • IETF将SSL标准化,即 RFC 2246 ,并将其称为TLS(Transport Layer Security),于1999年发表。
  • TLS 1.1在 RFC 4346 中定义,于2006年4月发表,它是TLS 1.0的更新。微软、Google、苹果、Mozilla四家浏览器业者将在2020年终止支持TLS 1.0及1.1版。2021年3月,RFC 8996标准弃用了TLS 1.0和TLS 1.1。
  • TLS 1.2在 RFC 5246 中定义,于2008年8月发表。它基于更早的TLS 1.1规范。
  • TLS 1.3在 RFC 8446 中定义,于2018年8月发表。
协议 发布时间 状态
SSL 1.0 未公布 未公布
SSL 2.0 1995年 已于2011年弃用
SSL 3.0 1996年 已于2015年弃用
TLS 1.0 1999年 于2021年弃用
TLS 1.1 2006年 于2021年弃用
TLS 1.2 2008年
TLS 1.3 2018年

从时间上看,TLS 1.0 协议已经有20年历史了,确实要退出历史舞台了。

目前TLS协议主流的版本是 v1.2,那么和 v1.0 和 v1.1 版本相比,它有那些优势呢?或者说 v1.0 和 v1.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 和 v1.1版本确实可以宣告死亡了,但为什么值得现在他们仍然还存活着?兼容性,这是一种妥协,因为世界上还有很多设备(比如 XP/IE8)不支持现代化的密码算法(比如GCM),所以HTTPS服务部署者不能强制使用 V1.2版本,这是在用户体验和安全性上的一个折中。

有的同学说,大部分浏览器使用v1.2版本连接我的网站,那么为了兼容老设备,服务器同时也只支持v1.0和v1.1版本,有何不可?还是安全性,只要你的服务器存在v1.0和v1.1版本,攻击者就会强制让你从v1.2降级到老版本,从而带来安全风险。

另外一个原因是如果想支持HTTP/2协议,必须构建于 TLS 1.2协议,它不支持 TLS 1.0 和 TLS 1.2版本。

TLS测试

可以通过openssl这个工具,使用以下命令来测试服务器端使用哪个版本的TLS。

openssl s_client -connect www.baidu.com:443 -tls1 2> /dev/null | grep -i -E "cipher|protocol"
openssl s_client -connect www.baidu.com:443 -tls1_1 2> /dev/null | grep -i -E "cipher|protocol"
openssl s_client -connect www.baidu.com:443 -tls1_2 2> /dev/null | grep -i -E "cipher|protocol"
openssl s_client -connect www.baidu.com:443 -tls1_3 2> /dev/null | grep -i -E "cipher|protocol"

如果不支持此TLS版本的话,会显示类似以下信息:

New, (NONE), Cipher is (NONE)
    Protocol  : TLSv1.1
    Cipher    : 0000

支持此TLS版本的话,会显示类似以下信息:

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

nginx配置

nginx 有个ssl_protocols参数,用于配置支持的SSL版本。但是重点在于,需要在配有default_serverserver域里面配置才可以生效。
比如:

server {
    listen 80 default_server;
    listen 443 default_server;

    server_name _;

    ssl_certificate /usr/local/nginx/conf/ssl/www.pem;
    ssl_certificate_key /usr/local/nginx/conf/ssl/www.key;

    access_log /usr/local/nginx/logs/default.access.log;
    error_log /usr/local/nginx/logs/default.error.log;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
    ssl_prefer_server_ciphers on;

    location / {
            ...
    }
}

TLSv1.1 和 TLSv1.2 参数(1.1.13、1.0.12)仅在使用 OpenSSL 1.0.1 或更高版本时有效。
TLSv1.3 参数 (1.13.0) 仅在使用 OpenSSL 1.1.1 或更高版本时有效。

修改完后,执行nginx -s reload重载生效即可。

在 Tim Butler 的《NGINX Cookbook》中提到

We add the defanlt_server so that NGINX has a default configuration it will use during the negotiation phase. This is because the Server Name Indication(SNI) only occurs after the connection has been negotiated.Without specifying the default_server directive, the initial handshake would revert to TLS 1.0(the NGINX default).
我们添加了 defanlt_server 以便 NGINX 有一个默认配置,它将在协商阶段使用。这是因为Server Name Indication(SNI)仅在协商连接后发生,如果没有指定 default_server 指令,初始握手将恢复为 TLS 1.0(NGINX 默认值)。

所以需要把ssl_protocols配置在default_serverserver域里,在建立连接协商阶段就决定使用TLS哪个版本来建立连接。

参考:
https://serverfault.com/questions/704376/disable-tls-1-0-in-nginx/704382
https://www.jianshu.com/p/c2ab354b679a
https://zh.wikipedia.org/zh-cn/傳輸層安全性協定