tls1.2_ie11不支持tls1.2 - CSDN
精华内容
参与话题
  • 浅析TLS 1.2协议

    千次阅读 2018-05-05 09:54:06
    0x01 TLS 1.2 简介 TLS概述:TLS和他的前身SSL,都是提供在计算机网络上安全通信的密码学协议,最常见就是用于HTTPS中,用来保护Web通信的。 发展史:网景公司开发了原始的SSL协议,SSL 1.0因为本身存在着严重的...
        

    0x01 TLS 1.2 简介

    • TLS概述:TLS和他的前身SSL,都是提供在计算机网络上安全通信的密码学协议,最常见就是用于HTTPS中,用来保护Web通信的。
    • 发展史:网景公司开发了原始的SSL协议,SSL 1.0因为本身存在着严重的安全问题,所以从未被公开发布。只有SSL 2.0和SSL 3.0是被公开发布和使用的。后来为了对SSL进行标准化,推出了TLS,TLS 1.0就对应着SSL 3.0。TLS后来又有了1.1版本和1.2版本,1.3版本目前还在草案中。现在除了TLS 1.2和TLS 1.3草案之外,所有早期的协议都存在安全性问题,不建议使用。
    • 我们今天的话题是TLS 1.2,首先分析TLS 1.2的整个体系结构,然后会借助其通信的报文进行详细分析。

    0x02 TLS 1.2 的体系结构

    • 首先TLS是一个高层协议,工作在计算机网络五层模型的上面两层,也就是Transport层(传输层)和Application层(应用层)。
    • 今天主要介绍的是TLS 1.2在HTTPS环境下的应用。TLS 1.2不止可以用于Web通信,还可以用于其他的通信方式,只是今天以Web通信为例介绍。
    • 整个TLS 1.2的概述:TLS 1.2实际上目的是在Web服务器和客户端浏览器之间建立安全连接。要想建立安全连接,必须通过密钥交换协议协商出一个共同的密钥(一般我们称为Handshake),然后再利用对称密码进行加密传输 [1]。这个过程中为了避免中间人攻击,还需要通过数字证书保护公钥 [2]。这些就是TLS 1.2的基本任务,即——证书认证、密钥协商以及加密传输。
    [1] 对称密码体制要求通信双方必须有一个两方都知道的密钥,这个密钥必须通过保密的方式传送,而实际上计算机网络本身并不保密。所以如何在不安全的网络上“协商”出一个安全密钥,这是个很大的问题。详见密钥交换协议。

    [2] 通过公钥密码体制,允许双方各持有公钥和私钥进行通信,但是密钥的协商过程中依旧可能被欺骗,这称为中间人攻击。数字证书是为了解决这个问题。详见数字证书。

    • 所以从整体来看,TLS 1.2做了以下的工作:在TCP连接建立之后,首先客户端验证服务器的证书,在安全性要求高的情况下服务器还会验证客户端的证书。然后两者开始协商加密密钥,协商完成之后,就利用这个密钥开始加密通信了。我们通过实际的报文来看看这个过程。

    0x03 借助Wireshark分析TLS 1.2的通信流程

    1. 环境说明

    • 服务器IP地址:10.5.24.129
    • 服务器操作系统:openSUSE Linux (Leap 42.3)
    • 服务器软件:Apache
    • 服务器应用层协议:HTTP 2.0、TLS 1.2
    • 客户端IP地址:10.5.24.130
    • 客户端操作系统:openSUSE Linux (Leap 42.3)
    • 客户端软件(浏览器):Mozilla Firefox 57.0
    • 网络拓扑:客户端和服务器直接通过交换机连接,不经过任何路由。
    • 捕获软件:Wireshark 2.2

    2. TCP的三次握手

    • 前三个报文是TCP建立连接的过程,本例中客户端首先发起连接,客户端向服务器发送SYN报文,服务器接收到之后回复SYN ACK确认,之后客户端再向服务器发送ACK确认。通过三次交互,一个TCP连接就建立起来了。
    • 本文无意讨论TCP三次握手的过程,读者如果不理解的可以查阅相关资料,这里只需要理解这三次握手是通过TCP协议通信的必经之路就好了。
    • 需要注意的是,如果按照HTTP协议的规定,建立TCP连接之后,就可以正式开始通信了,客户端可以构建HTTP请求,来请求服务器上的页面,服务器也会按照要求进行响应。但是这个过程是完全不进行加密的,并没有安全性可言。这部分属于TCP的范畴,下面我们才真正开始讨论TLS 1.2。

    3. Client Hello

    • 客户端发送的,属于TLS握手协议(TLS handshake)的一部分,其内容包括客户端的一个Unix时间戳(GMT Unix Time)、一些随机的字节(Random Bytes),还包括了客户端接受的算法类型(Cipher Suites),本例中Mozilla Firefox 57.0允许15种算法,浏览器认为这些算法是可以被信任的。这是最基本的部分,同时还有其他的扩展参数,这里就不做介绍了。
    • Client Hello的目的就类似于SYN,客户端对服务器公布自己支持的算法等等,同时也附带请求服务器证书的意思。这里不验证客户端证书,所以Client Hello就只有这些内容。

    4. Server Hello

    • 服务器发送的,同样属于TLS handshake,内容包括服务器的GMT Unix Time以及Random Bytes,和上面类似就不再解释。这时候服务器会将自己支持的算法类型发送给客户端,以便于客户端进行验证,这里我的服务器使用的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,也就是使用AES-128的GCM模式进行对称加密,同时以带SHA-256的RSA作为签名算法,用ECDHE做密钥交换的一整套协议。我的服务器也算是主流安全啦~
    • Server Hello目的就是服务器对客户端公布自己的算法,以便于后续操作。

    5. Certificate

    • 服务器或者客户端发送的,依旧属于TLS handshake,它一般和Server Hello在同一个TCP报文中传送。显然的,这里服务器将自己的数字证书发送给客户端,客户端就会进行证书验证,如果不通过的话,客户端会中断握手的过程。如果也要求客户端提供证书的话,Client Hello后面也会紧跟着该报文,形式完全一样,就不再解释了。

    6. Server Key Exchange

    • 服务器发送的,属于TLS handshake,一般也和Server Hello与Certificate在一个TCP报文中。服务器将自己的公钥参数传输给了客户端,因为使用的是ECDHE,这里传输的内容有:椭圆曲线域参数,以及公钥的值。
    • 这个就是密钥交换协议的一部分,最终协商出密钥来。

    7. Server Hello Done

    • 服务器发送的,属于TLS handshake,一般也和Server Hello、Certificate和Server Key Exchange在一个TCP报文中,介于Server Hello和Server Hello之间的是服务器想要给客户端的东西。所以这里面客户端没有发送Client Hello Done

    8. Client Key Exchange

    • 客户端发送的,属于TLS handshake,客户端收到了服务器的证书进行验证,如果验证通过了,就会继续密钥交换的过程,向服务器发送自己的公钥参数。待服务器收到之后进行数学计算,就可以协商出密钥了,这里客户端实际上已经计算出了密钥。

    9. Change Cipher Spec

    • 客户端或者服务器发送的,属于TLS handshake,紧跟着Key Exchange发送,代表自己生成了新的密钥,通知对方以后将更换密钥,使用新的密钥进行通信。

    10. Encrypted Handshake Message

    • 客户端或者服务器发送的,属于TLS handshake,也是紧跟着Key Exchange发送。这里是进行一下测试,一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方,如果密钥协商正确无误的话,对方应该可以解密。这段加密内容的明文一般是协议中规定好的,双方都知道。

    11. New Session Ticket

    • 服务器发送的,属于TLS handshake,服务器给客户端一个会话,用处就是在一段时间之内(超时时间到来之前),双方都以刚刚交换的密钥进行通信。从这以后,加密通信正式开始。

    12. Application Data

    • 应用层的数据,是加密的,使用密钥交换协议协商出来的密钥加密。因为我们的Wireshark不知道服务器的私钥,所以这段通信是安全的,我们在Wireshark中也无法解密这段信息。

    13. Encrypted Alert

    • 客户端或服务器发送的,意味着加密通信因为某些原因需要中断,警告对方不要再发送敏感的数据。

    0x04 总结

    • 本文粗略的介绍了TLS协议的1.2版本的通信过程,重点是handshake的过程,以上部分完成了证书认证、密钥协商以及加密传输的任务。
    • 在我看来,计算机网络有一种独特的魅力,那就是人们在设计网络协议的时候,也完全是按照人类的思维进行的设计。实际上在各种各样的网络协议中,处处流淌着人类的思想,体现着人类的文化。就比如本文介绍的TLS,就好像服务器和客户端是两个人在对话一样。事实就是如此,计算机网络就是计算机之间“对话”的科学。这也是我对计算机网络的兴趣所在。
    展开全文
  • https站点强制通信协议TLSv1.2

    万次阅读 2017-07-03 13:56:48
    TLSv1.2协议支持具体要分三部分内容。 <一>服务器对TLSv1.2的支持。 <二>客户端设置对TLSv1.2的支持 <三>客户端默认通过TLSv1.2访问设置。 本文对上述三方面内容进行了解读。

    现在网络安全原来越重要,好多公司网站需要ssl支持,也就是要求客户通过https访问公司站点,由于TLSv1.1容易被黑客攻击,于是很多企业要求站点只提供TLSv1.2协议支持。

    对Java 程序,TLSv1.2的实现中, oracle 从JDK1.7 update96以后的版本才开始支持,IBM JDK 采用的是类似的方案。只有从JDK1.8开始才是默认支持的。

    https://bugs.openjdk.java.net/browse/JDK-7093640

    https://www.java.com/en/configure_crypto.html#enableTLSv1_2

    https://wiki.openssl.org/index.php/Manual:Ciphers(1) 参见TLSv1.2支持的cipher list.

    TLSv1.2协议支持具体要分三部分内容。

    <一>服务器对TLSv1.2的支持。

    具体要看服务器采用的是那种服务器,这里主要讲Apache web server 和Tomcat 为基础的web 服务器。

    Apache web server:

    更新文件 httpd-ssl.conf于如下路径:WebServer/conf/extra/


    做如下更改: 

    #Limit Protocol to TLSv1.2
    SSLProtocol +TLSv1.2


    #Update cipher suites to remediate variousencryption related vulnerabilities
    SSLHonorCipherOrder On
    SSLCipherSuiteECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256

     

    Tomcat:

     更新文件 wrapper.conf 文件于如下路径

     Tomcat/conf/ (Windows) or the setenv.shscript file (UNIX) with the following modifications:

     ·        添加参数 -Djdk.tls.client.protocols=TLSv1.2 在 Java Virtual Machine (JVM) arguments.

    针对AIX 环境参数变为-Dcom.ibm.jsse2.overrideDefaultProtocol="TLSv12".

    ·       如果Tomcat 配置了TLS , 更新文件 server.xml 在如下路径

    Tomcat/conf/, 如下. 在<Connector> 定义中, 更改 ciphers 和 sslProtocols 参数如下:

    ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA" sslProtocols="TLSv1.2"


    <二>客户端设置对TLSv1.2的支持

    现代浏览器对TLS 1.2 默认支持的版本如下: 
      
        Firefox: Next 6 months (either version 27 or 28) 
        IE version 11 
        Google Chrome 31 
        Opera 18 on Windows 
        Safari 7.0 on Mac 


      ①.打开Java Control Panel,查看Java支持的TLS版本

      ②.高级。拉到最下面。

                          

                                        

    为了你的浏览器在访问时不弹出不安全访问访问提示,你需要在浏览器中导入客户端证书。


    TrustError IE.png

    <三>客户端默认通过TLSv1.2访问设置。


    本文以httpClient 4.5.1为例,特别讲述了怎么让客户端程序强制通过TLSv1.2通信的代码修改。



    1. import org.apache.http.impl.client.DefaultHttpClient;  
    2.   
    3. public class SSLClient extends DefaultHttpClient {  
    4.         public SSLClient() throws Exception {  
    5.             super();  
    6.             SSLContext ctx = SSLContext.getInstance("TLSv1.2");  
    7.             X509TrustManager tm = new X509TrustManager() {  
    8.                 @Override  
    9.                 public void checkClientTrusted(X509Certi<a target=_blank target="_blank" href="http://superuser.com/questions/747377/enable-tls-1-1-and-1-2-for-clients-on-java-7">http://superuser.com/questions/747377/enable-tls-1-1-and-1-2-for-clients-on-java-7</a>ficate[] chain, String authType) throws CertificateException {  
    10.                 }  
    11.   
    12.                 @Override  
    13.                 public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {  
    14.                 }  
    15.   
    16.                 @Override  
    17.                 public X509Certificate[] getAcceptedIssuers() {  
    18.                     return null;  
    19.                 }  
    20.             };  
    21.             ctx.init(nullnew TrustManager[] { tm }, null);  
    22.             org.apache.http.conn.ssl.SSLSocketFactory ssf = new org.apache.http.conn.ssl.SSLSocketFactory(ctx,  
    23.                     org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);  
    24.             ClientConnectionManager ccm = this.getConnectionManager();  
    25.             SchemeRegistry sr = ccm.getSchemeRegistry();  
    26.             sr.register(new Scheme("https"443, ssf));  
    27.         }  
    28.     }  

    为了测试需要你可以通过如下代码来测试你的客户端环境,看你的客户程序可以采用的协议:


    1. public static void main(String[] args) throws Exception {  
    2.         SSLContext context = SSLContext.getInstance("TLS");  
    3.         context.init(nullnullnull);  
    4.   
    5.         SSLSocketFactory factory = (SSLSocketFactory) context.getSocketFactory();  
    6.         SSLSocket socket = (SSLSocket) factory.createSocket();  
    7.   
    8.         String[] protocols = socket.getSupportedProtocols();  
    9.   
    10.         System.out.println("Supported Protocols: " + protocols.length);  
    11.         for (int i = 0; i < protocols.length; i++) {  
    12.             System.out.println(" " + protocols[i]);  
    13.         }  
    14.   
    15.         protocols = socket.getEnabledProtocols();  
    16.   
    17.         System.out.println("Enabled Protocols: " + protocols.length);  
    18.         for (int i = 0; i < protocols.length; i++) {  
    19.             System.out.println(" " + protocols[i]);  
    20.         }  
    21.   
    22.     }  



    展开全文
  • Tls升级-将tls从1.0升级到1.2

    万次阅读 2018-12-18 15:22:26
    背景: 某人在开发微信小程序时,调用测试环境的https接口,该接口由nginx提供代理服务,报错,说是不支持tls1 ,需要升级到tls1.2 环境: Ubuntu 16.04.5 LTS 查看ssl版本 1 cmd openssl s_client -connect ...

    背景: 某人在开发微信小程序时,调用测试环境的https接口,该接口由nginx提供代理服务,报错,说是不支持tls1 ,需要升级到tls1.2

    环境: Ubuntu 16.04.5 LTS

    查看ssl版本

    1 cmd

    openssl s_client -connect domain:443 -tls1 (-tls1_1, -tls1_2)
    其中domain 表示nginx 域名配置中使用https的域名,以上命令可以查看,目前nginx支持的tls版本。

    2 chrome

    依次打开: 右键->审查(inspect) ->安全(security)。

    然后在当前页面访问配置的域名。然后 安全(security) 下点击要查看的域名,即可在右侧的连接中的协议下,看到 tls 版本号。
    在这里插入图片描述

    升级操作总共分三步:
    1 升级openssl 2 重新编译nginx (这一步可以尝试不操作,因为自己看openssl是以动态库的方式使用,但是自己没有试过跳过这一步) 3,修改配置文件

    1 升级安装openssl

    常见的比较方便的做法是使用系统的软件管理工具, 比如 apt, yum等。具体做法,可以在网上找资料。
    此处还是使用源码手动安装:

    下载openssl

    在官网下载相应源码, https://www.openssl.org/source/

    解压后安装

    ./config 
    make
    sudo make install
    

    默认的安装目录:

    /usr/local/ssl/bin/openssl
    /usr/local/ssl/include/openssl
    

    所以现在可以查看你安装的openssl 版本:

    /usr/local/ssl/bin/openssl version -a
    

    创建软连接

    依次执行以下操作

    mv /usr/bin/openssl /usr/bin/openssl.old
    mv /usr/include/openssl /usr/include/openssl.old
    ln -s /usr/local/ssl/bin/openssl /usr/bin/openssl
    ln -s /usr/local/ssl/include/openssl/ /usr/include/openssl
    

    然后

    sudo vim /etc/ld.so.conf
    

    /usr/local/ssl/lib 添加到上面文件中,报错退出,然后通过以下命令,可以看到自己安装的openssl版本号。

    openssl version -a
    

    2 nginx 重编译

    由于之前别人是使用apt之间安装的nginx,当然可以直接重新编译生成nginx,然后替换 sbin/nginx,即可,具体实现,参见我之前文章,
    给网站添加ssl证书(https)https://blog.csdn.net/a1368783069/article/details/80719768 中的 nginx 安装ssl模块 方法。
    个人建议安装nginx使用手动编辑安装。
    从官网下载nginx源码。解压文件,使用默认安装。

    ./configure
    make
    sudo make install
    

    执行 sudo /usr/local/nginx/sbin/nginx 会提示没有安装与ssl 相关的modules, 则重新编译nginx

    1、 生成文件 进入nginx安装文件目录,执行:

    ./configure --with-http_ssl_module
    make
    1 2 2、 替换nginx
    首先关闭nginx服务(很重要)
    在nginx安装文件目录下面,会生成一个 objs 目录,将 objs/nginx替换
    /usr/local/nginx/sbin/nginx(两者都是nginx的可执行文件)。 重启nginx服务就行。
    /usr/local/nginx/sbin/nginx -s reload

    以上的操作,主要是理解nginx这种更新操作过程。
    如果想一步到位,安装nginx,检测环境的时候,可以直接

    ./configure --with-http_ssl_module
    make
    sudo make install
    

    3 更改nginx 配置文件

    原来的配置文件中,
    对ssl的设置时

    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2 ;
    

    所有配置文件中的 ssl_protocols 都改为(有的会配置多个网站,每个都需要改):

    ssl_protocols   TLSv1.2 TLSv1.1 TLSv1 ;
    

    或者只保留 TLSv1.2 。
    一般,可以检测配置文件是否有问题

    /usr/local/nginx/sbin/nginx   -t
    

    然后查看ssl 版本号。

    其他

    查看nginx安装使用的配置,以及添加的模块

    nginx -V
    

    参考文章:
    为CentOS升级OpenSSL 让Nginx支持TLS 1.2
    https://www.sunbloger.com/2016/12/26/543.html

    nginx 配置TLS1.2无效总是TLS1.0 https://blog.csdn.net/wanderstarrysky/article/details/53336129

    展开全文
  • TLS1.2 规范

    2012-06-11 15:09:58
    TLS1.2协议 共包含rfc5246 rfc5746 rfc5878 rfc6176几个部分
  • SSL和TLS-TLS 1.2

    千次阅读 2018-11-12 11:00:30
    SSL和TLS-TLS 1.2TLS ExtensionsServer Name IndicationMaximum Fragment Length NegotiationClient Certificate URLTrusted CA KeysTruncated HMACCertificate Status RequestUser MappingAuthorizationCertificate...

    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长度是214。TLS也还是这样。有时候,因为带宽限制,需要较小长度的fragment。
    max_fragment_length扩展(type等于1)可以由客户端告诉服务器,需要协商一个比较小的最大fragment长度。
    实际的最大长度,由data属性确定。值分别是1(代表29)、2(代表210)、3(代表211)和、4(代表212)。
    该长度在一个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消息里发给服务器。然后,服务器解析和使用该数据。
    The TLS handshake protocol supporting the exchange of supplemental application data

    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消息)。
    The message flow of the TLS handshake protocol issuing a new session ticket

    The message flow for an abbreviated TLS handshake protocol using a new session ticket

    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
    展开全文
  • TLS 1.0 RFC http://www.ietf.org/rfc/rfc2246.txt TLS 1.1 RFC ...TLS 1.2 RFC http://www.ietf.org/rfc/rfc5246.txt   TLS 1.3 见:https://blog.csdn.net/mrpre/article/deta...
  • TLSv1.2协议了解

    万次阅读 2019-03-23 00:17:53
    首先明确TLS的作用三个作用 (1)身份认证 通过证书认证来确认对方的身份,防止中间人攻击 (2)数据私密性 使用对称性密钥加密传输的数据,由于密钥只有客户端/服务端有,其他人无法窥探。 (3)数据完整性 使用...
  • 在Windows服务器上启用TLS 1.2TLS 1.2基本原理 2015-10-23 17:28 在Windows服务器上启用TLS 1.2TLS 1.2基本原理   最近由于Chrome40不再支持SSL 3.0了,GOOGLE认为SSL3.0已经不再安全了。所以也...
  • 传输层安全协议(TLS1.2

    万次阅读 2016-02-03 12:57:50
    这个协议由两层组成:TLS记录协议和TLS握手协议。最低层是基于一些可靠传输协议(如TCP)的TLS记录协议。TLS记录协议提供的连接安全有两个基本性质: 连接是私有的。对称密码学被用于数据加密(如:AES,RC4等)。...
  • 最近由于Chrome40不再支持SSL 3.0了,GOOGLE认为SSL3.0已经不再安全了。所以也研究了一下SSL TLS加密,给大家分享一下
  • 让XP兼容TLS1.2.rar

    2019-09-05 11:10:48
    让WindowsXP兼容TLS1.1和TLS1.2,首先要往注册表中写入项,再安装微软的补丁,重启系统后生效。
  • XP支持TLS1.1和TLS1.2.rar

    2020-08-25 21:54:12
    XP的IE8增加TLS1.1 1.2支持 将XP识别成POSReady 2009 。打上对应的补丁。最后更新证书就实现了。
  • 开发十年,就只剩下这套架构体系了! >>> ...
  • 用vs2010开发的web应用,部署在 IIS6.0 下,代码中用HttpWebRequest访问https TLS1.2网站,报protocolerror错误。 代码如下: C# code ... url="https://login.taobao.com/member/login.jhtml"; ServicePointManager...
  • php不支持TLS1.2解决方法php不支持TLS1.2解决方法php不支持TLS1.2解决方法
  • 补丁安装完之后还要重启系统修改注册表等操作,注意看文档
  • https://segmentfault.com/a/1190000006781741 参照这篇文章修改了注册表 ![图片说明]... 但实际效果确实 tls1.1 !... 检测结果显示好像还是不支持1.2 ...不知道该如何设置,才能开启使用TLS1.2,望大神解答
  • 修复internet用户和站点所有者的SSL/TLS握手失败错误 现在是发表另一篇技术文章的时候了,今天我们将讨论SSL/TLS握手失败错误及其修复方法。与许多SSL错误消息一样,这可以从客户端和服务器端触发,因此有时可以由...
1 2 3 4 5 ... 20
收藏数 23,646
精华内容 9,458
关键字:

tls1.2