关注网络安全
和行业未来

OpenSSL 1.1.1发布 正式支持TLS1.3

Jesdoit阅读(162)评论(0)

在经历两年的修补改进后,OpenSSL于近日发布了1.1.1版本并承诺至少投入5年的时间支持该版本。

OpenSSL的Matt Caswell在博文中感谢了对OpenSSL近5000次的优化的两百多名志愿者,以及所有下载测试版本并提供反馈的各种用户。

OpenSSL1.1.1的一大亮点无疑是TLS1.3。这个在一个月前由IETF发布为RFC8446的最新协议改写了以往的旧标准,其包含全新的特性备受瞩目并在OpenSSL的1.1.1版本中展现。

更重要的是,OpenSSL 1.1.1是个API,且ABI兼容OpenSSL 1.1.0。所以大多数使用1.1.0的应用程序只需通过新的OpenSSL版本就可以获得TLSv1.3的许多好处。尽管如此,由于TLSv1.3与TLSv1.2的工作方式非常不同,少数应用程序可能会遭遇警告。 有关更多详细信息,请参阅OpenSSL wiki上的TLSv1.3页面

文章还指出了OpenSSL 1.1.1中具体包含的新特性:

  • 由于减少了客户端和服务器之间所需的往返次数,缩短了连接时间
  • 在某些情况下,客户端能够立即开始将加密数据发送到服务器而无需与服务器进行任何往返(称为0-RTT或“早期数据”)。
  • 由于删除了各种过时和不安全的加密算法以及更多连接握手的加密,提高了安全性

以及OpenSSL 1.1.1新增的:

  • 完全重写OpenSSL随机数生成器以引入以下功能
    • 默认的RAND方法现在使用符合NIST标准SP 800-90Ar1的AES-CTR DRBG。
    • 通过种子链支持多个DRBG实例。
    • 有一个公共和私有DRBG实例。
    • DRBG实例是分叉安全的。
    • 可启用将所有全局DRBG实例保留在安全堆上。
    • 公共和私有DRBG实例每线程锁定自由操作
  • 支持各种新的加密算法,包括:
    • SHA3
    • SHA512 / 224和SHA512 / 256
    • EdDSA(包括Ed25519和Ed448)
    • X448(添加到1.1.0中的现有X25519支持)
    • 多素数RSA
    • SM2
    • SM3
    • SM4
    • SipHash
    • ARIA(包括TLS支持)
  • 显著的侧通道攻击安全性改进
  • 最大片段长度TLS扩展支持
  • 一个新的STORE模块,它实现了一个基于统一和URI的存储读取器,可以包含密钥,证书,CRL和许多其他对象。

此外,由于OpenSSL 1.1.0不是LTS版本,因此根据OpenSSL之前的公告和此次发布的策略,它将立即开始接收安全修复程序,并且将在一年内停止获得所有支持(不再维护)。

之前的LTS版本(OpenSSL 1.0.2)将继续获得全面支持,直到今年年底。 之后它只会收到安全修复程序。 它将在2019年底停止接收所有支持。笔者强烈建议该版本的用户升级到OpenSSL 1.1.1。

Matt Caswell还透露,下一个OpenSSL的重要功能将是新的FIPS模块。

离不开OpenSSL的你,是否已经跃跃欲试了呢?

 

稿源:OpenSSL blog

八月行业新闻回顾

Jesdoit阅读(268)评论(0)

本月大事件:TLS 1.3 正式发布

盼望着,盼望着,TLS协议1.3版本(RFC 8446)终于在本月发布啦!

我们在之前的新闻简报中多次讨论过TLS 1.3的发展。新的协议版本弃用了许多有问题和不安全的做法,包括没有前向保密的静态RSA密码,带有MAC-then-Encrypt的CBC模式,不安全的哈希以及许多其他旧算法。新功能包括了删除一次往返的来回握手,可选且有争议的零往返模式,加密证书,AEAD模式的更安全的随机数构造以及RSA-PSS签名。

TLS 1.3的开发花费的时间比预期的要长,因为许多部署的设备没有正确实现TLS握手,或者在看到尚未知的TLS版本时以其他方式破解。

TLS 1.3的部署在最终确定之前已经开始;各种浏览器和服务器已支持草稿版本。预计他们很快就会进入最终版本。

IETF发布了一篇介绍新TLS版本的博客文章,Cloudflare的Nick Sullivan撰写了非常详细的描述

短新闻

  • 8月1日起,证书颁发机构不再允许使用两种有问题的验证方法。这些方法允许在没有任何技术验证的情况下检查域的所有权。 Digicert解释了细节
  • Mega.nz同步客户端包含一个带有用于localhost连接的私钥的证书
  • 许多人在TLS研究中使用Alexa Top 1 Million列表,因此了解它的可靠性非常重要。几家机构的研究人员查看了这份名单,发现了几个值得注意的特性;比方说,每天都有大变化。
  • 8月1日起,苹果公司停止信任部分赛门铁克证书,并发布了一项计划,表明它将在2018年晚些时候停止相信其余的证书。
  • Facebook发布了Fizz,一个支持TLS 1.3的开源库。
  • 微软接受了Let's Encrpyt的根证书。这意味着所有主流浏览器现在都直接接受Let's Encrpyt的根。由于使用了由IdenTrust证书颁发机构签名的交叉签名中间件,Let's Encrypt早已被大部分浏览器接纳。
  • RFC 8410为X.509证书中的Ed25519指定了现代椭圆曲线加密算法的标识符。
  • RFC 8422定义了TLS 1.2及更早版本的现代椭圆曲线(曲线25519,曲线448)。
  • OpenSSL发布了1.1.0i和1.0.2p版本,修复了之前公开的两个不太严重的安全问题。
  • 谷歌发布了一份关于HTTPS安全团队的Emily Schechter的采访
  • MesaLink是一个用Rust编写的TLS库,旨在与OpenSSL兼容。
  • Trail of Bits探索使用Rowhammer式攻击来注入错误并导致RSA-CRT错误。 RSA-CRT算法的属性意味着签名中的错误计算允许攻击者正常地计算私钥。
  • 一篇研究论文研究了加密库中素性测试的稳健性,并发现了几个问题。
  • 研究人员在TLS中发布了针对CBC模式的Lucky Thirteen攻击的新变种,影响了亚马逊的s2n,GnuTLS,mbed TLS和wolfSSL。
  • Thyla van der Merwe发表了她的博士论文,该论文分析了TLS 1.3。
  • 谷歌最近宣布,它打算取消对Chrome中令牌绑定的支持,默认情况下从未启用。 另一方面,微软宣布它计划在未来如何使用令牌绑定。 令牌绑定可以将应用程序级令牌(如cookie)直接绑定到TLS连接,但这是否具有实际用途仍然存在争议。
  • 汉堡大学的研究人员研究了如何将TLS会话恢复用作跟踪机制
  • Ian Foster和Dylan Ayrey发布了有关改变所有权的域名证书的研究。这项工作也在DEFCON上发表。这会导致两个有问题的情况:首先,旧的域所有者可能仍然拥有允许对证书进行中间人攻击的私钥。其次,对于许多域共享单个证书的云提供商,这可能允许域所有者撤销该证书,从而导致拒绝服务。
  • 黑帽会议上的一次演讲着眼于TLS 1.3和0-RTT的重播攻击
  • 今年的Pwnie最佳加密攻击奖授予了ROBOT攻击。
  • 普林斯顿大学的研究人员研究了证书发布过程中的BGP攻击,并在USENIX会议上发表了他们的研究成果
  • Brigham Young大学的一个研究小组提出了一个支持直接TLS的套接字API。它发布在USENIX会议上,并在Facebook的互联网防御奖中获得第二名。

稿源: Feisty Duck

Cloutflare:TLS 1.3解读 你想了解的都在这儿

Jesdoit阅读(365)评论(0)

