传输层安全性(Transport Layer Security,TLS)-译

原文: 高性能网络浏览器-第四章传输层安全性(Transport Layer Security,TLS)
翻译: outshineamaze

介绍:

SSL协议在网景公司最初开发支持电子商务网络交易安全,须要加密 http 请求 来保护客户的我的资料,以及身份验证和完整性保证,以确保一个安全的交易。为了达到这个目标,SSL协议在应用程序层实现,直接上TCP(图4 - 1上面),使协议(HTTP、电子邮件、即时消息和许多其余人)在使用上不作改变,同时提供安全通讯时的通讯网络。

正确使用SSL时,第三方观察者只能推断出链接端点类型的加密,以及频率和一个近似发送的数据量,但不能读取或修改任何实际的数据。

图4 - 1。传输层安全性(Transport Layer Security,TLS)

SSL协议由IETF标准化时,它被命名为传输层安全性(TLS)。许多地方不太区分SSL和TLS名称,但从技术上讲,它们是不一样的,由于每一个描述了不一样版本的协议。

SSL协议的2.0是第一个公开发布的版本,因为发现安全漏洞,但它很快就被SSL 3.0取代了. 由于SSL协议是网景私有的,努力造成的IETF标准化协议,最终定稿为RFC 2246,这是1999年1月出版,被称为TLS 1.0。此后,IETF继续迭代协议来解决安全漏洞,以及扩大其功能:TLS 1.1(RFC 2246)发表在2006年4月,TLS 1.2(RFC 5246)2008年8月,如今正在开发中的版本,将定义为TLS 1.3。

不要让大量的版本号误导你:

服务器会更加倾向于选择最新稳定版本TLS协议,以确保最好的安全,功能和性能保证。事实上,一些性能关键型特性,好比HTTP / 2,明确须要使用TLS 1.2或更高版本,不然将终止链接。良好的安全性和性能齐头并进。

notice

TLS是被设计用于支持的可靠传输的协议(如TCP。然而,它也被适应碾如UDP数据报协议。数据报传输层安全(迪泰)),在RFC 6347中定义的是: 基于TLS协议可以提供相似的安全保障,同时保留数据报传递模型。

加密、身份验证、完整性 (Encryption, Authentication, Integrity)

TLS协议旨在提供三个基本服务上面运行的应用程序:加密、认证和数据完整性。从技术上讲,你不须要在全部的状况中所有使用上面三个特性。你能够决定接受证书没有验证其真实性,可是你应该清楚这样作的安全风险和影响。在实践中,一个安全的web应用程序将利用全部三个服务。

加密
主机发送数据到到另外一个终端的一种混淆机制。

身份验证
提供一种机制来验证的有效性身份资料。

完整性
一种机制来检测消息篡改和伪造。

为了创建一个密码安全的数据通道,peers 之间的链接必须赞成使用密码套件和密钥用于加密数据。TLS协议定义了一个明确的握手顺序来执行这个交换,咱们将详细检查TLS握手。TLS 设计巧妙而且可靠缘由,是因为其使用公钥加密(也称为非对称密钥加密),它容许同伴协商共享密钥,而无需创建彼此的任何先验知识,并经过未加密的通道。

TLS协议容许两个 peer 在握手的过程当中验证对方的身份。当在浏览器中使用TSL 协议时,这种验证机制容许客户端验证服务器是谁(如。,你的银行),而不是一个虚假的名称或IP地址。这个验证是基于信任的创建的——看到的链的信任和证书颁发机构。此外,服务器还能够选择验证客户端的身份——如。公司代理服务器能够验证全部员工,每一个人均可以有公司为本身签署惟一的的证书。

最后,包含加密和认证的地方,TLS协议还提供本身的消息框架机制和信号每一个消息与消息身份验证代码(MAC)。MAC算法是单向加密哈希函数(有效校验和),谈判的两个链接的关键。每当TLS发送记录,MAC值是生成和附加信息,而后接收者是可以计算和验证发送MAC值,以确保消息的完整性和真实性。

全部三个机制结合在一块儿,做为网络安全通讯的基础。全部现代web浏览器提供支持多种密码套件,能够对客户端和服务器进行身份验证,并透明地为每个记录执行消息完整性检查。

代理,中介机构,TLS,web 上的新协议

HTTP的可扩展性和成功创造了一个充满活力的网上代理和中介机构:缓存服务器,安全网关,网络加速器,内容过滤器,和许多其它生态系统。在某些显式的代理,咱们能够意识到它们的存在,最终对于用户是彻底透明的。
在实践中, 在80端口上经常会部署不可靠的服务,这些服务偏离的定义良好的HTTP / 1语义, 一些客户没有问题,一些客户的不可预知。相同的客户端在不一样的网络环境中可能会看到不一样的结果,

因为这些行为,新协议和HTTP扩展,好比WebSocket,HTTP / 2等,必须依靠创建一个HTTPS隧道绕过中间代理, 加密隧道能够很好的保护数据经过中间机构。若是你曾经想知道为何大多数WebSocket指南会告诉你使用HTTPS来传送数据到移动客户端,这就是为何。

HTTPS无处不在

未加密的HTTP和其余protocols-creates通讯提供大量的隐私、安全性和完整性的漏洞。这样的链接很容易被拦截、操纵和模拟,并能暴露用户凭证,历史,身份,和其余敏感信息。HTTPS能够很好的为用户的隐私提供保护 。

HTTPS保护网站的完整性

加密能够防止入侵者篡改data-e.g交换。重写内容、注入 广告的和恶意的内容等等。

HTTPS保护用户的隐私和安全

加密能够防止入侵者监听传输的数据。每一个未受保护的请求能够暴露用户的敏感信息,当这些数据包含不少的 session 信息,能够用来推测用户的身份和其余敏感信息。

HTTPS支持强大的功能

愈来愈多的新的网络平台特性,如访问用户地理位置,拍照,录音录像,支持离线应用经验,,须要显式的用户选择,反过来,须要HTTPS。HTTPS提供的安全性和完整性保证相当重要的一部分在一个安全的用户权限工做环境中
进一步指出,因特网工程任务组(IETF)和互联网架构委员会(IAB)发布了指导开发人员和强烈鼓励采用HTTPS协议设计师:

IETF:无处不在的监控是攻击

内勤局:互联网保密声明

当咱们依赖互联网的发展,因此对每一个依赖它的人来讲都有风险,它是咱们的责任,做为应用程序开发人员和用户,以确保咱们保护本身经过启用HTTPS无处不在。

Let’s Encrypt

对普遍采用HTTPS常见的疑问和障碍的要求是 从一个可信证书颁发机构购买证书。

