tls_贪婪算法 - CSDN
tls 订阅
安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。 展开全文
安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。
信息
外文名
Transport Layer Security
简    称
TLS
中文名
安全传输层协议
TLS简介
传输层安全性协议(英语:Transport Layer Security,缩写作TLS),及其前身安全套接层(Secure Sockets Layer,缩写作SSL)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。网景公司(Netscape)在1994年推出首版网页浏览器,网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。IETF将SSL进行标准化,1999年公布第一版TLS标准文件。随后又公布RFC 5246 (2008年8月)与RFC 6176(2011年3月)。在浏览器、邮箱、即时通信、VoIP、网络传真等应用程序中,广泛支持这个协议。主要的网站,如Google、Facebook等也以这个协议来创建安全连线,发送数据。目前已成为互联网上保密通信的工业标准。SSL包含记录层(Record Layer)和传输层,记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证,之后利用非对称加密演算来对通信方做身份认证,之后交换对称密钥作为会谈密钥(Session key)。这个会谈密钥是用来将通信两方交换的数据做加密,保证两个应用间通信的保密性和可靠性,使客户与服务器应用之间的通信不被攻击者窃听。 [1] 
收起全文
精华内容
参与话题
  • 什么是TLS

    2019-06-27 08:40:26
    最近在Istio实验中经常遇到HTTP,HTTPS,TLS等名词,感觉忘得差不多,需要复习一下计算机网络的知识了。 本文参考 http://www.techug.com/post/https-ssl-tls.html ... ...

        最近在Istio实验中经常遇到HTTP,HTTPS,TLS等名词,感觉忘得差不多,需要复习一下计算机网络的知识了。

       本文参考   http://www.techug.com/post/https-ssl-tls.html

                        https://blog.fleeto.us/post/istio-security-notes/

    1. “HTTP”是干嘛用滴?

    首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如你访问博客的主页,浏览器地址栏会出现如下的网址

    http://www.techug.com/

    加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。

    2. “SSL/TLS”是干嘛用滴?

    SSL 是“Secure Sockets Layer”的缩写,中文叫做“安全套接层”。它是在上世纪90年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”)
    为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。
    到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是“Transport Layer Security”的缩写),中文叫做“传输层安全协议”。
    很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

    3. “HTTPS”是啥意思?

    解释完 HTTP 和 SSL/TLS,现在就可以来解释 HTTPS 啦。咱们通常所说的 HTTPS 协议,说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。

    再来说说 HTTP 协议的特点

    作为背景知识介绍,还需要再稍微谈一下 HTTP 协议本身的特点。HTTP 本身有很多特点,只谈那些和 HTTPS 相关的特点。

    1. HTTP 的版本和历史

    如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是1995年底开始起草的(技术文档是 RFC2068),并在1999年正式发布(技术文档是 RFC2616)。
    在 1.1 之前,还有曾经出现过两个版本“0.9 和 1.0”,其中的 HTTP 0.9 【没有】被广泛使用,而 HTTP 1.0 被广泛使用过。

    2. HTTP 和 TCP 之间的关系

    简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。

    在网络分层模型中,TCP 被称为“传输层协议”,而 HTTP 被称为“应用层协议”。

    有很多常见的应用层协议是以 TCP 为基础的,比如“FTP、SMTP、POP、IMAP”等。
    TCP 被称为“面向连接”的传输层协议。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

    3. HTTP 协议如何使用 TCP 连接?

    HTTP 对 TCP 连接的使用,分为两种方式:俗称“短连接”和“长连接”(“长连接”又称“持久连接”,“Keep-Alive”或“Persistent Connection”)
    假设有一个网页,里面包含好多图片,还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。然后针对【每一个】外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开)
    相反,如果是“长连接”的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

    在 HTTP 1.0 版本,【默认】使用的是“短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接”的问题不大);
    到了1995年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有“时间成本”和“CPU 成本”滴)。所以,在 HTTP 1.1 中,【默认】采用的是“Keep-Alive”的方式。

    Istio双向 TLS 支持

    双向 TLS 支持主要针对的是通信方面,把明文传输的服务通信,通过转换为 Envoy 之间的加密通信。这一安全设置较为基础,可以在全局、Namespace 或者单个服务的范围内生效。

    这一功能主要通过两个 Istio CRD 对象来完成:

    Policy

    例如 Basic Authentication Policy 中的一个样例,用于给单个服务设置 mtls:

    apiVersion: "authentication.istio.io/v1alpha1"
    kind: "Policy"
    metadata:
      name: "example-2"
    spec:
      targets:
      - name: httpbin
      peers:
      - mtls:
    

    其中 target 是可选项,如果去掉的话,作用域将扩展到整个 Namespace。

    DestinationRule

    同样的一个例子里面的目标规则如下:

    apiVersion: "networking.istio.io/v1alpha3"
    kind: "DestinationRule"
    metadata:
      name: "example-2"
    spec:
      host: httpbin.bar.svc.cluster.local
      trafficPolicy:
        tls:
          mode: DISABLE
        portLevelSettings:
        - port:
            number: 1234
          tls:
            mode: ISTIO_MUTUAL
    

    这个也很容易理解,这一规则用于指派对该地址的访问方式:

    • tls.mode = DISABLE,这个服务缺省是不开启 tls 支持的,如果取值 ISTIO_MUTUAL,则代表这个地址(服务)的所有端口都开启 TLS。
    • port...ISTIO_MUTUAL,只针对这一个端口启用 mTLS 支持。

    创建 Policy 之后,Citadel 会生成证书文件,并传递给 Envoy,我们可以在 Envoy 容器(kube-proxy)的 /etc/certs/ 目录中看到这几个 *.pem 文件。如果使用 openssl x509 -text -noout 查看 cert-chain.pem 的证书内容,会看到 spiffe 编码的 ServiceAccount 内容来作为 SAN:

     X509v3 Subject Alternative Name:
                URI:spiffe://cluster.local/ns/default/sa/default
    

    规则生效之后,原有的服务间调用是没有差异的,但是如果在网格之外,就必须 https,结合上面谈到的证书来访问目标服务才能完成访问。

     

     

    转载于:https://www.cnblogs.com/yuxiaoba/p/9232427.html

    展开全文
  • HTTPS、SSL、TLS三者之间的联系和区别

    万次阅读 多人点赞 2018-08-17 17:52:54
    SSL(Secure Socket Layer 安全套接层)是基于HTTPS下的一个协议加密层,最初是由网景公司(Netscape)研发,后被IETF(The Internet Engineering Task Force - 互联网工程任务组)标准化后写入(RFCRequest For ...

    SSL(Secure Socket Layer 安全套接层)是基于HTTPS下的一个协议加密层,最初是由网景公司(Netscape)研发,后被IETF(The Internet Engineering Task Force - 互联网工程任务组)标准化后写入(RFCRequest For Comments 请求注释),RFC里包含了很多互联网技术的规范!

    起初是因为HTTP在传输数据时使用的是明文(虽然说POST提交的数据时放在报体里看不到的,但是还是可以通过抓包工具窃取到)是不安全的,为了解决这一隐患网景公司推出了SSL安全套接字协议层,SSL是基于HTTP之下TCP之上的一个协议层,是基于HTTP标准并对TCP传输数据时进行加密,所以HPPTS是HTTP+SSL/TCP的简称。

    由于HTTPS的推出受到了很多人的欢迎,在SSL更新到3.0时,IETF对SSL3.0进行了标准化,并添加了少数机制(但是几乎和SSL3.0无差异),标准化后的IETF更名为TLS1.0(Transport Layer Security 安全传输层协议),可以说TLS就是SSL的新版本3.1,并同时发布“RFC2246-TLS加密协议详解”,如果想更深层次的了解TLS的工作原理可以去RFC的官方网站:www.rfc-editor.org,搜索RFC2246即可找到RFC文档! ——以上就是历史背景

    SSL 是指安全套接字层,简而言之,它是一项标准技术,可确保互联网连接安全,保护两个系统之间发送的任何敏感数据,防止网络犯罪分子读取和修改任何传输信息,包括个人资料。两个系统可能是指服务器和客户端(例如,浏览器和购物网站),或两个服务器之间(例如,含个人身份信息或工资单信息的应用程序)。

    要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。
    1. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义
    2. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”)
    3. 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别)
    4. 大致了解 CA 证书的用途   5.TCP通信协议的几次握手

    TLS(传输层安全)是更为安全的升级版 SSL。由于 SSL 这一术语更为常用,因此我们仍然将我们的安全证书称作 SSL。但当您从赛门铁克购买 SSL 时,您真正购买的是最新的 TLS 证书,有 ECC、RSA 或 DSA 三种加密方式可以选择。

    TLS/SSL是一种加密通道的规范

    它利用对称加密、公私钥不对称加密及其密钥交换算法,CA系统进行加密且可信任的信息传输

    在HTTP SSL中常用的对称加密算法有RC4,AES,3DES,Camellia等

    SSL由从前的网景公司开发
    有1,2,3三个版本,但现在只使用版本3

    TLS是SSL的标准化后的产物
    有1.0 1.1 1.2三个版本
    默认使用1.0

    TLS1.0和SSL3.0几乎没有区别

    事实上我们现在用的都是TLS,但因为历史上习惯了SSL这个称呼
    平常还是以SSL为多。

    1. SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

    2. SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层: SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

    3. 安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。

    4. TLS 的最大优势就在于:TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而,TLS 标准并没有规定应用程序如何在 TLS 上增加安全性;它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

     1、SSL加密
      SSL是Netscape公司所提出的安全保密协议,在浏览器(如Internet Explorer、Netscape Navigator)和Web服务器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之间构造安全通道来进行数据传输,SSL运行在TCP/IP层之上、应用层之下,为应用程序提供加密数据通道,它采用了RC4、MD5以及RSA等加密算法,使用40 位的密钥,适用于商业信息的加密。同时,Netscape公司相应开发了HTTPS协议并内置于其浏览器中,HTTPS实际上就是HTTP over SSL,它使用默认端口443,而不是像HTTP那样使用端口80来和TCP/IP进行通信。HTTPS协议使用SSL在发送方把原始数据进行加密,然后在接受方进行解密,加密和解密需要发送方和接受方通过交换共知的密钥来实现,因此,所传送的数据不容易被网络黑客截获和解密。 然而,加密和解密过程需要耗费系统大量的开销,严重降低机器的性能,相关测试数据表明使用HTTPS协议传输数据的工作效率只有使用HTTP协议传输的十分之一。假如为了安全保密,将一个网站所有的Web应用都启用SSL技术来加密,并使用HTTPS协议进行传输,那么该网站的性能和效率将会大大降低,而且没有这个必要,因为一般来说并不是所有数据都要求那么高的安全保密级别
      2、TLS加密
      TLS:安全传输层协议
      TLS:Transport Layer Security
      安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成: TLS 记录协议(TLS Record)和 TLS 握手协议(TLS Handshake)。较低的层为 TLS 记录协议,位于某个可靠的传输协议(例如 TCP)上面。

     

    SSL与TLS的区别以及介绍

    SSL:(Secure Socket Layer,安全套接字层),位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性,以实现客户端和服务器之间的安全通讯。该协议由两层组成:SSL记录协议和SSL握手协议。

    TLS:(Transport Layer Security,传输层安全协议),用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成:TLS记录协议和TLS握手协议。

      SSL是Netscape开发的专门用于保护Web通讯的,目前版本为3.0.最新版本的TLS 1.0是IETE(工程任务组)指定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。两者差别极小,可以理解为SSL 3.1,它是写入了RFC的。

      SSL(Secure Socket Layer)

      为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取。

      当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。

      SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层:SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

      SSL协议提供的服务主要有:

      1)认证用户和服务器,确保数据发送到正确的客户机和服务器;

      2)加密数据以防止数据中途被窃取;

      3)维护数据的完整性,确保数据在传输过程中不被改变。

      SSL协议的工作流程:

      服务器认证阶段:

      1)客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接;

      2)服务器根据客户的信息确定是否需要生成新的主密钥,如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息;

      3)客服根据收到的服务器响应信息,产生一个主密钥,并用服务器的公开密钥加密后传给服务器;

      4)服务器恢复该主密钥,并返回给客户一个用主密钥认证的信息,以此让客户认证服务器。

      用户认证阶段:在此之前,服务器已经通过了客户认证,这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户,客户则返回(数字)签名后的提问和其公开密钥,从而向服务器提供认证。

      TLS(Transport Layer Security Protocol):安全传输层协议

      安全传输层协议(TLS)用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两成组成:TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)。较低的层为TLS记录协议,位于某个可靠的传输协议(例如TCP)上面。

      TLS记录协议提供的连接安全性具有两个基本特性:

    • 私有——对称加密用以数据加密(DES、RC4等)。对称加密所产生的密钥对每个连接都是唯一的,且此密钥基于另一个协议(如握手协议)协商。记录协议也可以不加密使用。
    • 可靠——信息传输包括使用密钥的MAC进行信息完整性检查。安全哈希功能(SHA、MD5等)用于MAC计算。记录协议在没有MAC的情况下也能操作,但一般只能用于这种模式,即有另一个协议正在使用记录协议传输协商安全参数。

      TLS记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间互相认证,协商加密算法和加密密钥。TLS握手协议提供的连接安全具有三个基本属性:

    • 可以使用非对称的,或公共密钥的密码术来认证对等方的身份。该认证是可选的,但至少需要一个结点方。
    • 共享解密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密,即使是进入连接中间的攻击者也不能。
    • 协商是可靠的。没有经过通信方成员的检测,任何攻击者都不能修改通信协商。

      TLS的最大优势就在于:TLS是独立于应用协议。高层协议可以透明地分布在TLS协议上面。然而,TLS标准并没有规定应用程序如何在TLS上增加安全性;它如何启动TLS握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。

      协议结构

      TLS协议包括两个协议组——TLS记录协议和TLS握手协议。

      TLS和SSL的关系:并列关系

      最新版本的TLS(Transport Layer Security,传输层安全协议)是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。在TLS与SSL 3.0之间存在着显著的差别,主要是它们所支持的加密算法不同,所以TLS与SSL 3.0不能互操作。

      1.TLS与SSL的差异

      1)版本号:TLS记录格式与SSL记录格式相同,但版本号的值不同,TLS的版本1.0使用的版本号为SSLv3.1。

      2)报文鉴别码:SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法,两者差别在于SSLv3.0中,填充字节与密钥之间采用的是连接运算,而HMAC算法采用的异或运算。但是两者的安全程度是相同的。

      3)伪随机函数:TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块,是更安全的方式。

      4)报警代码:TLS支持几乎所有的SSLv3.0报警代码,而且TLS还补充定义了很多报警代码,如解密失败(decryption_failed)、记录溢出(record_overflow)、未知CA(unknown_ca)、拒绝访问(access_denied)等。

      5)密文族和客户证书:SSLv3.0和TLS存在少量差别,即TLS不支持Fortezza密钥交换、加密算法和客户证书。

      6)certificate_verify和finished消息:SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时,计算的输入有少许差别,但安全性相当。

      7)加密计算:TLS和SSLv3.0在计算主密值(master secret)时采用的方式不同。

      8)填充:用户数据加密之前需要增加的填充字节。在SSL中,填充后的数据长度哟啊达到密文快长度的最小整数倍。而在TLS中,填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节),这种方式可以防止基于对报文长度进行分析的攻击。

     

      2.TLS的主要增强内容

      TLS的主要目标是使SSL更安全,并使协议的规范更精确和完善。TLS在SSL v3.0的基础上,提供了以下增加内容:

      1)更安全的MAC算法

      2)更严密的警报

      3)“灰色区域”规范的更明确的定义

     

      3.TLS对于安全性的改进

      1)对于消息认证使用密钥散列法:TLS使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用(消息认证代码)MAC功能更安全。

      2)增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。

      3)改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。

      4)一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。

      5)特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

     

    [更多详细地介绍]

    1、聊聊HTTPS和SSL/TLS协议 | 程序师 - 程序员、编程语言、软件开发、编程技术 http://www.techug.com/post/https-ssl-tls.html

    2、详解SSL/TLS http://www.mamicode.com/info-detail-1846390.html (推荐阅读)

    展开全文
  • 图解SSL/TLS协议

    万次阅读 2014-11-11 17:03:07
    转载http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

    转载http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

    本周,CloudFlare宣布,开始提供Keyless服务,即你把网站放到它们的CDN上,不用提供自己的私钥,也能使用SSL加密链接。

    我看了CloudFlare的说明(这里这里),突然意识到这是绝好的例子,可以用来说明SSL/TLS协议的运行机制。它配有插图,很容易看懂。

    下面,我就用这些图片作为例子,配合我半年前写的《SSL/TLS协议运行机制的概述》,来解释SSL协议。

    一、SSL协议的握手过程

    开始加密通信之前,客户端和服务器首先必须建立连接和交换参数,这个过程叫做握手(handshake)。

    假定客户端叫做爱丽丝,服务器叫做鲍勃,整个握手过程可以用下图说明(点击看大图)。

    握手阶段分成五步。

    第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。

    第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。

    第三步,爱丽丝确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给鲍勃。

    第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。

    第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。

    上面的五步,画成一张图,就是下面这样。

    二、私钥的作用

    握手阶段有三点需要注意。

    (1)生成对话密钥一共需要三个随机数。

    (2)握手之后的对话使用"对话密钥"加密(对称加密),服务器的公钥和私钥只用于加密和解密"对话密钥"(非对称加密),无其他作用。

    (3)服务器公钥放在服务器的数字证书之中。

    从上面第二点可知,整个对话过程中(握手阶段和其后的对话),服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。

    某些客户(比如银行)想要使用外部CDN,加快自家网站的访问速度,但是出于安全考虑,不能把私钥交给CDN服务商。这时,完全可以把私钥留在自家服务器,只用来解密对话密钥,其他步骤都让CDN服务商去完成。

    上图中,银行的服务器只参与第四步,后面的对话都不再会用到私钥了。

    三、DH算法的握手阶段

    整个握手阶段都不加密(也没法加密),都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。

    虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,我们可以考虑把握手阶段的算法从默认的RSA算法,改为Diffie-Hellman算法(简称DH算法)。DH算法的详细介绍->http://blog.csdn.net/fw0124/article/details/8462373

    采用DH算法后,Premaster secret不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

    上图中,第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数,然后双方各自算出Premaster secret。这样就提高了安全性。

    四、session的恢复

    握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。

    这时有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket。

    session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。

    上图中,客户端给出session ID,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信。

    session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。

    上图中,客户端不再发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

    (完)

    展开全文
  • TLS 1.0 RFC http://www.ietf.org/rfc/rfc2246.txt TLS 1.1 RFC http://www.ietf.org/rfc/rfc4346.txt TLS 1.2 RFC http://www.ietf.org/rfc/rfc5246.txt   TLS 1.3 见:...

    TLS 1.0 RFC http://www.ietf.org/rfc/rfc2246.txt

    TLS 1.1 RFC http://www.ietf.org/rfc/rfc4346.txt

    TLS 1.2 RFC http://www.ietf.org/rfc/rfc5246.txt

     

    TLS 1.3 见:https://blog.csdn.net/mrpre/article/details/81532469

    我的TLS实现,大家可以参考:https://github.com/mrpre/atls/


    这里根据TLS的实现,进行总结。至于各个版本号之间丢弃了哪些算法、新增了哪些算法,直接看RFC即可,这里并不关心。

    这里只关心TLS报文内在处理逻辑存在哪些变化,即站在代码的角度剖析。各位看官如果对TLS协议不熟悉,那么不建议看此文章。要读懂此文章需要对TLS实现由较深的理解,想了解TLS基础知识,建议从本系列开头看起。


    区别1:对finished报文(Encrypted handshake message)影响
    TLS 1.0 TLS 1.1 在计算finish时,进行的是MD5+ SHA1组合方式运算,而在TLS 1.2下,摘要算法变成了单次SHA256。

     

     

    伪代码如下

    If(version >= TLS1_2)
    {
    
    
         If (cipher.mac == SHA384)
         {
    
    
                restult = SHA384(handshake_in );
         }
         Else
         {
                restult  =  SHA256(handshake_in);
         }
    }
    Else
    {
        restult  =  md5(handshake_in) + sha1(handshake_in);
    }

    其中 handshake_in是 字符串常量+所有握手信息(类型为Handshake的message)。

    例如

    作为client端handshake_in =“client finidhed” + all_handshake
    作为Server 端handshake_in = “server finidhed” + all_handshake


    注:对于加密套件存在SHA384及其以上的高级摘要算法,无论TLS哪个版本,都用 加密套件指定的 握手摘要算法计算 摘要,如上伪代码所示(RFC上说对于每一种新的算法, 都需要指定default还是SHAXXX,但是在实现上,都是根据MAC是什么,SHAXXX就是什么)。

    其实加密套件中指定的摘要算法是用来在加密时进行HMAC的,并不影响握手流程中的运算,但是如果两端协商的加密套件支持SHAXXX,那么必然表示两端支持SHAXXX算法,那么在SHAXXX安全性高于SHA256的情况下,握手阶段需要摘要算法就没必要那么‘死’只用SHA256。当然目前也没有比SHA384更高的了。

     



    区别2:对PRF算法的影响
     

    先用伪代码梳理逻辑:

    If(version >= TLS1_2)
    {
        If (cipher.mac == SHA384)
        {
            TLS1_2_PRF(SHA384, in, srcret);
        }
        Else
        {
            TLS1_2_PRF(SHA256, in, srcret);
        }
    }
    Else
    {
        TLS1_PRF(MD5,SHA1, in, srcret);
    }

     

    1:对于SHA384的判断,上面已经说过,这里不再赘述。
    2:可以看到TLS1.2和TLS 1.0 TLS 1.1的PRF实现也不同,参数不同。

    TLS 1.2 的PRF
    单次P_HASH,P_HASH使用的是SHA256

    TLS 1.1 的PRF
    两次P_HASH,第一次P_HASH使用的是MD5,以及secret的前半部分;第二次P_HASH使用的SHA1,以及secret的后半部分。两次P_HASH的结果进行亦或(xor),得到最后结果。

    注意secret如果是偶数,则正好各一半,如果是奇数:

     

    例如secret是1234567,则前一半 指的是1234,后一半指的是4567,中间一个字节公用。

     

    区别3:对Certificate verify的影响

    Certificate vertify是客户端在发送证书后,为了表明自己是证书的拥有者,用自己的私钥对之前收到、发送的握手信息进行签名。(和finished类似)。

    同样签名前,需要对握手信息进行HASH运算。

     

    TLS1.0 TLS1.1:

    使用MD5+SHA1的形式对握手信息进行摘要运算,这个流程和计算finished一样,只是不加字符串常量’XXX finished’。

    注:有一个例外,对于ECDSA签名算法(客户端证书是ECC证书),只做单次SHA1计算。

    TLS 1.2:

    TLS 1.2 下, certificate verify报文格式和之前的不同,多出2个字节(Signature Hash Algorithm),表示hash_alg以及sign_alg。具体握手摘要根据hash_alg进行单次计算。

    同样,如果加密套件存在SHA384,则使用SHA384

    TLS 1.2下 Certificate verify的格式

     

    伪代码如下:

    If(version >= TLS1_2)
    {
        result = SHAXXX(all_handshake);
        ADD_MD_INFO_TO_PACKET();//报文中增加两个字节表明自己签名算法
    }
    Else
    {
        If(ECDSA_SIGN)
        {
              result = SHA1(all_handshake);
        }
        Else
        {
            result = MD5(all_handshake) + SHA1(all_handshake) 
        }
    }

     

    总结来说:

     

    1:TLS 1.2需要增加2个字节表明签名算法类型(非对称+摘要)。而TLS1.2之前的协议默认就用md5+sha1的形式计算摘要,非对称算法肯定使用私钥类型对应的算法,这个无需显示表明。

    2:ECDSA签名需要特殊对待。

     

     

    区别4:对server key exchange的影响

    TLS1.2下和 certificate verify类似,报文格式较之前版本有不同。多了2个字节表示HASH算法和签名算法。

     

     

    签名时的摘要逻辑和certificate verify一样。

     

    区别5:对加密的影响

        这个变化是TLS1.1开始变化的,不是TLS1.2。

        为了对抗beast攻击,SSL在加密数据前,需要填充一个BLOCK_SIZE(IV_SIZE)长度的随机数,这个随机值也被作为数据的一部分进行加密,在解密时,同样进行解密,然后丢弃。

         CBC下,对于上述这个场景我们其实可以进行优化,这个BLOCK_SIZE的数据对于发送端来说可以不进行加密,然后下一个数据块的Write_IV改成这个随机数,这样CBC模式就可以完整的工作。对于解密方来说,这个BLOCK_SIZE的数据可以不解密,然后解密下一个块时的Read_IV变成这个随机数,CBC模式也能正常工作。减少了一个BLOCK_SIZE的解密、加密数据。详细优化方案见我的博客 http://blog.csdn.net/mrpre/article/details/78093370

     

    如果觉得对你有用, 请打赏1元哦:http://www.mrpre.com/

     

     

    展开全文
  • TLS 1.3 协议详解

    万次阅读 热门讨论 2020-06-26 12:46:27
    TLS 1.3 握手流程详解 需要的背景知识: (1):对 TLS 1.2 协议有一定程度的了解,包括秘钥交换、会话复用等。 第一节 TLS 1.3 的握手概述 协议分析的第一步就是看报文。TLS 1.3的报文,有个特点,就是通过抓...
  • 一声惊雷,今天爆出了一个关于SSL协议的惊天大漏洞,在用完各种poc工具后,我们不妨来深入了解下这个高危漏洞的机理。 不管你是用网上公布的检测网站还是各个QQ群疯传的poc 脚本...点评ssl服务没有开启TLS heartbeat...
  • TLS重新协商显示扩展,RFC5746

    千次阅读 2017-08-29 14:20:01
    TLS [RFC5246]允许客户端或服务器启动重新协商 - 建立新的加密参数的新握手。 不幸的是,虽然使用由原始握手建立的加密参数来执行新的握手,但是两者之间没有加密绑定。 这将为攻击者创造机会,攻击者可以拦截客户端...
  • 常见主机漏洞及修复方案

    万次阅读 2018-09-28 16:29:34
    1、openssh累积型漏洞 高 cve-2017-10012 修复意见: 升级版本至>=openssh-5.3p1-122.el6   2、NTP累积型漏洞 高 ...稳定版请尽快安装ntp-4.2.8p4及以后版本  ...开发版请尽快安装ntp-4.3.77及以后版本 ...
  • TLS & DTLS心跳扩展(rfc6250)

    千次阅读 2015-01-26 18:54:11
    最近半年中openssl的心脏滴血漏洞造成的影响真是太大了,openssl在实现rfc6052文档中定义的心跳扩展协议的时候出现了低级错误。对于这个错误的动机是什么真是无从说起。最近自己的项目中用到了这一部分的内容,那么...
  • 详解 HTTPS、TLS、SSL、HTTP区别和关系

    万次阅读 2018-10-03 16:02:34
    TLS的前身是SSL,TLS 1.0通常被标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。下图描述了在TCP/IP协议栈中TLS(各子协议)和HTTP的关系。 二、HTTP和HTTPS协议的区别 1、HTTPS协议需要到证书颁发机构...
  • TLS 详解

    千次阅读 2019-03-20 09:40:53
    1. TLS 定义 SSL(Secure Sockets Layer) 安全套接层,是一种安全协议,经历了 SSL 1.0、2.0、3.0 版本后发展成了标准安全协议 - TLS(Transport Layer Security) 传输层安全性协议。TLS 有 1.0 (RFC 2246)...
  • TLS 与HTTPS

    万次阅读 2018-03-29 14:25:40
    1 概述TLS 是进行 HTTPS 连接的重要环节,通过了 TLS 层进行协商,后续的 HTTP 请求就可以使用协商好的对称密钥进行加密SSL 是 Netscape 开发...所以 TLS 1.0 可以认为是 SSL 3.1TLS(Transport Layer Security Prot...
  • TLS安全设置

    万次阅读 2018-05-25 16:54:49
    解决方案:控制面板-Internet 选项-高级中,建议您查看一下TLS项目的勾选情况。使用TLS相关的项目建议可以尝试勾选一下,应用后看下访问效果
  • 随着sha-1的废止,需要更强的防护手段作为常规手段,原来的设置已经被很多的网站抛弃...3.在internet选项界面的“高级”选卡“设置”框中勾选“使用TLS1.0”、“使用TLS1.1”、“使用TLS1.3”,点击应用并确定即可。
  • TLS 版本查询

    万次阅读 2018-01-24 16:11:46
    openssl命令 openssl s_client -connect intl.jdair.net:443 -tls1(-tls1_1 -tls1_2)  网页查询的话 https://www.ssllabs.com/ssltest/analyze.html
  • TLS Error: TLS handshake failed解决办法

    万次阅读 2019-05-03 00:48:38
    直接修改端口号 服务器端和客服端都要改哟 本文转自 luoguo 51CTO博客,原文链接:http://blog.51cto.com/luoguoling/1080298 ...
  • 声明:本文只作学习研究,禁止用于非法用途,否则后果自负,如有侵权,请告知删除,谢谢! 项目场景: 想必做过爬虫的工程师,都接触过中国土地市场网这个网站吧,网上也有很多相关的爬取方式介绍,我看了几篇...
  • 服务器 TLS1.0 1TLS.2 配置详细教学!

    万次阅读 热门讨论 2018-09-14 14:37:52
    今天写4种方法 配置TLS 不啰嗦 直接干货! 首先我们要确定系统是否支持TLS1.2 ,参考如下配置图↓↓↓↓↓↓↓↓↓↓↓↓↓↓ 如果你的系统支持 继续往下看!!!!! 第一个方法 操作注册表 1.找到HKEY_LOCAL...
  • 查看服务器的tls是否为1.2

    千次阅读 2019-04-02 10:20:05
    https://www.ssllabs.com/ssltest/analyze.html
  • 1.mbedtls_ssl_conf_authmode( &conf, MBEDTLS_SSL_VERIFY_REQUIRED );第二个参数不要用MBEDTLS_SSL_VERIFY_OPTIONAL,不然验证通不过的时候也能用,意义不大 2.mbedtls_ssl_set_hostname( &ssl, "MQTT" )第二个
1 2 3 4 5 ... 20
收藏数 140,400
精华内容 56,160
关键字:

tls