在过去的五年中,互联网工程任务组(IETF),即定义互联网协议的标准机构,一直致力于标准化其最重要的安全协议之一的最新版本:传输层安全性(TLS)。 TLS用于保护Web(以及更多!),提供加密并确保每个HTTPS网站和API的真实性。 最新版本的TLS,TLS 1.3(RFC 8446)于本月10日发布。 这是该协议的第一次重大改革,带来了重大的安全性和性能改进。 本文转载自Cloudflare博客,深入探讨了TLS 1.3中引入的变化及其对互联网安全未来的影响。

一场变革

Cloudflare提供安全性的一个主要方式是支持网站和API等Web服务的HTTPS。使用HTTPS(“S”代表安全),浏览器和服务器之间的通信通过加密和经过身份验证的通道传输。通过HTTPS而不是HTTP提供内容可以让访问者确信他们看到的内容是由合法内容所有者呈现的,并且通信是安全的,不会被窃听。在这个世界里,在线隐私比以往任何时候都更加重要,这是一个大问题。

使HTTPS安全的引擎下的机制是一种称为TLS的协议。它源于九十年代中期在Netscape开发的称为安全套接字层(SSL)的协议。到20世纪90年代末,Netscape将SSL交给IETF,IETF将其重命名为TLS,并从此成为该协议的管理者。许多人仍将Web加密称为SSL,即使绝大多数服务已切换到仅支持TLS。 SSL这个术语继续受到人们的欢迎,而Cloudflare通过无钥匙SSL和通用SSL等产品名称使这个术语保持活力。

在IETF中,协议称为RFC。 TLS 1.0是RFC 2246,TLS 1.1是RFC 4346,TLS 1.2是RFC 5246.今天,TLS 1.3发布为RFC 8446. RFC通常按顺序发布,保留46作为RFC编号的一部分是一个很好的延续。

在过去几年中,TLS已经被发现诸多的问题。 首先,实现TLS的代码存在问题,包括Heartbleed,BERserk,goto fail;等等。 这些问题不是协议的基础,而且主要是由于缺乏测试。 像TLS Attacker和Project Wycheproof这样的工具有助于提高TLS实施的稳健性,但TLS面临的更具挑战性的问题与协议本身有关。

TLS由工程师使用数学家的工具设计。 SSL时代的许多早期设计决策都是使用启发式方法和对如何设计健壮的安全协议的不完全理解。 也就是说,这不是协议设计者(Paul Kocher,Phil Karlton,Alan Freier,Tim Dierks,Christopher Allen等人)的错,因为整个行业仍在学习如何正确地做到这一点。 在设计TLS时,关于安全认证协议设计的正式论文,如Hugo Krawczyk的标志性SIGMA论文,还需要几年的时间。 TLS是90年代的密码:它当时意味着很好,看起来很酷,但是现代密码学家的调色板已经发展得不同了。

许多设计缺陷是使用形式验证发现的。 学者们试图证明TLS的某些安全属性,但却找到了反例,这些反例被转化为真正的漏洞。 这些弱点包括纯理论(SLOTH和CurveSwap),高资源攻击者(WeakDH,LogJam,FREAK,SWEET32),既“实用”又“危险”(POODLE,ROBOT)。

TLS 1.2实在是太慢了

加密在网上一直很重要,但从历史上看,它只用于登录或发送信用卡信息,使大多数其他数据暴露。 在过去几年中,一直存在一个主要趋势,即将HTTPS用于互联网上的所有流量。虽然能够保护更多我们在线上的交互,但却使连接变得更慢了。

要使浏览器和Web服务器就密钥达成一致,他们需要交换加密数据。 自TLS于1999年标准化以来,在TLS中称为“握手”的交换基本保持不变。握手需要在发送加密数据之前在浏览器和服务器之间再进行两次往返(或者在恢复先前连接时进行一次往返))。 与单独的HTTP相比,HTTPS的TLS握手的额外成本导致潜在的显着命中。 这种额外的延迟会对以性能为中心的应用产生负面影响。

定义TLS 1.3

IETF对TLS 1.2的过时设计和两次往返开销不满意,开始着手定义新版本的TLS。 2013年8月,Eric Rescorla为新协议制定了一份功能愿望清单:

https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf

经过一番辩论后,决定将这个新版本的TLS称为TLS 1.3。 推动TLS 1.3设计的主要问题与五年前提出的主要问题大致相同:

  • 减少握手延迟
  • 加密更多的握手
  • 提高跨协议攻击的弹性
  • 删除旧功能

该规范由志愿者通过开放的设计过程塑造,经过四年的勤奋工作和激烈的辩论,TLS 1.3现在处于最终形式:RFC 8446.随着采用的增加,新协议将使互联网更快、更安全。

下文将重点介绍TLS 1.3与以前版本相比的两个主要优势:安全性和性能。


在过去的二十年中,我们已经学到了很多关于如何编写安全加密协议的知识。 从POODLE到Lucky13到SLOTH到LogJam的巧妙命名攻击表明了,即使是TLS 1.2也包含了加密设计早期的陈旧观点。 TLS 1.3的设计目标之一是通过消除潜在危险的设计元素来纠正以前的错误。

修复密钥交换

TLS是所谓的“混合”密码系统。这意味着它使用对称密钥加密(加密和解密密钥相同)和公钥加密(加密和解密密钥不同)。混合方案是Internet上使用的主要加密形式,用于SSH,IPsec,Signal,WireGuard和其他协议。在混合密码系统中,公钥密码术用于在双方之间建立共享密钥,共享密钥用于创建可用于加密交换数据的对称密钥。

根据经验,公钥加密是缓慢且昂贵的(每个操作几微秒到几毫秒),对称密钥加密快速且便宜(每个操作纳秒)。混合加密方案允许您通过仅执行一次昂贵的部分,以极少的开销发送大量加密数据。 TLS 1.3中的大部分工作都是关于改进握手的部分,其中公钥用于建立对称密钥。

RSA密钥交换

TLS的公钥部分是关于建立共享秘密。 使用公钥加密有两种主要方法。 更简单的方法是使用公钥加密:一方用另一方的公钥加密共享密钥并发送它。 然后另一方使用其私钥解密共享秘密并且......原来他们都有同样的秘密。 这种技术于1977年由Rivest,Shamir和Adelman发现,称为RSA密钥交换。 在TLS的RSA密钥交换中,共享密钥由客户端决定,然后客户端将其加密到服务器的公钥(从证书中提取)并将其发送到服务器。

TLS中提供的另一种密钥交换形式是基于另一种形式的公钥密码术,由Diffie和Hellman于1976年发明,即所谓的Diffie-Hellman密钥协议。 在Diffie-Hellman中,客户端和服务器都从创建公钥 - 私钥对开始。 然后,他们将其关键份额的公共部分发送给另一方。 当每一方收到另一方的公钥共享时,他们将其与他们自己的私钥组合在一起,最终得到相同的值:前主秘密。 然后,服务器使用数字签名来确保交换未被篡改。 如果客户端和服务器都为每个交换选择一个新的密钥对,则该密钥交换称为“临时交换”。

两种模式都会导致客户端和服务器具有共享密钥,但RSA模式有一个严重的缺点:它不是前瞻性的。这意味着如果有人记录加密的对话,然后获得服务器的RSA私钥,他们就可以解密对话。这甚至适用于记录对话并且密钥在未来一段时间内获得的情况。在一个国家政府正在记录加密对话并使用像Heartbleed这样的漏洞来窃取私钥的世界中,这是一个相当现实的威胁。

RSA密钥交换在一段时间内一直存在问题,且不仅仅是因为它不是前向保密的。1998年,Daniel Bleichenbacher在SSL中进行RSA加密的方式发现了一个漏洞并创建了所谓的“百万消息攻击”,它允许攻击者通过发送一百万或者一个服务器的私钥来执行RSA私钥操作。 如此精心设计的消息,并寻找返回的错误代码的差异。 多年来,这种攻击得到了改进,在某些情况下只需要数千条消息便能从一台普通笔记本电脑发动攻击。最近发现,主要网站(包括facebook.com)在2017年也容易受到Bleichenbacher攻击变种的影响,称为ROBOT攻击。