“Let’s Encrypt是一个免费的、自动化的、开放的证书颁发机构为您的网络安全研究小组(ISRG)。让咱们加密和ACME协议的目的是可以创建一个HTTPS服务器并让它自动得到browser-trusted证书,没有任何人工干预。”

访问项目网站学习如何设置它在你本身的站点上。没有限制,如今任何人均可以得到一个受信任的证书的网站,免费的。

TLS握手

以前,客户机和服务器能够交换应用程序数据/ TLS加密隧道必须协商:客户端和服务器必须赞成TLS协议的版本,若是有必要选择密码套件,并验证证书。不幸的是,每个步骤须要新的数据包往返(图4 - 2客户机和服务器之间的),这增长了启动延迟全部TLS链接。

图4 - 2。TLS握手协议
图4 - 2假设相同(乐观的状况)28日毫秒的“光纤”延迟纽约和伦敦之间的使用在之前的TCP链接创建的例子,看看表1 - 1.

0 ms
TLS运行在一个可靠的运输(TCP),这意味着咱们必须首先完成TCP三方握手,这须要一个完整的往返。

56 ms
与TCP链接,客户端发送一个纯文本的规范,如TLS协议的版本运行,支持的密码套件列表和其余可能想使用TLS选项。

84 ms
服务器选择TLS协议版本进行进一步的沟通,决定从列表所提供的客户端密码套件,高度的证书,并将响应发送回客户端。可选地,服务器也能够发送一个请求客户机的证书和其余参数TLS扩展。

112 ms
假设双方能够协商一个共同的版本和密码,和客户满意提供的证书服务器,客户端发起RSA或diffie - hellman密钥交换,这是创建对称密钥用于随后的会话。

140 ms
服务器处理客户端发送的密钥交换参数,检查消息完整性经过验证MAC,并返回一个加密 Finished消息发送回客户端。

168 ms
客户端与谈判对称密钥解密消息,验证MAC,若是一切顺利,那么创建了隧道和应用程序数据如今能够发送。

如上述所示,新的TLS链接须要两个往返的“握手”。然而,在实践中,优化部署能够作得更好并提供一个一致的1-RTT TLS握手:

False Start 是TLS协议的扩展,它容许客户端和服务器上开始传输加密应用程序数据只是部分complete-i.e握手时。,一旦 ChangeCipherSpec和 Finished消息被发送,但没有等待另外一侧作一样的事情。这种优化下降了新TLS握手开销链接一个往返,明白了支持TLS FALSE Start.

若是客户曾与服务器通讯,可使用一个“缩写握手”,这就须要一个往返,还容许客户端和服务器CPU开销下降安全会话重用先前商定的参数;看到TLS会话恢复.

上述优化的组合使咱们可以为首次访问的和非首次访问的访客提供一个 1-RTT TLS握手,加上计算储存先前的会话,能够恢复协商会话参数。确保在部署中利用这些优化点。

TLS 1.3的设计目标之一是减小创建安全链接的延迟开销:新会话1-RTT,和恢复会话0-RTT!

RSA、diffie - hellman和保密

因为各类历史和商业缘由RSA握手一直大多数TLS实现中占主导地位的密钥交换机制:客户端生成一个对称密钥,与服务器的公钥进行加密,并将它发送到服务器使用的对称密钥创建会话。反过来,服务器使用本身的私钥解密对称密钥和密钥交换完成发送。从这个角度提出了客户端和服务器使用对称密钥来加密会话协商。

RSA的握手,但有一个重要缺点:使用相同的公私密钥对服务器进行身份验证和加密对称会话密钥发送到服务器。结果,若是一个攻击者能够访问服务器的私钥和并监听数据传输,他们能够就解密整个会话。更糟糕的是,即便攻击者目前没有访问私钥,他们仍然能够记录加密的会话,以后一旦在得到私钥就能够解密它。

相比之下,diffie - hellman密钥交换容许客户端和服务器协商共享密钥没有明确沟通的握手:服务器的私钥用于签名和验证的握手,但对称密钥从未离开过客户机或服务器,攻击者没法拦截即便他们得到私钥。

维基百科文章diffie - hellman密钥交换

最重要的是,diffie - hellman密钥交换能够用来减小传递 session 的风险:咱们能够为每一个对话生成一个新的“短暂”对称密钥,每个密钥交换后丢弃以前的钥匙。由于 暂时的 key 是历来没有沟通,新的会话会致使从新协商,最坏的状况是,攻击者能够破解的客户端或服务器,拿到的当前会话密钥和将来的会话密钥。然而,知道如今的私钥,不能帮助攻击者解密任何先前的会话!

结合,使用diffie - hellman密钥交换和临时会话密钥使“完美向前保密”(PFS):长期密钥的妥协(如服务器的私钥)和过时的会话密钥 不容许攻击者解密之前记录的会话。一个高度可取的属性,至少能够这样说!

结果,这个不该该感到惊讶,RSA握手在渐渐的被淘汰:全部流行的浏览器选跟先进的加密算法(即依靠diffie - hellman密钥交换),做为额外的奖励,可能使某些协议优化只有当保密是available-e.g向前发展。经过TLS的 False Start 实现1-RTT握手。

公共与对称密钥加密的性能

使用公开密匙加密只在初始设置的TLS隧道:证书认证和密钥交换算法执行。

对称密钥加密,使用对称密钥是用于创建客户机和服务器之间的全部进一步沟通在会话。这样作,在很大程度上,提升performance-public密钥加密计算昂贵得多。为了说明不一样,若是你有OpenSSL安装在您的计算机上,您能够运行下面的测试:

$> openssl speed ecdh

$> openssl speed aes

注意,两次测试之间的单位不具备直接可比性:椭圆曲线diffie - hellman(ECDH)测试提供了一个汇总表的操做每秒对于不一样大小的关键,同时AES性能以字节每秒。尽管如此,它应该很容易看到ECDH操做计算昂贵得多。

使用的具体性能数据创建在不一样硬件、核心数量,TLS版本,服务器配置,和其余因素。不要爱上一个过期的基准!老是在本身的硬件上运行性能测试和参考下降计算成本额外的上下文。

应用程序层协议谈判(ALPN)

两个peer 可能想要使用一个自定义协议相互通讯。解决这个问题的一个方法是肯定协议的前期,分配一个使用比较普遍的端口(如。HTTP 80端口, TLS端口443), 而后配置全部客户端和服务器使用它。然而,在实践中,这是一个缓慢而不切实际的过程:每一个端口分配必须批准,更糟糕的是,防火墙和其余中介机构经常容许流量只在端口80和443。

