关注网络安全
和行业未来

通往QUIC之路

Jesdoit阅读(737)评论(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阅读(525)评论(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阅读(601)评论(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阅读(672)评论(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阅读(854)评论(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阅读(512)评论(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

DigiCert宣布退出CA安全委员会

Jesdoit阅读(706)评论(0)

本月15日,DigiCert官方博客发布一则Diss CA安全委员会的声明,并义正言辞地表示了退出安全委员会的意愿。原文翻译如下:

鉴于CA安全委员会(CASC)正朝着DigiCert不支持的方向发展,我司正在考虑退出CASC。

  • 我们认为CASC不够透明,无法代表当代认证机构行业的多样性。改善生态系统需要所有感兴趣的利益相关者的广泛参与,却有许多人被不必要地排除在外。
  • 同时我们认为CASC近日对网络钓鱼的过分关注是不合时宜的。我们更渴望CASC关注CA行业现今遇到的诸多调整和机遇。
  • 尽管DigiCert支持EV证书并十分坚信CA提供的身份验证价值,我们认为安全性是一个不断变化的趋势,并希望以有意义的方式改进EV证书。我们相信EV证书可以得到显着加强而不会对合法企业获得EV证书的能力产生负面影响。我们将通过开放和有力的讨论以及我们对CA / B论坛验证工作组的持续贡献进行改进。

什么是CA安全委员会?

创建CASC是为了允许证书颁发机构就数字证书的安全性和最佳实践展开协作。这项工作无法在CA / Browser(CA / B)论坛内完成,因为:

  • CA / B论坛是一个行业标准组织,这意味着教育和研究超出了范围。
  • 标准必须着重于最低可接受的做法,而不是最佳做法和创新。
  • 大型CA希望迅速提高安全状态。
  • CASC提供了共同资助行业改进工作的机会。

其目的是利用CASC的资源来推动CA / B论坛最终可能采用的创新。 CASC成立的目的是为CA业界提供一个统一的解决方案,以应对少数CA的不良做法,并提高社区对领先企业的期望。

多年来,CASC:

  1. 已发布的博客帮助教育读者了解各种安全主题。
  2. 为CASC建立了一个身份。
  3. 维护一个信息丰富的网站,被那些对CA运营和最佳实践感兴趣的人用作资源。
  4. 致力于支持KeyGen功能的新技术解决方案,尽管浏览器不推荐使用该功能。

我们认识到这些成就和未来,尽管我们已经退出了CASC,但我们希望继续与社区合作,并且我们有兴趣改进PKI,我们相信这是一个光明的未来。 我们期待全球性的参与,以使CA运营变得透明并解决许多持续出现的行业问题。 我们计划直接通过CA / B论坛和Mozilla开发者政策邮件列表介绍建议的改进措施,并单方面自行实施这些改进措施,给我们客户的带来好处和便利。

DigiCert不玩儿了,CASC还能撑多久?你怎么看?

 

稿源:DigiCert

苹果公司在WWDC大会中宣布证书透明度要求

Jesdoit阅读(669)评论(0)

在近日举行的WWDC大会上,苹果宣布将要求在2018年10月15日之后颁发的所有SSL / TLS证书加入证书透明度(CT)。

证书透明度是SSL生态系统的最新成员,2013年首次推出,通过公开记录SSL证书提供了透明度。这使得审计人员可以更加可靠地查看证书颁发机构正在发布的内容,并提高Web PKI系统中的公共信任和安全性。

苹果的新政策适用于整个macOS和iOS平台,而不仅仅是浏览器。这意味着除了Safari之外,还将在SSL证书用于保护连接的所有其他环境(如应用程序中)中检查CT列表。

证书透明系统由谷歌开发,并于今年4月起在Chrome浏览器中正式要求所有证书使用CT。

未记录的证书将不被信任,并且将被视为与过期或自签名证书类似,其中浏览器/应用程序将显示错误并拒绝建立连接。对于有效期更长的证书,可同时在至少两个CT记录中登记且兼容。

证书颁发机构负责处理客户端证书的日志记录,并且通常会将一种名为“SCT”的数据嵌入到证书中,作为已登录的证据 - 大多数情况下,所有这些都由供应商透明地处理,并且不会增加额外的负担到您的证书供应过程。

对于2018年10月15日之前颁发的证书,苹果将不会严格要求加入CT。他们的声明还包括将在其平台上受信任的CT日志列表,这些列表已从Chrome受信任的列表中借用。 Firefox之前宣布他们有意支持证书透明度,但没有公布任何公布日期。 在浏览器中要求CT可以确保用户被日志记录下的客户端利用,从而增强终端用户的安全性。

稿源:Digicert

五月行业新闻回顾

Jesdoit阅读(670)评论(0)

云提供商停止使用域名前端技术

著名云供应商谷歌和亚马逊已经停止使用域名前端技术,该技术被加密的信使和隐私工具用于规避某些国家的网络封锁。

从技术上讲,域前端是基于以下事实:在HTTPS连接中,目标主机的主机名以两种方式传输:(1)作为TLS协议中的服务器名称指示(SNI)扩展的一部分,以及(2)作为 底层HTTP连接中的“主机”标头。 在许多实现中,只有HTTP部分对于转发流量非常重要,而外部流量观察者只能看到TLS连接中的SNI字段。

因此,域名前端技术的特点是发送一个连接,其中SNI部分是不同的主机名,而只有HTTP头包含正在使用的服务的实际目标主机名。从网络观察者的角度来看,这些连接无法确定,因而阻止特定服务非常困难,且阻止与云提供商的所有连接也会影响到其他连接。

Tor的开发人员首先注意到,域名前端不再适用于Google App Engine。后来在The Verge的一篇文章中报道了这一点。此后不久,Signal的开发人员收到来自AWS的通知,警告他们不允许他们使用亚马逊所拥有的域名进行连接,这有效地表明他们将无法使用AWS的域名前端。 Tor项目发布的一篇博客文章指出,微软Azure仍然有可能实现域名前端,但它也提到有传言说这个选项最终也会被关闭。

这一突如其来的举动可能和俄罗斯政府尝试禁止电报加密的信使有关。在试图阻止电报的同时,俄罗斯还禁止了用户对各大云供应商的访问。

短新闻

稿源:feisty duck

谷歌将在今年9月取消“安全”标识

Jesdoit阅读(1209)评论(1)

最后甚至会从Chrome的UI中取消挂锁图标。。。

谷歌爸爸在上周四的博文中提到,他们将在今年9月发布的Chrome 69版本中移除“安全”标识。这么做的目的是为了进一步推进全网加密。

自从我们在Chrome中引入安全标识,网络上的HTTPS使用情况变得十分显著。既然那么顺,我们决定顺水推舟移除这个标识。因为用户的体验应当建立于网络默认情况下是安全的,而在出现问题时才会被警告。鉴于我们马上要着手标记所有HTTP网页为“不安全”,我们将逐步移除Chrome的积极安全标识,以便默认未被标记的网站才是安全的。这个计划预计从今年9月的Chrone 69开始执行。

尽管Chrome的“安全”标识UI总被人津津乐道,这其实并不是一个很好的点子。毕竟这年头霸屏使用的HTTPS的网站里,有很多是钓鱼网站。明明是钓鱼网站,却偏偏因为用了HTTPS而被标记成了安全,显然是不合理的。现在谷歌提出的作法,或许能改善如今的局面。所以新的UI会长这样:

在目前的最新版本,即Chrome 67中,谷歌已将协议头https省略了。更进一步,将仅留下挂锁。最后完全取消所有标识。

负责Chrome安全的谷歌产品经理Emily Schecter在近日发布了个keynote解释为什么谷歌决定不再显示协议、进一步简化地址栏的UI的原因。

此外,从Chrome 70开始(今年10月发布),谷歌将进一步丧心病狂地加强“不安全”标识的显示和波及范围。比方说,你在HTTP页面里连字都打不了。

这个新的UI意味着EV证书会成为所有SSL证书中唯一一个带皇冠会员特殊标记特权的。而许多非CAB论坛的会员,早在N年前就讨论着要把EV证书的标识给做掉了。

世事难料,对谷歌的这一决定,您怎么看?

 

稿源: The ssl store