为了降低非前向秘密连接和百万邮件攻击所带来的风险,RSA加密已从TLS 1.3中删除,将短暂的Diffie-Hellman作为唯一的密钥交换机制。 删除RSA密钥交换带来了其他优势,我们将在下面的性能部分中讨论。

以Diffie-Hellman命名的加密手段

在加密方面,提供太多选项会导致选择错误的选项。 在选择Diffie-Hellman参数时,这个原理最为明显。 在以前版本的TLS中,Diffie-Hellman参数的选择取决于参与者。 这导致一些实现选择不正确,导致部署易受攻击的实现。 TLS 1.3取消了这一选择。

Diffie-Hellman是一个功能强大的工具,但并非所有Diffie-Hellman参数都可以“安全”使用。 Diffie-Hellman的安全性取决于称为离散对数问题的特定数学问题的难度。 如果可以解决一组参数的离散对数问题,则可以提取私钥并破坏协议的安全性。 一般来说,使用的数字越大,解决离散对数问题就越困难。 因此,如果您选择较小的DH参数,则会遇到麻烦。

2015年的LogJam和WeakDH攻击表明,许多TLS服务器可能被欺骗使用Diffie-Hellman的小数字,允许攻击者破坏协议的安全性并解密对话。

Diffie-Hellman还要求参数具有某些其他数学属性。 2016年,Antonio Sanso在OpenSSL中发现了一个问题,其中选择的参数缺乏正确的数学属性,导致另一个漏洞。

TLS 1.3采用固定路由,将Diffie-Hellman参数限制为已知安全的参数。 但是,它仍然有几个选择; 只允许一个选项使得在以后发现这些参数不安全的情况下更新TLS非常困难。

混合加密方案的另一半是数据的实际加密。 这是通过组合认证码和对称密码来完成的,每个参与方都知道密钥。 正如我将要描述的,有许多方法可以加密数据,其中大多数都是错误的。

CBC模式密码

在上一节中,我们将TLS描述为混合加密方案,具有公钥部分和对称密钥部分。 公钥部分并不是多年来造成麻烦的唯一部分。 对称关键部分也有其公平的问题。 在任何安全通信方案中,您都需要加密(保密)和完整性(以确保人们不会修改,添加或删除对话的部分)。 对称密钥加密用于提供加密和完整性,但在TLS 1.2及更早版本中,这两个部分以错误的方式组合,导致安全漏洞。

执行对称加密和解密的算法称为对称密码。 对称密码通常有两种主要形式:分组密码和流密码。

流密码采用固定大小的密钥并使用它来创建任意长度的伪随机数据流,称为密钥流。 要使用流密码进行加密,您可以通过将密钥流的每个位与消息的相应位进行异或来获取消息并将其与密钥流合并。要解密,请使用加密消息并使用密钥流对其进行异或。 纯流密码的示例是RC4和ChaCha20。 流密码很受欢迎,因为它们易于实现且软件速度快。

分组密码与流密码不同,因为它只加密固定大小的消息。 如果要加密比块大小更短或更长的消息,则必须执行一些操作。 对于较短的消息,您必须在消息的末尾添加一些额外的数据。 对于较长的消息,您可以将消息拆分为密码可以加密的块,然后使用分组密码模式以某种方式将各个部分组合在一起。 或者,您可以通过使用块密码加密计数器序列并将其用作流来将块密码转换为流密码。 这称为“计数器模式”。 使用分组密码加密任意长度数据的一种流行方式是称为密码块链接(CBC)的模式。

为了防止人们篡改数据,加密是不够的。 数据还需要受到完整性保护。 对于CBC模式密码,这是使用称为消息验证代码(MAC)的东西来完成的,这类似于带有密钥的花哨校验和。 密码强的MAC具有以下特性:除非您知道密钥,否则找到与输入匹配的MAC值几乎是不可能的。 有两种方法可以组合MAC和CBC模式密码。 您先加密,然后加密密文,或者首先MAC明文,然后加密整个文件。 在TLS中,他们选择后者,MAC-then-Encrypt,结果证明是错误的选择。

你可以将这个选择归咎于BEAST,以及一系列填充oracle漏洞,例如Lucky 13和Lucky Microseconds。CBC模式和填充之间的交互也是SSLv3中广泛宣传的POODLE漏洞和TLS的一些实现的原因。

RC4是由Ron Rivest(RSA的“R”)设计的经典流密码,自TLS早期就得到广泛支持。 在2013年,它被发现具有可衡量的偏差,可以利用它来允许攻击者解密消息。

在TLS 1.3,所有麻烦的密码和密码模式已被删除。 您不能再使用CBC模式密码或不安全的流密码,如RC4。 TLS 1.3中允许的唯一类型的对称加密是一种称为AEAD(带有附加数据的经过身份验证的加密)的新结构,它将加密和完整性结合到一个无缝操作中。

修复数字签名

TLS的另一个重要部分是身份验证。 在每个连接中,服务器使用具有公钥的数字证书向客户端验证自身。 在RSA加密模式中,服务器通过解密预主密钥并在会话的记录上计算MAC来证明其对私钥的所有权。 在Diffie-Hellman模式下,服务器使用数字签名证明私钥的所有权。 如果你到目前为止都读得很仔细,应该很容易猜到这也是错误的。

PKCS#1v1.5

Daniel Bleichenbacher致力于识别TLS中RSA的问题。 2006年,他设计了针对TLS中使用的RSA签名的纸笔攻击。 后来发现包括NSS和OpenSSL在内的主要TLS实施容易受到这种攻击。 此问题再次与正确实现填充的难度有关,在这种情况下,RSA签名中使用的PKCS#1 v1.5填充。 在TLS 1.3中,删除了PKCS#1 v1.5以支持更新的设计RSA-PSS。

签署整个握手记录

我们之前描述过服务器如何使用数字签名来证明密钥交换没有被篡改。 在TLS 1.2及更早版本中,服务器的签名仅涵盖部分握手。 握手的其他部分,特别是用于协商使用哪个对称密码的部分,不由私钥签名。 相反,使用对称MAC来确保握手未被篡改。 这种疏忽导致了许多备受瞩目的漏洞(FREAK,LogJam等)。 在TLS 1.3中,这些被阻止,因为服务器签署整个握手记录。

FREAK,LogJam和CurveSwap攻击利用了两件事:

  1. 许多浏览器和服务器仍然支持20世纪90年代故意弱密码(称为导出密码)的事实,
  2. 以及用于协商使用哪种密码的握手部分未经数字签名的事实。

这些攻击被称为降级攻击,它们允许攻击者强制两个参与者使用双方支持的最弱密码,即使支持更安全的密码也是如此。 在这种攻击方式中,犯罪者处于握手的中间,并将从客户端通告的服务器支持的密码列表更改为仅包含弱导出密码。 然后,服务器选择一个弱密码,攻击者通过暴力攻击计算出密钥,允许攻击者在握手时伪造MAC。 在TLS 1.3中,这种类型的降级攻击是不可能的,因为服务器现在签署了整个握手,包括密码协商。

用简化来改善性能

TLS 1.3是一个更加优雅和安全的协议,删除了上面列出的不安全功能。 这种对冲修剪允许简化协议,使其更容易理解,更快。

在以前版本的TLS中,主要的协商机制是密码组。 密码套件几乎涵盖了可以就连接进行协商的所有内容:

  • 支持的证书类型
  • 用于导出密钥的散列函数(例如,SHA1,SHA256,...)
  • MAC功能(例如,HMAC与SHA1,SHA256,...)
  • 密钥交换算法(例如,RSA,ECDHE,......)
  • 密码(例如,AES,RC4,......)
  • 密码模式(如果适用)(例如,CBC)