为了使自定义协议容易部署,咱们必须复用端口80或443,使用一个额外的机制应用协议进行协商。端口80是用于HTTP,HTTP规范提供了一个特殊的 Upgrade流这一目的。然而,使用 Upgrade能够添加一个额外的网络往返延迟,在实践中每每是不可靠的许多中介机构, 代理,中介机构,TLS,新协议在网络上.

notice

HTTP操做示例的升级流程,提早翻转升级到HTTP / 2.

解决方法是使用端口443,它是用于安全的HTTPS会话运行/ TLS。使用端到端加密通道, 一种快速而可靠的方法来部署新应用程序协议。然而,咱们还须要另外一种机制谈判中的协议,它将使用于TLS会话。

应用程序层协议谈判(ALPN)

顾名思义,是一个TLS扩展。它扩展了TLS握手(图4 - 2),并容许在同行谈判协议没有额外的循环。具体来讲,过程以下:

客户端添加一个新的 ProtocolNameList领域,包含支持的应用程序协议列表,进入 ClientHello消息。

服务器检查 ProtocolNameList场,并返回一个 ProtocolName字段显示选中的协议的一部分 ServerHello消息。

服务器可能只有一个响应协议名称,若是它不支持任何客户机请求,那么能够选择终止链接。所以,一旦TLS握手完成后,创建安全的隧道,和客户端和服务器协议将使用哪些应用协议;客户端和服务器能够当即开始经过协商协议交换消息。

历史和NPN型和ALPN的关系

(NPN)是一个TLS扩展,谷歌开发它做为SPDY功能的一部分,使应用程序在TLS握手高效地协议谈判。听起来是否是很熟悉?最终的结果是功能上至关于ALPN。

ALPN修订和IETF批准版的NPN型扩展。广告在NPN型中,服务器所支持的协议,而后客户端选择和确认协议。在ALPN,这种交换是逆转:如今客户端指定它所支持的协议,而后,服务器选择并确认协议。变化的基本原理是,这让ALPN更为契合其余协议谈判的标准。

简而言之,ALPN是NPN型的一个接班人。

服务器名称指示(SNI)

能够创建一个加密的TLS隧道之间的任何两个TCP同行:客户端只须要知道其余同行的IP地址进行链接和执行TLS握手。然而,若是服务器但愿托管多个独立站点,每一个都有本身的TLS证书,在相同的IP地址——这是如何工做的呢?技巧问题;它不。

解决前面的问题,服务器名称指示(SNI)扩展了TLS协议,它容许客户端显示客户机试图链接到主机名的TLS握手。反过来,服务器能够检查SNI主机发送的 ClientHello信息,选择合适的证书,并完成所需主机的TLS握手。

TLS、HTTP和专用IPs

TLS + SNI工做流是相同的 Host在HTTP头声明,客户端显示站点的主机名要求:一个IP地址可能会 host 过个域名,SNI和 Host他们之间须要消除歧义。

不幸的是,一些老客户(如。,大多数IE版本上运行Windows XP,Android 2.2,和其余人)不支持SNI。所以,若是您须要提供TLS这样的客户,那么你可能须要一个专用的IP地址为每个主机。

TLS会话恢复

额外的延迟和成本计算完整的TLS握手一个严重的性能损失强加给全部的应用程序都须要安全通讯。为了下降延时上的成本,TLS提供一个机制来共享多个链接之间相同的协商密钥数据。

会话标识符

第一个会话标识符(RFC 5246)恢复机制是在SSL 2.0中引入的,它容许服务器建立和发送32字节的会话标识符的一部分 在TLS协商以前发送ServerHello消息。与会话ID,客户机和服务器能够存储以前协商会话parameters-keyed会话ID和后续会话重用它们。

具体来讲,客户端能够包括的会话ID ClientHello消息告诉服务器它还记得密码套件和密钥协商从先前的握手和可以重用它们。反过来,若是服务器可以找到会话参数与广告相关的缓存ID,而后缩写握手(图4 - 3)能够发生。不然,就须要一个完整的新会话协商过程了,这将生成一个新的会话ID。

图4 - 3。缩写TLS握手协议

利用会话标识符容许咱们减小一个完整的往返,以及公钥密码学的开销,用于协商共享密钥。这样子在创建一个安全快速的链接同时, 也不会损失的安全性,由于咱们是重用之前协商会话数据。

对于HTTP / 1会话恢复是一个重要的优化。HTTP / 2 x的应用能够消除了一个完整的往返延迟和显著减小计算双方的成本。

事实上,若是浏览器须要多个链接相同的主机(例如当HTTP / 1.x是使用),它每每会故意等待第一个TLS协商完成以后才链接到同一台服务器上,这样他们能够“恢复”和重用相同的会话参数。若是你曾经看着网络跟踪,想知道为何你不多看到同一主机TLS多个谈判并行,这就是为何!

然而实际的限制要求服务器会话标识符机制来建立和维护一个会话缓存为每个客户。这致使服务器上的几个问题,这可能会每一天看到成千上万甚至上百万独特的链接:每打开TLS链接消耗内存,要求一个会话ID缓存和拆迁政策,对于拥有大量服务器的热门网站是一个重要挑战,在理想状况下,使用一个共享TLS会话缓存能够得到最佳性能。

前面的问题都没法解决,可是许多高流量网站现在使用会话标识符依旧很成功。但对于任何多服务器部署、会话标识符须要仔细思考和系统架构,确保会话缓存的合理性。

Session Tickets

为解决服务器端部署TLS会话缓存这个问题,“Session Ticket”(RFC 5077)替换机制被引入,服务器不须要保持每一个客户机会话状态。相反,若是客户表示它支持Session Ticket,服务器能够包含一个 New Session Ticket记录,包括全部协商会话数据, 这些会话数据用一个只有服务器知道的密匙加密。

此次会话Ticket而后会被存储在客户端,能够包含在 Session Ticket内的扩展 ClientHello消息的后续会话。所以,全部会话数据只存储在客户端,但Ticket仍然是安全的,由于它是用一个只有服务器知道的密钥加密。

会话标识符和会话票机制一般分别称为会话缓存和无状态恢复机制。无状态恢复的主要改进是服务器端会话缓存,这简化了部署,每一个新链接服务端要求客户端提供session ticket,直到ticket已通过期。

在实践中,票在一组负载均衡服务器中部署session Tickets 也须要仔细思考和系统架构:全部服务器必须使用相同的初始化会话密钥,和一个额外的安全机制须要按期和旋转全部服务器的共享密钥。

信任链和证书颁发机构

身份验证是不可分割的一部分,创建每个TLS链接。毕竟,能够进行一次谈话在一个与任何同行加密通道,包括攻击者,除非咱们能够肯定主人对咱们信任,那么全部的加密工做能够。了解咱们如何验证对等的身份,让咱们看看一个简单的验证工做流之间的爱丽丝和鲍勃:

