赞
踩
传输层安全性协议(英语: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)。这个会谈密钥是用来将通信两方交换的资料做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。
协议 | 发布时间 | 状态 |
---|---|---|
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版本。
可以通过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 有个ssl_protocols
参数,用于配置支持的SSL版本。但是重点在于,需要在配有default_server
的server
域里面配置才可以生效。
比如:
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_server
的server
域里,在建立连接协商阶段就决定使用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/%E5%82%B3%E8%BC%B8%E5%B1%A4%E5%AE%89%E5%85%A8%E6%80%A7%E5%8D%94%E5%AE%9A
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。