先前版本的TLS中的密码套已经发展成为巨大的字母汤。 常用密码套件的示例是:DHE-RC4-MD5或ECDHE-ECDSA-AES-GCM-SHA256。 每个密码套件由一个名为Internet Assigned Numbers Authority(IANA)的组织维护的表中的代码点表示。 每次引入新密码时,都需要将一组新的组合添加到列表中。 这导致代码点的组合爆炸,代表着参数的每一个有效选择。

TLS 1.3删除了许多这些遗留功能,允许在三个正交协商之间进行彻底拆分:

  • 密码+ HKDF哈希
  • 密钥交换
  • 签名算法

这种简化的密码套件协商和从根本上减少的协商参数集开辟了一种新的可能性。 这种可能性使得TLS 1.3握手延迟从两次往返降至仅一次往返,从而提供性能提升,确保TLS 1.3受欢迎并广泛采用。


建立与之前没有见过的服务器的新连接时,需要两次往返才能在连接上发送数据。 这在服务器和客户端在地理位置上彼此靠近的位置并不是特别明显,但是它可以在移动网络上产生很大的差异,其中延迟可以高达200ms,这对人来说是显而易见的。

1-RTT模式

TLS 1.3现在具有更简单的密码协商模型和一组减少的密钥协商选项(没有RSA,没有用户定义的DH参数)。 这意味着每个连接都将使用基于DH的密钥协议,并且服务器支持的参数很容易猜测(ECDHE使用X25519或P-256)。 由于这种有限的选择,客户端可以简单地选择在第一条消息中发送DH密钥共享,而不是等到服务器确认它愿意支持哪些密钥共享。 这样,服务器可以学习共享密钥并提前一次往返发送加密数据。 例如,Chrome的TLS 1.3实现会在第一条消息中向服务器发送X25519密钥共享。

在极少数情况下,服务器不支持客户端发送的密钥共享之一,服务器可以发送新消 HelloRetryRequest,让客户端知道它支持哪些组。 由于列表已被削减太多,预计这种情况不常发生。

0-RTT恢复

QUIC协议启发了进一步的优化。 它允许客户端将第一条消息中的加密数据发送到服务器,与未加密的HTTP相比,不会产生额外的延迟成本。 这是一大进步,一旦TLS 1.3被广泛部署,加密的网络肯定比以前更加快捷。

在TLS 1.2中,有两种方法可以恢复连接,会话ID和会话票证。 在TLS 1.3中,这些被组合以形成称为PSK(预共享密钥)恢复的新模式。 该想法是在建立会话之后,客户端和服务器可以导出称为“恢复主密钥”的共享秘密。 这可以使用id(会话ID样式)存储在服务器上,也可以通过仅为服务器知道的密钥(会话票据样式)加密。 此会话票证将发送到客户端并在恢复连接时进行兑换。

对于恢复的连接,双方共享恢复主密钥,因此除了提供前向保密之外,不需要密钥交换。 下次客户端连接到服务器时,它可以从上一个会话中获取秘密并使用它来加密应用程序数据以及会话票证发送到服务器。

0-RTT数据中没有交互性。 它由客户端发送,并由服务器使用,没有任何交互。 这对性能很有帮助,但需要付出代价:可重复性。 如果攻击者捕获发送到服务器的0-RTT数据包,他们可以重播它,并且服务器有可能接受它为有效。 这会产生有趣的负面后果。

危险重放数据的一个示例是在服务器上更改状态的任何内容。 如果增加计数器,执行数据库事务或执行任何具有永久效果的操作,将其放入0-RTT数据中是有风险的。

作为客户端,您可以尝试通过仅将“安全”请求放入0-RTT数据来防止这种情况。 在此上下文中,“安全”表示请求不会更改服务器状态。 在HTTP中,不同的方法应该具有不同的语义。 HTTP GET请求应该是安全的,因此浏览器通常只能通过在0-RTT中发送GET请求来保护HTTPS服务器免受重放攻击。 由于大多数页面加载以GET“/”开头,因此页面加载时间更快。

当在0-RTT中发送的数据用于状态改变请求时,问题开始发生。 为帮助防止此故障情况,TLS 1.3还包括会话票证中的经过时间值。 如果这种情况发生太大分歧,客户端要么接近光速,要么重播值。 在任何一种情况下,服务器都应该谨慎拒绝0-RTT数据。

可部署性

TLS 1.3与TLS 1.2及更早版本完全不同,但为了广泛部署,它必须向后兼容现有软件。 TLS 1.3从草案到最终发布花了这么长时间的原因之一是,一些现有的软件(即中间盒)与新的更改并没有很好地协调。 即使在线上可见的TLS 1.3协议的微小更改(例如消除冗余的ChangeCipherSpec消息,将版本从0x0303提升到0x0304)最终导致某些人的连接问题。

尽管未来的灵活性已经内置到TLS规范中,但是一些实现对如何处理未来的TLS版本做出了错误的假设。造成这种变化的现象称为骨化, 为了适应这些变化,TLS 1.3被修改为看起来很像TLS 1.2会话恢复(至少在线路上)。 这导致了更多功能性但不太美观的协议,也是您在线升级最广泛部署的协议之一所付出的代价。

结语

TLS 1.3是一种现代安全协议,使用正式分析等现代工具构建,保持其向后兼容性。 它已经过广泛测试,并在使用现实世界部署数据时进行了迭代。 它是一种更清晰,更快速,更安全的协议,可以在线成为事实上的双方加密协议。

发布TLS 1.3是一项巨大的成就。也是近日行业里最好的示例,它证明了通过修改20年前部署的遗留代码来改善人们互联网体验,是一件多么棒的事!TLS 1.3在过去三年中一直处于争论和分析中,现在已准备好迎接它的黄金时段。 欢迎你,RFC 8446!

 

稿源:Cloudflare博客

七月行业新闻回顾

Jesdoit阅读(372)评论(0)

Chrome对所有HTTP网页说“不安全”

在最新发布的Chrome68中,谷歌Chrome浏览器引入了对全网非HTTPS页面的警告。“不安全”标记出现在所有使用HTTP加载的页面的左上角地址栏。

这一举动在今年2月被提出,时至今日才正式被采用。谷歌旨在让HTTPS成为网络的标准并最终希望去除安全指示锁。目前,该警告仍处于最温和的版本。 未来的版本可能包含一个红色警告标志,正如谷歌之前所解释的那样。

在Chrome默认启用警告的那天,安全研究人员Troy Hunt和Scott Helme启动了为什么没有HTTPS? 项目,列出了尚未默认为HTTPS的流行网页,也可以按国家/地区显示它们。 不受HTTPS限制的最受欢迎的页面是中文搜索引擎百度; 列表中最受欢迎的非中文页面是Twitter的URL缩短服务,t.co.

本月短新闻

稿源:FeistyDuck

通往QUIC之路

Jesdoit阅读(323)评论(1)

QUIC(快速UDP互联网连接)协议是一种新的默认加密的互联网通信协议,它提供了许多改进,旨在加速HTTP通信,同时使其变得更加安全,其最终目的是在web上代替TCP和TLS协议。在这篇博客中,我们将对QUIC协议的一些内容进行概述,这些内容包括该协议的一些关键特性以及这些特性会如何使web受益,还包括支持这种激进的新协议过程中遇到的一些挑战。

事实上,有两种协议共用这个名称,一种是“Google QUIC”(简称gQUIC),它是几年前由谷歌公司的工程师设计的原始协议,经过多年的试验,该协议现在已经被IETF(互联网工程任务组)采纳为标准协议。
另一种是“IETF QUIC”(从现在开始叫作“QUIC”),它已经与gQUIC有了很大的不同,以至于它可以被认为是一个单独的协议。从数据包的有线格式,到握手机制和HTTP的映射,通过许多机构和个人的开放的合作,QUIC协议改进了最初的gQUIC设计,实现了让互联网更快、更安全的共同目标。

那么,QUIC带来的改进是什么呢?

内置的安全性(以及性能)

QUIC有一个更彻底的背离现在脆弱的TCP协议的特点,即它所声称的设计目的是提供一个默认安全的传输协议。通过提供一些安全方面的特性,比如身份验证和加密等,QUIC协议自身实现了这一目的。而这些工作通常本应是由更高层次的协议(如TLS协议)来完成的。