爱丽丝和鲍勃生成本身的公钥和私钥。

爱丽丝和鲍勃隐藏各自的私钥。

爱丽丝和鲍勃,分享她的公钥和鲍勃分享了他与爱丽丝。

爱丽丝为鲍勃和迹象代表,它生成一个新消息与她的私钥。

Bob使用爱丽丝的公钥验证提供消息签名。

信任是一个关键组成部分前面的交换。具体来讲,公钥加密容许咱们使用发送方的公钥来验证消息正确的私钥签署,但决定批准发送方还是创建在信任的基础之上的。在交换显示,Alice和Bob能够交换他们的公钥亲自会面时,由于他们彼此很了解,他们确信他们的交流不被黑客impostor-perhaps他们甚至经过另外一个验证他们的身份,秘密(物理)握手他们早先创建了!

接下来,爱丽丝收到消息从查理,她历来没有见过谁,而是谁声称是鲍勃的朋友。事实上,证实他的朋友鲍勃,查理问鲍勃签署本身与鲍勃的公钥私钥,并与他的消息(这个签名图4 - 4)。在这种状况下,爱丽丝首先检查鲍勃的签名的查理的关键。她知道鲍勃的公钥,于是可以确认鲍勃确实签查理的关键。由于她相信鲍勃决定验证查理,她接受消息和对查理的消��执行相似的完整性检查,以确保它是,事实上,从查理。

图4 - 4。信任链的爱丽丝,鲍勃,和查理
咱们刚刚作的就是创建信任链:爱丽丝相信鲍勃,鲍勃信托查理,传递信任,爱丽丝决定相信查理。只要没有人链中的妥协,这让咱们构建出一个信任方的列表。

网络身份验证和在浏览器中遵循相同的过程如图所示。这意味着在这一点上你应该问:你的浏览器信任谁,你信任谁,是你本人在使用浏览器吗?至少有三种回答这个问题:

手动指定证书
全部浏览器和操做系统提供了一种机制让你手动导入任何你信任的证书。你如何得到证书并验证其完整性是彻底取决于你。

证书颁发机构
一个证书颁发机构(CA)是一个受信任的第三方信任的证书的主体(全部者)。

浏览器和操做系统
每个操做系统和大多数浏览器附带一个知名证书颁发机构列表。所以,您应该相信这个软件的供应商提供和维护的信任方列表。

在实践中,手动的去储存每一个网站证书是不切实际(尽管你能够)。所以,最多见的解决方案是使用证书颁发机构(ca)为咱们作这个工做(图4 - 5):浏览器指定ca信任(根ca), 中科院的做用就是用来验证每一个站点的sign,审计和验证这些证书不被误用或妥协。若是任何站点的安全与CA的证书被打破,那么它的责任,CA撤销妥协证书。

图4 - 5。CA签名的数字证书
每一个浏览器都容许你检查的信任链安全链接(图4 - 6),一般能够经过单击锁定图标旁边的URL。

图4 - 6。信任的证书链为igvita.com(Google Chrome,25节)
igvita.com证书签署StartCom类1主要中间服务器。

StartCom类1主要中间服务器证书签署的StartCom认证权威。

StartCom认证中心是公认的根证书颁发机构。

整个链的“信任锚”是根证书权威,这只是显示,StartCom认证权威。全部浏览器附带一个预表受信任的证书颁发机构(“根”),在这种状况下,浏览器信托和可以验证StartCom根证书。所以,经过传递信任链的浏览器,浏览器厂商和StartCom证书颁发机构,咱们扩展信任咱们的目的地网站。

证书的透明度

每个操做系统供应商和每个浏览器提供一个他们信任而且公开上市的默认证书颁发机构。能够搜索引擎来查找和调查这些列表。在实践中,你会发现大多数系统依赖数以百计的受信任的证书颁发机构,这也是一个对系统常见的抱怨:大量的受信任的ca在您的浏览器中建立一个大型攻击表面积的信任链。

好消息是,证书的透明度项目正在努力解决这些缺陷经过提供一个框架公开日志监控和审核发行的新证书。访问项目网站,了解更多信息。

证书撤销

偶尔的发行者证书须要撤销或无效证书因为许多可能的缘由:证书的私钥被入侵,证书颁发机构自己已经遭到破坏,或因为各类良性缘由取代证书等的变化关系,等等。为了解决这个问题,本身的证书包含指令(图4 - 7)如何检查是否已被撤消。所以,为了确保信任链不是妥协,每一个同行均可以检查每一个证书的状态根据嵌入式的指导,以及签名,验证证书链。

图4 - 7。CRL和OCSP指令为igvita.com(Google Chrome,25节)

证书撤销列表(CRL)

证书撤销列表(CRL)由RFC 5280定义和指定了一个简单的机制来检查每个证书的状态:每一个证书颁发机构维护和按期发布撤销证书编号的列表。任何一个试图验证证书的人就能下载撤销列表,缓存,并检查特定序列号的存在,若是它存在,那么它被撤销。

这个过程简单明了,但有不少限制:

愈来愈多的撤销签证意味着CRL列表只会变得更长,和每一个客户端必须获取序列号的完整列表。

没有即时通知证书机制revocation-if CRL证书被撤销前由客户端缓存,而后CRL认为撤销证书有效,直到缓存到期。

须要获取最新的CRL, CA可能会阻止证书验证列表,这将显著延长TLS握手时间。

CRL获取可能会失败,因为各类缘由,在这种状况下,浏览器的行为是未定义的。大多数浏览器把这种状况下定义为“软失败”,容许验证proceed-yes。

在线证书状态协议(OCSP)

解决一些CRL机制的局限性,介绍了在线证书状态协议(OCSP)由RFC 2560,这提供了一种机制来执行一个实时检查证书的状态。不像CRL文件,其中包含全部的撤销序列号,OCSP容许客户端直接查询CA的证书数据库序列号的问题,同时验证证书链。

所以,消耗更少的带宽和OCSP机制可以提供实时验证。然而,要求执行实时OCSP查询建立本身的一组问题:

CA必须可以处理负载的实时查询。

CA必须确保服务和全局可用。

实时OCSP请求可能损害客户的隐私由于CA知道哪些网站客户端访问。

客户端必须阻止OCSP请求而验证证书链。

浏览器行为,再一次,未定义,一般致使“软失败”若是OCSP获取失败因为网络超时或其余错误。

做为一个现实世界的数据点,Firefox遥测代表OCSP请求时间高达15%的时间,并添加TLS握手当successful-see大约350毫秒hpbn.co / ocsp-performance.

OCSP装订

上面列出的缘由,不管是CRL或OSCP撤销机制提供了安全性和性能保证咱们渴望咱们的应用程序。可是,不要绝望,由于OCSP装订(RFC 6066,“证书状态请求”扩展)解决了大部分的问题咱们以前看到经过容许执行验证的服务器和发送(“钉”)的TLS握手到客户端:

而不是客户OCSP请求,服务器,按期检索签署和时间戳OCSP CA的响应。

而后,服务器(即附加内容。“主食”)签署了OCSP响应做为TLS握手的一部分,容许客户端验证证书和附加OCSP撤销CA签署的记录。

这角色转换是安全的,由于ping CA签署的记录,能够由客户端验证,并提供一些重要的好处:

客户不会流失,其导航历史。

客户端没有阻止和查询OCSP服务器。

客户端可能“hard-fail”撤销处理若是服务器选择加入(经过广告OSCP Must-Staple国旗)和验证失败。

简而言之,两个最好的安全性和性能保证,确保在您的服务器上配置和测试OCSP装订。

TLS协议记录

不一样的IP或TCP层下面,TLS会话中的全部数据交换框架使用一个定义良好的协议(图4 - 8)。TLS协议记录负责识别不一样类型的消息(握手、警告或数据经过“内容类型”字段),以及保护和验证每一个消息的完整性。

图4 - 8。TLS记录结构
交付应用程序的典型工做流数据以下:

记录协议接收应用程序数据。

接收的数据分为块:最多214字节,或16 KB /记录。

消息验证码(MAC)或HMAC被添加到每一个记录。

数据在每一个记录是使用协商加密密码。

一旦完成了这些步骤,加密的数据传递到TCP层的传输。在接收端,相同的工做流程,可是反过来讲,由同行应用:解密使用密码谈判记录,核实MAC,提取和交付应用程序上面的数据。

好消息是,全部的工做就显示由TLS层自己,对于大多数应用程序是彻底透明的。然而,记录协议并介绍几个重要的意义,咱们须要注意的:

最大TLS记录大小是16 KB

每条记录包含一个5字节的头,一个MAC(SSLv3 20字节,TLS 1.0,TLS 1.1,TLS 1.2)和32字节,若是使用分组密码和填充。

解密和验证记录,整个记录必须是可用的。

为应用程序选择正确的记录大小,若是你有这样作的能力,能够是一个重要的优化。小记录招致更大的CPU和开销字节因为框架和MAC验证记录,而大的记录必须交付和重组的TCP层以前,他们能够处理的TLS层和提早送到你application-skip优化TLS记录大小所有细节。

优化TLS

部署您的应用程序在TLS须要一些额外的工做,在您的应用程序(如资源迁移到HTTPS以免混合内容),以及基础设施的配置负责交付应用程序数据在TLS。调整部署可使一个巨大的不一样凡响的观测性能,用户体验,和总体运营成本。就让咱们一探究竟吧。

下降计算成本

创建和维护一个加密的通道同行介绍了附加的计算成本。具体来讲,首先是不对称的(公钥)加密中使用TLS握手(解释道TLS握手)。而后,一旦创建共享密钥,它被用做一个对称密钥加密全部TLS记录。

正如咱们前面提到的,公钥密码术更计算昂贵的相比,对称密钥加密,并在早期的Web一般须要额外的硬件来执行“SSL卸载。“好消息是,这再也不是必要的,一旦须要专用硬件在CPU上直接就能够完成。大型组织如Facebook、Twitter和谷歌提供TLS数十亿的用户,在计算软件和硬件执行全部必要的TLS协商。

2010年1月,Gmail将默认为全部使用HTTPS。以前它被引入做为一个选项,但如今咱们全部的用户使用HTTPS来保护他们的浏览器和谷歌之间他们的电子邮件,全部的时间。为了作到这一点咱们尚未部署额外的机器,没有特殊硬件。在咱们的前端生产环境服务器机,SSL / TLS占不到1%的CPU负载、每一个链接不到10 KB的内存和不到2%的网络开销。许多人认为,SSL / TLS须要大量的CPU时间,咱们但愿前面的数字(公共)能够帮助你们打消那个误解。

若是你如今中止阅读你只须要记住一件事:SSL / TLS再也不计算昂贵了。

亚当·兰利(谷歌)
咱们在大规模部署TLS使用硬件和软件负载平衡器。咱们发现,现代的基于软件的TLS实现产品, 高速cpu来处理大量HTTPS流量负载,而不须要采起专门的加密硬件。咱们的服务全部的HTTPS都使用软件来运行.

Doug海狸(Facebook)
椭圆曲线diffie - hellman(ECDHE)仅仅是一个更昂贵的比RSA同等安全级别…在实际部署中,咱们发现,启用和优先ECDHE密码套件是微不足道的CPU使用量的增长引发的。HTTP keepalives和会话恢复意味着大多数请求不须要一个完整的握手,握手操做并不占用咱们的CPU使用率。咱们发现75%的Twitter客户端使用ECDHE在链接创建请求被发送。剩下的25%主要由老客户还不支持ECDHE密码套件。

雅各Hoffman-Andrews(Twitter)
在本身的部署过程当中获得最好的结果,启动最好的TLS会话恢复,优化其成功率。消除每个握手须要执行昂贵的公钥密码学操做将明显下降计算成本,同时减小TLS延迟;没有理由把CPU周期浪费在本不须要作的事情上面。

谈到优化CPU周期,请必定要保持你的服务器更新与TLS库的最新版本!除了安全改进,你也会常常看到性能优点。安全性和性能是密不可分的。

启用 1-RTT TLS握手

一个未优化的TLS部署能够轻松添加许多额外的往返和介绍user-e.g明显延迟。multi-RTT握手,缓慢而无效的证书撤销支票、大TLS记录,须要屡次往返的

调优的TLS部署应该最多添加一个额外的往返谈判TLS链接,无论它是新的或恢复,并避免其余延迟陷阱:配置会话恢复,并使向前保密支持TLS FALSE Start。

要得到最佳的端到端性能,确保审计本身的和第三方服务和服务器所使用的应用程序,包括你的CDN提供商。快速,与流行的服务器和发布商的概述,请查看istlsfastyet.com.

优化链接重用

最好的方法减小计算开销和延迟设置新的TCP + TLS链接优化链接重用。这样平摊到了设置成本在请求和向用户提供更快的体验。

验证您的服务器和代理配置设置容许keepalive链接,和审计链接超时设置。许多流行的服务器组积极的链接超时(例如Apache版本默认为5 s超时),迫使不少没必要要的协议。为达到最佳效果,使用你的日志和分析来肯定最优超时值。