最初的QUIC握手机制将TCP协议使用的典型的三次握手方式,与TLS1.3协议的握手机制结合起来,它提供了端点的身份验证以及加密参数的协商等机制。对于那些熟悉TLS协议的人们来说,QUIC用它自己的框架格式代替了TLS协议的记录层,同时保留了与原来相同的TLS握手消息。

这不仅能够确保连接总能实现身份验证和加密,而且,由此使得初始连接的建立速度更快了:相比于TCP和TLS1.3相结合的握手机制需要客户端和服务器之间两次消息往返来说,典型的QUIC握手只需要一次往返就可以完成。

基于TCP+TLS的HTTP请求:

基于QUIC的HTTP请求:

但是QUIC走得更远,它还对额外连接的元数据进行加密,这些元数据可能被一些中间件所利用,从而对连接产生干扰。例如,当连接迁移的漏洞被利用时,路途中的被动攻击者可以利用数据包编号来发现多条网络路径上的用户活动之间的联系(详见下文)。通过加密数据包编号,QUIC可以确保,除了通信连接的端点之外,没有任何实体能够使用数据包编号来发现用户活动之间的联系。

加密也可以是一种有效的避免僵化的补救措施。所谓僵化是指,由于在部署时作出了错误的假设,导致某种协议原本内置的调节机制(例如,原本该协议与其自身的几个版本之间都可以进行协商)实际上无法奏效(僵化正是这么长时间以来TLS1.3的部署仍然被拖延的原因,TLS1.3旨在防止僵化的中间件错误地阻止该协议的修正,而只有当该协议做出几项重要变更后,才可能被广泛部署)。

队首阻塞

HTTP/2所带来的主要改进之一是,它能够将不同的HTTP请求多路传输到同一个TCP连接上。这使得HTTP/2应用程序能够并发地处理请求,并更好地利用它们可用的网络带宽。

这比原来的情况有了很大的改进,当时的要求是,如果应用程序想要并发地处理多个HTTP/1.1请求(例如,当浏览器需要同时获取CSS和Javascript资源以呈现web页面时),就需要初始化多个TCP+TLS连接。创建新的连接需要多次重复最初的握手,同时还要经历最初的拥塞窗口缓慢增大的过程,这意味着web页面的呈现速度被减慢了。多路复用HTTP交换则避免了所有这些问题。

然而,这有一个缺点:由于多个请求/响应通过同一个TCP连接传输,它们都同样受到数据包丢失(例如,由于网络拥塞所造成的)的影响,即使丢失的数据只涉及单个请求。这被称为“队首阻塞”。

QUIC走得更远一些,它为多路复用提供一流的支持,这样,不同的HTTP流反过来可以映射到不同的QUIC通信流,然而,尽管它们仍然共享同一QUIC连接因而不需要额外的握手,而且拥塞状态也是共享的,但QUIC流的传输却是独立的,因此在大多数情况下,数据包丢失只影响一个通信流,而不会影响其他人。

这可以极大地减少所需的时间,例如,呈现完整的web页面(带有CSS、Javascript、图片以及其它类型的资源)的时间,特别是在通信需要跨越高度拥挤的网络并伴随着很高的丢包率的情况下。

真的就那么简单?

为了实现它的承诺,QUIC协议需要打破许多网络应用程序认为理所当然的一些假设,这可能会使QUIC的实现和部署变得更加困难。

QUIC被设计为在UDP数据报的顶端进行传输,这样可以简化部署,并避免来自网络设备的一些问题(一些网络设备会自动丢弃来自未知协议的数据包),这是因为大多数设备已经支持UDP协议。这也使得QUIC可以在用户那一端进行部署,例如,浏览器将能够实现新的协议功能,并将它们发送给用户,而不必等待操作系统的更新。

然而,尽管目标是避免连接受损,但它也给防范入侵以及如何正确地将数据包路由到正确的端点带来了更多的挑战。

一个NAT把它们都带了出来,然后在暗中把它们捆绑起来

典型的NAT路由器能够对通过自身的TCP连接进行追踪,这可以使用传统的四元组(源IP地址、源端口、目标IP地址、目标端口)来实现,而通过观察在网络中传输的TCP数据包中的SYN、ACK和FIN标记位,这些路由器可以检测到新连接的建立和终止。这使得它们能够精确地管理NAT绑定的生命周期、内部IP地址和端口之间的联系以及外部IP地址。

而对于QUIC来说,这现在还是不可能的,因为目前部署在外部网络的NAT路由器还并不了解QUIC,所以它们通常会退回到默认的和不太精确的UDP流处理机制,这通常涉及到使用任意长度(有时非常短)的超时,而这可能会影响那些长时间运行的连接。

当一个NAT重新绑定发生时(例如由于超时),位于NAT边界之外的通信端点会看到来自另一个源端口的数据包,该端口与连接最初建立时被观察到的源端口并不相同,这样,就不可能通过使用传统的四元组来追踪连接。

而且不仅仅是NAT!QUIC想要带来的特性之一是“连接迁移”,它将允许QUIC端点将连接任意地迁移到不同的IP地址和网络路径。例如,当一个已知的WiFi网络变得可用时(比如,当用户进入他们最喜欢的咖啡厅时),移动客户端将能够在蜂窝数据网络和WiFi网络之间迁移QUIC连接。

QUIC试图通过引入连接ID的概念来解决这个问题,连接ID是指,一个由QUIC数据包携带的,任意的,不透明的,可变长度的blob对象,它可以用来标识网络连接。终端可以使用这个ID来追踪它们所负责的连接,而不需要检查四元组(实际上,可能会有多个ID来标识相同的连接,例如,可以用来避免在连接迁移时连接到不同的路径,但这种行为是由终端而不是中间件来控制的)。

然而,这也给使用任意播寻址方式和ECMP路由的网络运营商带来了问题,在ECMP路由中,单个目标IP地址可能会指向数百台甚至数千台服务器。因为这些网络所使用的边缘路由器也还不知道如何处理QUIC通信,可能会发生这样的情况,属于同一QUIC连接(这指的是具有同一连接ID的QUIC连接)但却具有不同的四元组(这是由于NAT重新绑定或连接迁移所造成的)的UDP数据包可能会被路由到不同的服务器,从而最终导致连接断开。

为了解决这个问题,网络运营商可能需要使用更加智能的第四层负载均衡解决方案,这种解决方案可以在软件中实现,并且在不需要接触边缘路由器的情况下部署(例如,Facebook的Katran项目)。

QPACK

HTTP/2所带来的另一个好处就是头部压缩(或叫作HPACK),它使得HTTP/2端点可以通过删除HTTP请求和响应的冗余来减少通过网络传输的数据量。

特别是,相比其他各项技术,HPACK所使用的充满了从此前的HTTP请求(或响应)发送(或接收)的报头的动态表,使得端点可以在新的请求(或响应)中引用以前遇到过的头部信息,而不必再一次传输它们。

HPACK的动态表需要在编码器(发送HTTP请求或响应的一方)和解码器(接收它们的一方)之间进行同步,否则解码器将无法解码它接收到的内容。

基于TCP的HTTP/2的这种同步是透明的,因为传输层(TCP)负责以与报文被发送到该层时相同的顺序来传输HTTP请求和响应,对表进行更新的指令可以直接作为请求(或响应)本身的一部分,由解码器进行发送,这使编码变得非常简单。但对于QUIC来说,情况则更为复杂。

QUIC可以在不同的流中独立地传递多个HTTP请求(或响应),这意味着,虽然对于单个流而言,它可以按顺序传输数据,但在多个流当中,却无法保证正确的传输顺序。

例如,如果一个客户端在QUIC流A中发送HTTP请求A,然后在QUIC流B中发送请求B,那么,由于在网络中数据包会重新排序或丢失,因此可能会发生服务器在收到请求A之前就收到请求B的情况,而如果请求B被编码了因而需要参考请求A的头部信息,那么由于服务器还未收到请求A,它将无法解码请求B。