利用提早终止

正如咱们讨论的Primer on Latency and Bandwidth,咱们可能没法使咱们的包跑得更快,但咱们可让他们更短的距离。经过将咱们的“边缘”服务器接近用户(图4 - 9日),咱们能够显著减小往返时间和TCP和TLS握手的总成本。

图4 - 9日。客户端链接的早期终止
一个简单的方法来作到这一点是利用内容分发网络(CDN)的服务,维护全球的边缘服务器池,或者本身部署。经过容许用户终止与附近的服务器,而不是穿越在海洋和大陆连接你的来源,客户获得的好处与短循环“提早终止”。这种技术一样是有用的和重要的静态和动态内容:静态内容也能够由边缘服务器缓存,而动态请求能够在创建路由链接从边缘到原点。

CDN获取资源

使用CDN技术或代理服务器来获取资源,这可能须要每一个用户定制的或包含其它私人数据,所以不是一个全球缓存资源的优点,一般被称为一个“未取回起源。”

而cdn效果最好,当数据被缓存在geo-distributed服务器在全世界范围内,仍未起源获取提供了一个很是重要的优化:客户端链接终止与附近的服务器,这能够大大减小握手延迟成本。反过来,CDN,或者本身的代理服务器,能够维持一个“温暖的链接池”起源服务器传递数据,容许您返回一个快速响应返回到客户机。

事实上,做为一个额外的一层优化,附近一些CDN提供商使用服务器链接两岸的!客户端链接终止在附近的一个CDN节点,而后将请求到CDN节点接近原点,而后请求被路由到原点。跳在CDN网络容许流量路由优化CDN骨干,这有助于进一步减小客户端和起源服务器之间的延迟。

配置会话缓存和无状态恢复

终止接近用户的链接是一种优化,有助于下降延迟为用户在全部状况下,但再一次,没有一点比一点快sent-send更少的比特。支持TLS会话缓存和无状态恢复容许咱们消除整个往返重复访客的延迟和减小计算开销。

会话标识符,TLS会话缓存依赖,介绍了SSL宽2.0,大多数客户端和服务器的支持。然而,若是你是在您的服务器上配置TLS,不要认为会话将在默认状况下支持。事实上,它是更常见的在大多数服务器的默认设置你知道更好!仔细检查并验证您的服务器、代理和CDN配置:

服务器有多个进程或员工应该使用一个共享会话缓存。

共享会话缓存的大小应该调整你的交通水平。

应提供会话超时时间。

在一个多服务器的设置中,客户端IP路由同样,或TLS会话ID相同,相同的服务器是一种提供良好的会话缓存利用率。

“粘性”负载平衡在哪里并非一个选择,应该使用一个共享缓存不一样服务器之间提供良好的会话缓存利用率,并创建安全机制须要分享和更新提供会话密钥来解密票。

检查和监控你的TLS会话缓存统计数据最佳性能。

在实践中,为达到最佳效果,你应配置两个会话缓存机制和会话ticket。这些机制共同努力,为新老客户提供最好的报道。

支持TLS False Start

会话恢复提供了两个重要的好处:它消除了额外的握手往返返回游客和下降计算成本的握手,容许重用以前协商会话参数。然而,它在第一次与服务器通讯,或者前一交易日已通过期是无效的。

获得最好的两个全世界一个往返握手为新和重复访客,和计算节省重复visitors-we可使用TLS FALSE Start,这是一个可选的扩展协议,容许发送方发送应用程序数据(图4到10)握手时只有部分完成。

图4到10。TLS握手与错误的开始
FALSE Start不修改TLS握手协议,相反,它只会影响协议的时机当应用程序能够发送数据。直观地说,一旦客户端发送 ClientKeyExchange记录,它已经知道加密密钥,就能够开始发送应用程序数据,剩下的握手是花握手确认没有人篡改记录,而且能够并行完成的。所以,错误的开始让咱们保持TLS握手一次往返无论咱们是否执行一个完整的或缩写握手。

部署TLS False Start

由于错误的开始只是握手协议的修改时间,它不须要任何更新TLS协议自己和能够unilaterally-i.e实现。,客户端能够开始传输加密的应用程序数据。理论上是这样的。

在实践中,尽管TLS False Start应该向后兼容全部现有的TLS客户机和服务器,使其默认为全部TLS链接问题被证实是因为一些糟糕的服务器实现。所以,全部现代浏览器都可以使用TLS FALSE Start,但某些条件获得知足时才会这么作的服务器:

Chrome和Firefox须要ALPN协议声明出如今服务器的握手,和选择的密码套件服务器使保密。

Safari要求密码组合要求服务器支持向前保密。

Internet Explorer使用黑名单的网站的结合,打破启用TLS False Start 时,和一个超时重复握手若是TLS FALSE Start握手失败了。

全部浏览器支持TLS FALSE Start服务器应该作广告支持的协议的列表经过ALPN extension-e.g。“h2,http / 1.1”——被配置为支持和更喜欢密码套件,使保密。

优化TLS记录大小

全部应用程序数据经过TLS内运输记录协议(图4 - 8)。每一个记录是16 KB的最大大小,取决于所选的密码,每一个记录将增长20到40字节的头开销,MAC和可选的填充。若是记录符合一个TCP数据包,而后咱们还必须添加TCP / IP开销:IP 20-byte头,20-byte头不为TCP选项。所以,有可能为每个记录60到100字节的开销。对于一个典型的最大传输单元(MTU)线大小为1500字节,这包结构转化为最小帧开销的6%。

记录越小,帧开销越高。然而,仅仅增长记录其最大尺寸的大小(16 KB)并不必定是一个好主意。若是记录多个TCP数据包,那么TLS层必须等待全部TCP数据包到达才能解密数据(图4 -)。若是这些TCP数据包迷路了,从新排序,或限制因为拥塞控制,而后TLS的各个片断记录必须缓冲以前能够解码,致使额外的延迟。在实践中,这些延迟能够为浏览器建立的重要瓶颈,更愿意消费数据以流的方式。

图4。WireShark捕获的11211字节的TLS记录分歧8 TCP段
小记录产生开销,大型记录产生延迟,没有一个“最优”记录的值大小。相反,为web应用程序,使用浏览器,最好的策略是动态调整记录大小基于TCP链接的状态:

当链接是新的和TCP拥塞窗口较低,或当链接闲置一段时间(见缓慢的开始重启),每一个TCP包应该携带一个TLS记录,和TLS记录应该占领整个最大段大小由TCP(MSS)分配。