在gQUIC协议中,这个问题通过在gQUIC流中简单地对所有HTTP请求和响应的头部(而不是主体)进行序列化而得到了解决,这意味着无论如何都要按顺序传输头部。这是一个非常简单的方案,它使得程序可以重复使用大量现有的HTTP/2代码,但另一方面,它也增加了队首阻塞的情况,而这本来是QUIC设计时想要减少的。因此,IETF QUIC工作组设计了一个在HTTP和QUIC(“HTTP/QUIC”)之间的新映射关系,同时还设计出一个名为“QPACK”的新头部压缩方案。

在最新的HTTP/QUIC映射和QPACK规范草案中,每个HTTP请求/响应交换都使用它自己的双向QUIC流,因此就没有队首阻塞的情况。此外,为了支持QPACK,每个对等节点会创建两个额外的单向QUIC流,一个用于向另一个对等节点发送QPACK表更新,而另一个则用于确认另一方收到的更新。通过这种方式,一个QPACK编码器只能在被解码器明确地承认后才能使用动态表引用。

使反射攻击偏转方向

在基于UDP的一些协议中,一个常见的问题是,它们容易受到反射攻击。这种攻击是这样进行的,为了对目标主机进行攻击,攻击者假冒发往服务器的数据包的源IP地址,使得这些数据包看起来像是由目标主机发过来的,从而欺骗了服务器,这样,服务器就会误认为目标主机请求了大量数据,于是就会将这些数据发送过去。

当服务器发出的响应比它接收到的请求更大时,这种攻击可能是非常有效的,在这种情况下,我们讨论的是“放大”。

这种攻击通常不使用TCP连接,因为在握手过程中传输的初始数据包(SYN、SYN+ACK、……)具有相同的长度,因此它们不会有任何被放大的可能。

QUIC的握手方式则是非常不对称的:就像对于TLS一样,在它的第一次旅程中,QUIC服务器通常会发送自己的证书链,它可能非常大,而客户端则只需要发送几个字节(将TLS的客户端问候消息嵌入到QUIC包中)。基于这个原因,客户端发送的初始QUIC包必须被填充到特定的最小长度(即使包的实际内容要小得多)。然而,这种缓和措施仍然是不够的,因为典型的服务器响应会跨越多个数据包,因此仍然比填充的客户端数据包大得多。

QUIC协议还定义了一个显式的源地址验证机制,在这种机制中,服务器只发送一个小得多的“重试”数据包,而不会发送较长的响应。这个小的数据包包含一个唯一的加密令牌,然后,客户端将必须在一个新的初始数据包中对服务器进行响应。通过这种方式,服务器将会更加信任客户端,相信客户端并未使用假冒的源IP地址(这是因为客户端收到了重试数据包),这样就可以完成握手了。这种缓和措施的缺点是,它增加了最初的握手时间,从一次往返变成了两次往返。

另一种可选的解决方案是,减少服务器的响应,使得反射攻击变得不那么高效,例如,使用ECDSA证书(这种证书通常比使用RSA算法的证书要小得多)。我们也一直在试验一种使用现成的压缩算法(如zlib和brotli)来压缩TLS证书的机制,这种机制最初是由gQUIC引入的一种功能,但目前还没有在TLS中使用。

UDP的性能

QUIC的一个反复出现的问题在于,部署在外部网络的现有硬件和软件无法理解它。我们已经研究了QUIC如何试图解决像路由器这样的网络中间件的问题,但是,另一个潜在的问题是,在QUIC端点上使用UDP协议发送和接收数据的性能如何。多年以来,人们做了很多工作来尽可能地优化TCP应用,包括在软件(如操作系统)和硬件(如网络接口)上建立卸载功能,但是目前UDP协议还不支持这些功能。

然而,QUIC应用可以使用这些功能将只是个时间问题。例如,最近人们致力于在Linux系统中为UDP协议实现通用分段卸载(Generic Segmentation Offloading)功能,这将使应用程序可以在用户空间和内核空间的网络协议栈之间以一个UDP段(或非常接近)的开销捆绑传输多个UDP段,以及为Linux加入零复制套接字支持的UDP段,这可以使应用程序免去从用户空间向内核空间复制信息的开销。

结语

与HTTP/2和TLS1.3一样,QUIC将提供许多新的特性,以提高web站点的性能和安全性,它也会提供许多其它的基于互联网的属性。IETF工作组计划于今年年底前交付QUIC规范的第一个版本,让我们拭目以待!

稿源:Cloudflare blog

Apple将于7月20日停止信任非CT登录的SSL / TLS证书

Jesdoit阅读(317)评论(0)

该公告是苹果公司赛门铁克CA不信任计划的补充

苹果公司已经明确了赛门铁克CA不信任计划,其中有即将到来的7月20日的最后期限。 2016年6月1日至2017年12月1日期间签发的任何Symantec CA SSL证书如果未发布到证书透明度日志,将不受信任。

这仅适用于Symantec CA证书,对于SSL / TLS生态系统的其余部分,Apple的CT截止日期仍为10月15日。除了浏览器中的Web内容之外,该要求不会影响SSL / TLS用例。 受影响的申请将包括:

  • macOS High Sierra
  • macOS应用程序
  • iOS 11
  • iOS应用
  • Safari浏览器

这不太可能产生重大影响,因为不信任将主要影响已经被谷歌Chrome浏览器和Mozilla Firefox处罚的证书。 此外,赛门铁克此前与谷歌的混战之后,已经要求记录它发布的证书了。

尽管如此,网站所有者仍希望仔细检查他们的Symantec CA SSL证书,以免他们被四大网络浏览器之一取消信任。

如何判断我的SSL证书是否已经过CT记录?

证书透明度是一个行业的事情,最终用户无需做任何事情来记录自己的证书。 CA必须这样做。 但是,有两种方法可以检查并查看是否已记录您颁发的SSL证书。 第一种方法是检查浏览器中的证书详细信息。

  1. 访问你的网站
  2. 单击浏览器地址栏中的挂锁图标
  3. 查找可以查看证书或证书详细信息的位置
  4. 查找字符串:'1.3.6.1.4.1.11129.2.4.2'

如果找到它,则表示您的证书已被记录。 所有CT记录的证书的OID都相同。 现在,浏览器以不同的方式显示此信息。 例如,Safari将其显示为:

Firefox将其称为对象标识符。

Google会让您浏览其菜单,从“更多工具”部分选择开发人员工具,然后导航到安全性,您可以通过单击“主要来源”查看证书详细信息。

如果您正在使用Microsoft Edge,或者只是不想在浏览器中点击,还有另一种方法可以检查。 您还可以使用Symantec的CryptoReport:

转到Symantec CryptoReport。
输入您的网址。
检查:“Certificate Transparency: Embedded in certificate”(证书透明度:嵌入证书)
如果该行存在,则说明已录入CT!

如果不是,并且您使用的是2016年6月1日至2017年12月1日期间颁发的Symantec CA品牌SSL证书,则需要立即重新颁发或更换您的SSL证书。 您的替代品将来自DigiCert,后者现已收购赛门铁克CA,并在过去9个月中一直在努力更换数百万受影响的证书。

稿源:The ssl store

什么?你的私钥泄漏了?

Jesdoit阅读(311)评论(0)

代码签名是一种当代标准做法,其中软件开发人员通过可信证书颁发机构的验证,并接收可用于签署脚本和可执行文件的证书和私钥。

几乎每个设备,操作系统和网络浏览器都经过硬编码,以尽可能少地信任各种来源。 这完全是以安全的名义完成的。 当您编写一个软件并将其上传到互联网而不签名时,会在浏览器中触发任何试图下载该软件的警告。 警告将说明此下载源自未知来源,其内容无法信任。