当链接拥塞窗口很大,若是咱们将一个大型流(如。流媒体视频),TLS记录的大小能够增长跨多个TCP数据包(16 kb)减小框架和客户端和服务器上的CPU开销。

若是TCP链接一直闲置,即便慢启动重启服务器上禁用,最好的策略是减小数据的记录大小在发送一个新的破裂:条件可能改变了自去年传播,咱们的目标是最小化的几率缓冲在应用程序层因为丢包,从新排序,重发。

使用一个动态交互式交通战略提供最佳性能:小记录大小能够消除没必要要的缓冲延迟和提升time-to-first - { HTML字节,…,视频帧},和一个更大的记录大小优化吞吐量为长寿流TLS的开销最小化。

肯定最优记录大小为每一个状态让咱们从最初的开始一个新的或闲置的TCP链接,咱们但愿避免TLS记录跨越多个TCP数据包:

IPv4分配20字节帧开销和40个字节为IPv6。

为TCP框架的开销分配20字节。

分配40字节TCP选项开销(时间戳,袋)。

假设一个常见的1500字节的MTU开始,这使得1420字节的TLS记录交付在IPv4,并为IPv6 1400字节。不会过期的技术,使用IPv6大小,留下1400字节为每一个TLS记录,并根据须要调整若是你的MTU低。

接下来,决定当记录大小应该增长和复位若是链接一直闲置,能够设置基于预配置的阈值:记录大小增长到16 KB XKB的数据传输,重置后记录大小 Y空闲时间的毫秒。

一般状况下,配置TLS记录大小不是咱们能够控制在应用程序层。相反,一般这是一个设置,有时TLS服务器的编译时常量。检查您的服务器的文档有关如何配置这些值。

TLS在谷歌优化

2014年初,谷歌的服务器使用小TLS记录,符合一个TCP段第一1 MB的数据,记录大小增长到16 KB以后优化吞吐量,而后重置记录大小回到一段inactivity-lather一秒钟以后,冲洗,重复。

一样,若是您的服务器处理大量的TLS链接,而后最小化优化内存使用每一个链接能够是相当重要的。默认状况下,OpenSSL等流行的库将50 KB的内存分配每一个链接,但与记录大小,它可能值得检查文件或源代码如何调整这个值。谷歌服务器减小OpenSSL缓冲区降低到5 KB。

优化证书链

验证信任链遍历链要求浏览器,从网站的证书,并递归地验证证书的父母,直到达到一个可信的根。所以,它是相当重要的,提供链包括全部中级证书。若是有遗漏,浏览器将被迫暂停验证过程和获取丢失的证书,添加额外的DNS查找,TCP握手和HTTP请求到流程中。

浏览器如何知道从哪里获取丢失的证书吗?每一个孩子父母证书一般包含一个URL。若是省略的URL和所需的证书是不包括的,而后验证将会失败。

相反,不包括没必要要的证书,如受信任的根证书中那些添加没必要要的字节。回想一下,发送服务器证书链的TLS握手,这是可能发生在一个新的TCP链接,在早期阶段的慢启动算法。若是证书链的大小超过最初TCP的拥塞窗口,而后咱们将无心中添加额外的次往返TLS握手:证书长度将溢出拥塞窗口,致使服务器中止,等待客户ACK以前。

在实践中,证书链的大小和深度是一个更大的担心和问题在旧TCP堆栈初始化其初始4 TCP segments-see拥塞窗口慢启动。对于更新的部署,最初的TCP拥塞窗口已经提升到10段,应该足够大多数证书链。

也就是说,验证您的服务器使用的是最新的TCP协议栈和设置,并优化,减小你的证书链的大小。少发送字节老是良好的和有价值的优化。

配置OCSP装订

每个新的TLS链接要求,浏览器必须验证发送的签名证书链。然而,还有一个重要的步骤,咱们不能忘记:浏览器也须要验证证书没有被撤销。

验证证书的状态浏览器可使用几种方法之一:证书撤销列表(CRL),在线证书状态协议(OCSP),或OCSP装订。每种方法都有本身的局限性,但OCSP装订提供,到目前为止,最好的安全性和性能guarantees-refer早期部分的细节。确保配置你的服务器包括(主食)提供证书的CA的OCSP反应链。这样作容许浏览器执行撤销检查没有任何额外的网络数据传输次数和提升安全保证。

OCSP响应能够改变从400年到4000字节大小。装订这个响应你的证书链将增长其size-pay密切关注证书链的总大小,这样它不会溢出的初始拥塞窗口新的TCP链接。

当前OCSP装订实现只容许一个单一的OCSP响应包含,这意味着浏览器可能要回退到另外一个若是它须要验证其余证书撤销机制的chain-reduce证书链的长度。在将来,OCSP Multi-Stapling应该解决这个问题。

最受欢迎的服务器支持OCSP装订。检查相关文档的支持和配置说明。一样,若是使用或决定一个CDN,检查他们的TLS堆栈支持和配置为使用OCSP装订。

启用HTTP严格的传输安全性(hst)

HTTP严格的交通安全是一个重要的安全策略机制,容许一个起源宣布访问规则经过一个简单的HTTP header-e.g兼容的浏览器。“Strict-Transport-Security:信息= 31536000”。具体地说,它指示用户代理执行如下规定:

全部请求的起源应该发送/ HTTPS。这包括导航和全部其余同源子资源requests-e.g。若是用户类型没有https URL前缀用户代理应该自动将它转换成一个https请求;若是一个页面包含一个引用非http资源,用户代理应该自动转换成请求https版本。

若是不能创建一个安全链接,用户不容许绕过HTTP version-i.e警告和请求。origin的协议是是https。

信息在几秒钟内指定指定hst的生命周期规则集(例如, max-age=31536000等于365天一辈子的广告策略)。

includeSubdomains代表当前的政策应该适用于全部子域。

hst origin 转换为一个https目的地和帮助保护应用程序从各类各样的被动和主动网络的攻击。还有一个额外的好处,它还提供了一个不错的性能优化经过消除须要HTTP-to-HTTPS重定向:客户端自动重写全部请求安全起源以前派遣!

确保启用hst以前完全地测试您的TLS部署。一旦政策是由客户端缓存,未能协商将致使hard-fail-i.e TLS链接。用户将看到浏览器错误页面,不会被容许继续下去。这种行为是明确的和必要的设计选择,以防止网络攻击者骗取客户没有HTTPS访问你的网站。

hst预加载列表

hst机制留下第一个请求的来源不受保护的积极attacks-e.g。恶意方能够下降客户的请求,并防止它注册hst政策。为了解决这个问题,大多数浏览器提供一个单独的“hst预加载列表”机制,该机制容许一个起源请求包含列表中的HSTS-enabled附带浏览器的网站。

一旦你有信心在你的HTTPS部署,考虑提交你的网站到hst经过预加载列表hstspreload.appspot.com.

启用 HTTP Public Key Pinning (HPKP)

的缺点之一,当前系统中讨论链的信任和证书颁发机构是咱们的依赖大量的受信任的证书颁发机构(CA)。一方面,这是方便的,由于它意味着咱们能够得到一个有效的证书从一个大池的实体。然而,这也意味着其中任何一个实体也可以发出有效的证书给咱们

DigiNotar认证权威的妥协的引人注目的例子之一是一个攻击者可以发行和使用虚假但有效证件与数以百计的高调的网站。

HPKP容许一个站点发送一个HTTP头指示浏览器记住(“pin”)一个或多个证书的证书链。经过这样作,它能够范围证书,或者发行人,应该接受浏览器在随后的访问:

origin能够销毁叶证书。这是最安全的策略,由于,实际上,硬编码一个小的特定证书签名应该接受浏览器。

父的起源能够销一个证书的证书链。例如,原点能够销中级证书的CA,告诉浏览器,这个特殊的起源,它应该只信任证书签署的证书颁发机构。

销哪一个证书,选择正确的战略和多少备份提供,时间,和其余标准部署HPKP是重要的,微妙的,超出了咱们的讨论范围。咨询你的最喜欢的搜索引擎,或者你当地的安全专家,以获取更多信息。

HPKP还公开一个“报告”模式,不执行提供销但可以检测到故障报告。这是一个伟大的第一步验证您的部署,和做为一种机制来检测违规。

更新网站内容,HTTPS

获得最好的安全性和性能担保其实是相当重要的,网站使用HTTPS来获取它的全部资源。不然,咱们遇到一些问题,最坏的就是网站崩溃

将被浏览器混合的“活跃”内容(如HTTP上的脚本和样式表传递)可能会破坏网站的功能。

混合的“被动”内容(如图片、视频、音频等,交付经过HTTP)将获取,但将容许攻击者观察和推断用户活动,并下降性能要求额外的链接和握手。

审计内容和更新你的资源和连接,包括第三方的内容,使用HTTPS。的内容安全政策(CSP)机制能够很大的帮助,肯定违反HTTPS和执行所需的政策。

Content-Security-Policy: upgrade-insecure-requests
Content-Security-Policy-Report-Only: default-src https:;
report-uri https://example.com/reporting...
告诉浏览器升级全部(本身的和第三方)请求HTTPS。
告诉浏览器报告任何违反非http指定端点。
CSP提供了一个高度可配置的机制来控制哪些资产能够被使用,以及如何,从那里他们能够获取。利用这些功能,能够保护你的网站和你的用户。

性能检查表

做为应用程序开发人员咱们免受大多数TLS协议的复杂性客户机和服务器表明咱们作最困难的工做。然而,正如咱们在本章中看到的,这并不意味着咱们能够忽视在TLS交付咱们的应用程序的性能方面。优化咱们的服务器,使关键TLS优化和配置应用程序启用客户端利用这些特性支付高额股息:更快的握手,减小延迟,更好的安全保障,等等。

考虑到这一点,一个简短的清单放在议事日程:

从TCP得到最佳性能;请参阅优化TCP.

TLS库升级到最新版本,和(从新)构建服务器。

启用和配置会话缓存和无状态的恢复。

监控你的会话缓存命中率,并相应地调整配置。

配置向前保密密码启用TLS FALSE Start。

终止TLS会话更接近用户往返延迟最小化。

使用动态TLS记录分级优化延迟和吞吐量。

审计和优化你的证书链的大小。

配置OCSP装订。

配置hst和HPKP。

配置CSP的政策。

启用HTTP / 2;看到HTTP / 2.

测试和验证

最后,为了验证和测试您的配置,您可使用一个在线服务,好比Qualys SSL服务器测试扫描你的公共服务器常见配置和安全漏洞。此外,你应该熟悉 openssl命令行界面,这将帮助你检查整个握手并在本地配置你的服务器。

$ > openssl s_client状态-CAfile startssl.ca。crt链接igvita.com:443

链接(00000003)
SSL_connect:前/链接初始化
SSL_connect:SSLv2的站点时/ v3写客户你好
SSL_connect:SSLv3读服务器你好
深度= 2 / C = IL / O = StartCom有限公司/ OU =安全数字证书签名
/ CN = StartCom认证权威
验证返回:1
深度= 1 / C = IL / O = StartCom有限公司/ OU =安全数字证书签名
/ CN = StartCom类1主要中间服务器
验证返回:1
深度= 0 = ABjQuqt3nPv7ebEG /描述/ C =
/ CN =www.igvita.com/emailAddress=ilya@igvita.com
验证返回:1
SSL_connect:SSLv3读服务器证书
SSL_connect:SSLv3读服务器作了
  SSL_connect:SSLv3 write client key exchange A
  SSL_connect:SSLv3 write change cipher spec A
  SSL_connect:SSLv3 write finished A
  SSL_connect:SSLv3 flush data
  SSL_connect:SSLv3 read finished A
  ---
  Certificate chain 
   0 s:/description=ABjQuqt3nPv7ebEG/C=US
       /CN=www.igvita.com/emailAddress=ilya@igvita.com
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
   1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Certification Authority
  ---
  Server certificate
  -----BEGIN CERTIFICATE-----
  ... snip ...
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 3571 bytes and written 444 bytes 
  ---
  New, TLSv1/SSLv3, Cipher is RC4-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1
      Cipher    : RC4-SHA
      Session-ID: 269349C84A4702EFA7 ... 
      Session-ID-ctx:
      Master-Key: 1F5F5F33D50BE6228A ...
      Key-Arg   : None
      Start Time: 1354037095
      Timeout   : 300 (sec)
      Verify return code: 0 (ok)
  ---

客户端完成验证收到的证书链。
收到证书链(两个证书)。
收到了证书链的大小。
发布了有状态的会话标识符TLS的简历。
在前面的例子中,咱们链接igvita.com在默认的TLS端口(443),并执行TLS握手。由于 s_client没有假设已知的根证书,咱们手动指定路径StartSSL证书的根证书Authority-this是很重要的。浏览器已经StartSSL的根证书,所以可以验证链,可是 s_client没有这样的假设。试着删除根证书,你将看到一个验证错误日志中。

检查证书链显示服务器发送两个证书,加起来3571个字节。同时,咱们能够看到协商会话variables-chosen TLS协议,密码,钥匙,咱们还能够看到服务器发布当前会话的会话标识符。

outshineamaze: 时间匆忙, 若有错误, 多多包涵