当您对一个软件进行代码签名时,您正在做的是使用与您的代码签名证书关联的私钥添加数字签名。 浏览器本身并不信任您,但如果他们可以将您的数字签名链接回受信任的根,即来自其中一个受信任的CA的证书,它会信任您,因为CA通过向您颁发证书为你担保。

简而言之,当您正确签署某些内容时,浏览器可以将其追溯到它信任的证书,这会依次授予您信任。

代码签名无处不在, 您需要它来在Apple和Android的应用商店中获取应用程序,您需要它来让所有主流浏览器下载您的软件。 为了使这种做法尽可能安全,在发布之前有一个验证过程,旨在清除不好的井和网络犯罪分子。

一般来说,证书颁发机构和数字证书行业最常见的一种做法是“永远不要让你的私钥发生任何事情。”然而百密总有一疏,当你的私钥真的被公开了,一切就没有想象的那么简单了。

研究人员发现了一对恶意软件家族,这些恶意软件家族使用来自台湾科技公司的妥协证书进行了数字签名,其中包括生产网络设备的跨国公司D-Link。

这些网络犯罪分子如何能够破坏私钥尚不得而知。 众所周知,他们用密钥签署了恶意软件。

当私钥被泄露并且数字签名被应用于恶意软件时,它会欺骗通常扫描下载的浏览器过滤器和防病毒程序。 比方说,让浏览器认为它来自D-Link,而不是看到这个脚本或可执行文件来自未知来源,并且浏览器允许下载开始。 这是一种非常有效的攻击媒介。

正如黑客新闻所解释的那样,两个恶意软件与受损密钥签署:

ESET的安全研究人员最近确定了两个恶意软件系列,这些恶意软件系列之前与网络间谍组BlackTech有关,这些恶意软件系列是使用属于D-Link网络设备制造商的有效数字证书和另一家名为Changing Information Technology的台湾安全公司签署的。

第一个恶意软件称为Plead。 日本计算机安全事件响应小组(CSIRT)JPCERT在6月对Plead进行了全面分析。 它本质上是一个后门,可用于窃取信息和监视人。 第二个恶意软件是一个相关的密码窃取程序,其目标是:

  • Google Chrome
  • Microsoft Internet Explorer
  • Microsoft Outlook
  • Mozilla Firefox

D-Link和变更信息技术已收到通知,并且已于7月4日撤销了证书。

BlackTech将继续使用已撤销的证书来签署恶意软件。 这可能听起来很愚蠢,但是这个问题在许多不同的防病毒解决方案的漏洞中都有所启发:它们不会扫描代码签名证书的有效性。

应该发生的情况,如图中所示,是防病毒程序会看到签署代码的证书被撤销,并通知用户或阻止下载。 即使恶意软件被加上时间戳,仍然应该提前通知证书已被撤销。 相反,许多防病毒程序根本不检查有效性,这意味着过期或受损的证书仍可构成相当大的威胁。

这甚至不是台湾科技公司第一次成为受害者。2010年的时候Stuxnet蠕虫就使用了从RealTek和JMicron盗取的证书签名。

那么如何预防私钥泄密呢?

密钥泄露可能会导致一连串的问题,无论是SSL证书,代码签名,个人身份验证 - 都可能带来灾难性的影响。 希望那些获得签名的恶意软件族最终不会导致大问题,但签署恶意软件始终是一个危险的主张。

因此,我们整理了以下建议:

将您的私钥存储在外部硬件令牌上

外部硬件TokenRight现在将密钥存储在物理硬件令牌上的想法在很大程度上被加密货币行业所采用,后者将其称为硬件钱包。在某种程度上,加密货币行业对于各种私钥存储来说都是一个有趣的测试案例,因为他就像是淘金者的平台,络绎不绝的黑客和各路人马是验证加密的最佳地点。

加密货币社区(不同于加密社区)推动了一系列关键存储解决方案,从层压纸钱包到将物理比特币侧面雕刻到“尖端”冷藏解决方案,这些花式加密价格极高,早已不是什么新奇玩意儿。

最好的方法从来都是把密钥保存在线下,不给他人任何机会获取。如果D-link和Changing Information Technology早就这么做了,要搞到他们的私钥就要牵涉到刑事案件了,哪个黑客还有空玩儿这个呢?

稿源:The ssl store

六月行业新闻回顾

Jesdoit阅读(422)评论(0)

TLS是否必须不断修改以使其面向未来?

TLS 1.3标准即将完成,但这一切得来不易。那些使用着旧版TLS的设备始终是标准化过程的一大挑战。尽管这使得协议变得莫名的复杂,但同时也更易于人们部署。为了让TLS能够适应各种设备,唯一的办法就是不断改变。

常见的问题有,版本不兼容:接收TLS 1.3连接的设备不会降级到较低版本。为了避免这些问题,版本协商转移到了扩展中,并引入了由Google的David Benjamin发明的GREASE机制。 TLS 1.3实现可以发送一组服务器要忽略的伪版本号。 同样的机制也可以用于其他领域,如密码套件。

但是版本协商并不是唯一的问题:中间件会假定TLS包将遵循他们在TLS 1.2中使用的格式,并且如果它们没有,则会断开连接。 通过让TLS 1.3看起来更像1.2,许多这些问题都可以得到解决。

预防类似的问题并不是件容易的事,硬件开发商常常对TLS协议不甚了解。David Benjamin提出了一个听起来很极端的办法,在正规版本的TLS1.3之外允许一些临时修改版的存在。这些修改版本每几周就会变化一次,一些服务器和浏览器可以在短时间内提供支持。

鉴于Chrome和谷歌自有服务的市场份额很大,任何人都不可能部署破坏它们之间连接的设备。 如果浏览器和网页无法就临时TLS版本达成一致也没有问题:它们总是可以回退到标准化的TLS 1.3(至少如果能使双方都正确地实现版本协商,就是值得去尝试的努力)。

本月短新闻

稿源:The Feisty Duck

PCI合规截止日期:你必须在6月30日之前禁用TLS 1.0

Jesdoit阅读(531)评论(0)


你有电子商务网站吗?你接受在线支付吗?你担心会受到处罚吗?如果所有三个问题的答案都是'是',那么您应该立即禁用TLS 1.0。思考它的时间已经过去了。你只有几天!

支付卡行业安全标准委员会(PCI SSC)是由美国运通,Discover金融服务,JCB国际,万事达卡和Visa Inc.于2006年组成的独立机构。该机构的成立旨在保护持卡人的数据,并规定了十二所有接受在线支付的供应商的主要要求。虽然这些要求不是任何法律的一部分,但他们的支付卡公司已经强制接受信用卡支付的商家。如果商家不符合规定,他们可能面临每月高达10万美元的罚款。

2015年4月发布的PCI DSS v3.1将2016年6月的最后期限从SSL和早期TLS迁移到更新,更安全的版本。这里,“从SSL和早期TLS迁移”意味着禁用对旧版SSL和TLS版本的支持。最终,截止日期延长了两年,并于2018年6月30日成为新的最后期限。

2016年4月发布的PCI DSS v3.2也包括此截止日期。

安全套接字层(SSL),原始密码协议在1999年发布了其最新版本(SSL 3.0)。由于SSL版本中存在漏洞,SSL很快被TLS取代。 自那以后,包括TLS 1.0在内已发布了四个版本。

早期版本的SSL和TLS已经被发现容易受到诸如Heartbleed,POODLE,BEAST,CRIME和Bleichenbacher等漏洞的影响 - 这包括TLS 1.0。这样的机会之窗吸引了黑客拦截并篡改客户的敏感信用卡数据 - 以技术术语来说是一种中间人攻击。

当然,搞一套中间人攻击不是什么容易的事,但它发生的可能性对涉及在线支付的电商类网站却是致命的。

你或许会问,为什么我们不直接把那些带漏洞的协议给禁了呢? 因为没有任何一个机构可以禁用整个互联网的旧SSL/TLS版本,它必须由服务器管理员在服务器上完成。

许多网站仍旧在不支持最新TLS版本的旧服务器上运行。 例如,Windows Server 2008不支持TLS 1.1,1.2和1.3。 这些网站的管理员需要尽快行动并迁移到较新的服务器。 即使您已经迁移到较新的服务器或者已经拥有一台服务器,您仍然没有完成。 您还需要禁用对SSL /早期TLS的支持。

哪些SSL / TLS版本应该被禁用?

这是来自PCI SSC的文件所说的关于SSL / TLS版本被禁用的内容:

POI可以继续使用SSL /早期TLS,但仅在它可以显示POI不容易受到当前已知的漏洞攻击时。 但是,SSL是一种过时的技术,将来可能会面临额外的安全漏洞; 因此强烈建议POI环境尽可能使用TLS v1.1或更高版本。 POI的新实现应该强烈考虑支持和使用TLS 1.2或更高版本。 如果环境中不需要SSL /早期TLS,则应禁用对这些版本的使用和降级。

TLS 1.2 / 1.1不是已经被用作默认了吗?

大多数情况下,是这样没错。

但就像某些高校还用着被微软弃疗的Win XP一样,新版本的TLS根本就无法在这些旧系统上兼容。 如果您在服务器上打开了较旧的TLS版本,则会建立连接。 这将违反PCI DSS的要求,您可能会受到严厉处罚。

网站管理员需要抓紧时间了!离2018年6月30日还有三天,你准备好了吗?

稿源: The ssl store

新的运行加密解决方案出现 以填补“加密差距”

Jesdoit阅读(344)评论(0)

新兴硬件和软件的实时加密方案将填补“加密差距”

几年前,在“Blockchain”和“Quantum”成为商业上最受欢迎的流行语之前,云端风靡一时。 今天我们已经过了炒作的时候,云早已无处不在。 虽然传统观点认为您应该在客户端运行应用程序,并且仅将云用于存储,但现在基于云的应用程序变得越来越流行,老观念变得过时。

要使基于云的应用程序能够工作,必须能够以明文形式读取数据。 这代表了加密差距。 传统上,您可以在客户端运行应用程序,至少可以让您对其安全性有一定程度的控制。 但是对于基于云的应用程序,如果攻击者或流氓员工可以访问应用程序的环境,则可以读取数据。 如果您还记得最近的Spectre和Meltdown漏洞 - 它们都利用了类似的攻击媒介。

在硬件和软件方面解决这些差距已经做了很多工作。 到目前为止,谷歌,微软和IBM在不同的完成阶段都有实时加密解决方案,一些初创公司也在努力在更具体的范围内解决这个问题。

硬件方面:Secure Enclaves

Secure Enclaves应用最广泛的例子还属苹果公司在其移动设备上的使用。作为ARM CPU的协处理器,负责存储重要的身份验证和付款信息。最重要的是,即使iOS内核被黑客入侵,它仍然是安全的。

Fortanix联合创始人兼首席执行官Ambuj Kumar表示:“Enclave并不使用于操作系统。无论你是在操作系统里找到个0日bug,还是恶意软件,又或者是黑客攻击进入所有内存,enclave都不会受到影响。因为它嵌入在CPU中。”

使用Secure Enclaves,加密数据会进入解密和处理区域,然后在呈现时再次加密。一切都发生在硬件,尤其是芯片,因此与基于软件的加密相比,加密速度更快、更可靠。

此外,还有其他针对促进云计算的芯片的解决方案。英特尔称其解决方案为“Software Guardian Extensions”或“Intel SGX”。ARM的TrustZone和AMD的Secure Execution Environment安全执行环境。

但Secure Enclaves仍存在一些缺点。 首先,Secure Enclaves的空间有限,所以处理延迟的可能性很大。 此外,并非每个Secure Enclave都与各种环境兼容。 这种技术形式仍处于早期阶段,多方争夺霸权。 领导者出现可能需要一点时间,然后大多数其他平台会适应。

还有一些研究发现,使用英特尔SGX可以发现类幽灵攻击,可以使Enclaves中的未加密数据可读。 因而产品还未达完满,未来可期。

软件方面:同态加密

大多数基于软件的解决方案的目标是尽可能多地完成工作,而无需解密任何内容。一种方法是使用同态加密。使用同态加密允许在不解密数据的情况下进行计算和搜索。缺点是它以牺牲速度为代价。

就互联网时代而言,同态加密实际上是非常古老的,可以一直追溯到1978年。它之所以复苏是因为一些安全专家看到了保护云应用程序的用例。2009年,IBM的Craig Gentry创建了第一个完全同态加密方案。在此之前,任何人都可以做的最好做法是创建部分同态方案,允许有限的加密数据计算。

Gentry称这种新系统是“用于处理有毒化学物质的手套箱中的一个......所有的操作都发生在箱子内部,化学物质不会暴露在外界。“

使用同态加密,系统将在加密数据时计算和处理数据,然后回传加密的答案。 当Gentry创建他的同态加密方案时,他预测这将是实用前的另一个十年。 这是因为这个过程实际上比使用未加密数据的过程慢100万倍。 虽然有人正在努力解决这个问题,但对于大多数公司来说,这仍然是一大障碍。

尽管如此,有一家公司Enveil声称已经找到了一种方法来使同态加密足够快,以供实际使用。 在联邦政府取得突破后,Enveil首席执行官Ellison Anne Williams 表示,一种可行的同态选择应该很快就会上市。

“我们真的带来了实用的同态加密。 而且我们可以轻松地与所有类型的应用程序即插即用,因此您不必更改用户体验,或者存储数据的方式,甚至不需要对数据进行加密。“

软件方面:多方计算

多方计算不是一次性在一台服务器上进行计算,而是将工作分解到多台服务器上。 没有一台服务器曾经同时拥有所有的加密数据。 至少在表面上,这与比特币矿工群体没有太大区别,他们集中资源去尝试和解决问题。

多方计算也不是新的。 它于1982年首次作为双方计算引入,并于1986年进行扩展。计算基于所有输入的秘密共享以及零知识证明,以帮助防止恶意活动。 这个想法是,只要有足够的“诚实的玩家”,任何恶意行为者的不良行为都会很快被发现并消除。

多方计算有两个特性:

  • 输入隐私:在协议执行期间发送的消息中不能推断出各方持有的私人数据。 唯一可以推断出私人数据的信息是通过单独查看函数的输出可以推断出的任何信息。
  • 正确性:在协议执行期间,任何愿意共享信息或偏离指令的敌对勾结方的任何适当子集都不应该强制诚实方输出不正确的结果。 这个正确性目标有两种形式:诚实的各方保证计算正确的输出(一种“健壮的”协议),或者如果他们发现错误(MPC协议“中止”),则中止。

多方计算比同态加密要快得多,但由于需要额外的通信,所以仍然比基于硬件的解决方案慢。

基于软件的加密解决方案的缺陷

对于初学者来说,基于软件的解决方案,同态加密和多方计算,在实施之前可能需要新的应用程序逻辑。 这些还不是全面解决方案,主要是因为这是一个相当新的行业。 有时这些解决方案可能会破坏应用程序或功能性。 并非每个程序都可以轻松转换为进行这类计算。 例如,如果应用程序从数据库中提取数据,然后使用自己的内部逻辑处理数据,那么将其转换为任一解决方案将很困难。

正如Unbound Tech的创始人Nigel Smart所言:

“世界上的所有技术都不会采用C程序,而只是运行它。 它需要被转换为密码协议。“

因此,许多位于这个领域的初创公司都专注于特定用例,提供位于用户应用程序和数据库之间的产品。 到目前为止,初创公司已经推出了一系列专门的产品,例如基于软件的密钥管理器和用于保护数据库访问的解决方案。

还有一些关于谁最适合提供实时加密的讨论。 它应该是网络安全厂商提供的产品,还是应该成为大型云平台提供的功能?

围绕实时加密存在很多不确定性,许多IT专业人员会争论有更多需要担心的问题。尽管如此,这些产品在未来几年应该会有很大的发展。 他们值得关注。

 

稿源:The ssl store