关注网络安全
和行业未来

苹果WWDC大会SSL相关亮点回顾

Jesdoit阅读(66)评论(1)

苹果全球开发者大会上宣布了LibreSSL、TLS 1.3 Beta版、新的证书吊销检查机制。

上周苹果公司召开了年度全球开发者大会。会上的重大消息之一就是苹果的High Sierra for macOS、iOS11、tvOS11和watchOS4等新版操作系统的发布。

苹果公司花费了一些工夫讨论他们各平台加密库和SSL/TLS支持的改善情况。

下面,我们对所有这些改变做了一个概述,其中的大部分已在“你的App与不断进步的网络安全标准”会议上宣布过。

新的证书报错界面

High Sierra系统的证书查看器和Safari浏览器,重新设计了证书报错界面。

在Safari浏览器中,新的报错页面被设计为,通过给出一段简明的英文来解释问题,而没有使用像“协议”或“签名”这样的术语。这与Chrome浏览器的界面有些类似。

ssl changes in high sierra and iOS 11

证书查看器会进一步显示更详细的信息。在下面的截屏中,你可以看到,屏幕上显示了一个警告,具体说明了该信任错误的详细内容。在这个例子中,该错误提示“此证书无法核实(弱摘要算法)”,是因为该证书是通过SHA-1进行签名的。

ssl changes in high sierra and iOS 11

改进后的证书吊销检查机制

苹果公司发布了一种新的适用于其所有平台的证书吊销检查方法。它还未取得适宜的名字,不过它与Mozilla的OneCRL运行方式相类似。

ssl changes in high sierra and iOS 11

苹果公司的方法是,先扫描证书透明系统日志来发现他们的平台所信任的证书。然后再从证书颁发机构查询已发现的证书吊销状态。已吊销证书的所有相关信息都被捆绑在一起,在静默状态下每隔一段时间会被自动分发给客户端设备(如Macbooks和iPhones)

当建立一个TLS连接后,客户端会进行检查,验证证书在中央列表中是否被标记为吊销。如果证书被标记为吊销,那么客户端将会执行一个活动的OCSP检查,来确定这条信息是否准确。一旦确认,客户端就会知道该证书已被吊销,然后就会拒绝建立连接。如果服务器提供一个绑定的OCSP响应,那么它将会用这个响应来进行确认,而不需要执行活动的检查。

如果证书在中央列表中没有被标记为吊销,那么OCSP就不会被使用。

为LibreSSL而放弃OpenSSL

在High Sierra系统中,苹果公司已经将SSL库从OpenSSL0.9.8zh转换到LibreSSL2.2.7了。LibreSSL是OpenSSL的一个分支,受OpenBSD支持。

“安全传输”是苹果公司自己为SSL/TLS开发的API,但其首先应用于他们自己的软件。LibreSSL也将作为第三方软件的SSL库。

任何一次苹果全球开发者大会都未声明这一点,但这被High Sierra系统beta版用户发现了。

扩展ATS豁免

Chris Wood是苹果公司的“安全传输”项目工程师,他谈到App传输安全(ATS)的应用。Wood解释说,开发人员向苹果公司反馈说,过渡期比预想的要长,收到这一反馈后,苹果公司正在扩大对ATS豁免的支持。

Wood强调,苹果公司仍然会全力推动经由ATS的HTTPS,开发人员在努力进行向HTTPS的正确过渡时,他们对这些豁免的信任应是暂时的。

新苹果操作系统现在会对以下框架支持ATS豁免:AVFoundation、WebView和Webkit。豁免对本地网络连接(Ip地址和不合格的主机名)将会是可配置的。

豁免可以被限制在一个特定的域名,或是整个app中。我们还有一个办法来确认你是否想要对一个主机名的证书进行证书透明检查。

TLS 1.3 Beta版

TLS最新版1.3还没有被国际互联网工程任务组(IETF)确定下来。High Sierra和iOS 11系统支持TLS 1.3的一个规范草案,该草案较最终版本将十分接近。这使得开发人员在TLS 1.3正式确定前就已经开始对其进行测试了。

Chris Wood强调了TLS 1.3中更短的握手时间。他分享了苹果公司的分析数据,数据显示,在蜂窝网络上建立的TLS连接中有10%花费了800毫秒或更长时间,而在Wifi网络上建立的TLS连接中有10%花费了500毫秒或更长时间。而由于TLS 1.3具有更高效的握手方案,这个时间可以减少三分之一。

你需要从这个链接下载一个配置文件并进行安装,然后就可以在iOS 11系统中启用TLS 1.3了(需要苹果开发人员账号)。

通过以下终端命令,就可以在macOS High Sierra系统中启用TLS 1.3草案:

defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1

结束对SHA-1和2048位以下的私钥的支持

苹果公司的平台马上就可以迎合行业标准对老化的散列算法和加密方法的弃用要求了。

以SHA-1算法和/或使用2048位以下私钥签名的证书将不再被High Sierra、iOS 11、watchOS 4或tvOS 11系统信任。

对这一改变还有一些豁免。通过移动设备管理(MDM)机制或由Safari、Mail、Keychain Access分发的证书可以继续使用这些弱散列和密钥。(用于交互验证的)客户端证书也没有受到影响。

SHA-1签名的根证书也未受影响,因为这些证书的签名验证机制并不相同。使用2048位以下密钥的根证书在2015年已从苹果平台移除。

这些要求不应该引起对那些使用现代CA签名证书的任何担忧。SSL行业标准已经禁止这些弱应用一段时间了。

开发人员将可以通过一个唯一的错误代码识别这个问题:“InvalidCertChain (-9807)”。在URLSession/URLConnection中会返回这一错误代码。因为苹果公司正准备完全放弃对这种情况的支持,所以解决这一错误的唯一的方法就是替换你的证书。

RC4和3-DES将会被移除

“安全传输”的工程师Bailey Basile强调,“在将来”,RC4和3-DES这两个老化的密码算法,会被苹果公司的所有平台弃用。虽然还没有给出准确日期,但开发人员应该开始逐渐远离这两种很久以来即被公众所知的弱密码了。

Basile还建议避免在CBC模式中使用AES(AES-CBC)。他建议的密码套件是AES-GCM或ChaCha20-Poly1305。

 

稿源:The ssl store

页面加载被延迟 Firefox将禁用对DV和OV证书的OCSP检查

Jesdoit阅读(107)评论(0)

由于性能降低,Mozilla将会尝试禁用OCSP检查。OCSP,或称在线证书状态协议,是用来检测证书是否已被撤销的一个技术性机制。Firefox的这一变更将会同即将推出的新测试版本Nightly一同出现。如果遥测数据证明了禁用对DV和OV证书的OCSP检查可以减少握手时间,这一做法将会被带到标准版。

这将使Firefox与其他主流浏览器(包括Chrome和Safari)相提并论,其中服务器向客户端直接提供OCSP响应的OCSP装订将不会受到影响。此外, Firefox还将继续为EV(扩展验证)证书提取OCSP响应。

OCSP长期被批评为鸡肋。 由于在全球范围内部署服务的操作性挑战,OCSP通常在“软失败”的情况下终止 - 这意味着在OCSP检查未完成的情况下(因为服务器关闭或连接超时),证书被认为是有效的。因而一旦发生这种状况,OCSP就形同儿戏。 谷歌的工程师亚当·兰利(Adam Langley)甚至嘲讽它为“崩溃时扣上的安全带”。

Mozilla的遥测数据显示,在成功的OCSP检查中,大约9%的检测花了超过1秒的时间。这一秒加在了SSL/TLS握手上,从而大幅延长了整个页面加载的时间。更有甚者(0.05%的OCSP检查)超过3秒!这能忍?

无独有偶,Let's Encrypt的OCSP服务也在上月早些时候下线了12个小时,影响了不少使用他家证书的用户。去年GlobalSign也被他们的OCSP服务器坑了一回。这些事件都让人不禁疑问,OCSP这么闹心真的还要继续用吗?

Mozilla的安全工程师David Keeler写道:“这次禁用是为了监控遥测数据,看看OCSP是不是真的影响TLS握手时间。”要是真的有用,他们将会在所有Firefox版本中禁用OSCP检查。

其实早在多年前OCSP的性能就已经提升了不少——OCSP装订和Must-Staple的出现都旨在修复性能、安全性和隐私问题。然而不开窍的其实是Apache和Nginx,作为两大最主流的web服务器,他们在OCSP的特性实施上乏善可陈。因而到底坑货是谁?这话还真不好说。

稿源:The ssl store

与其他CA合作签发证书 谷歌赛门铁克之争接近尾声

Jesdoit阅读(119)评论(0)

上周五,谷歌和赛门铁克促成了一项提议,将允许赛门铁克在一定条件下继续颁发SSL证书。这是继今年年初被发现违规误发证书和被谷歌提出取消信任之后,赛门铁克与谷歌的第一次正式协商方案。

谷歌和赛门铁克都指出,提议中的一些具体细节可能会改变,但是他们趋近于“一个解决安全风险和减轻中断的良好平衡的提案”。

之前的谷歌提案涉及到对赛门铁克证书的一系列复杂的限制,以及对现有证书的分级不信任。这将使赛门铁克及其客户陷入棘手的境地,因为赛门铁克将不得像与其他CA一样提供相应的服务。

根据新提案,赛门铁克将与其他CA合作,继续发行证书,同时重新启动自己的业务。执行此计划所需的大部分工作将由赛门铁克本身进行。用户将看到相对较少的更改,并且可以获得对他们没有任何限制的新证书。

对于浏览器,将新旧的赛门铁克证书与新的根证书分开是非常重要的。这使他们有能力通过技术措施来控制哪些证书是可信的,而不是那些听上去更靠谱的政策。

这个提议的亮点在于:

  • 与以前的计划一样,这些操作适用于所有赛门铁克运营的CA,其中包括GeoTrust,Thawte和RapidSSL。
  • 从8月8日起,赛门铁克证书将需要由“托管CA”发出 - 赛门铁克与其合作的另一个认证机构。 目前还不知道谁将与赛门铁克合作。

这些证书将由现有赛门铁克根证书交叉签署,可以让信任赛门铁克的现有根源的各种传统设备的新证书受到信赖。

  • 此管理CA颁发的证书不会面临任何独特的限制。这意味着赛门铁克证书将能够按照行业标准规则颁发。他们的EV证书将继续使用绿色地址栏UI显示。
  • 2016年6月1日之前发布的现有证书(当赛门铁克证书需要遵守Chrome的证书透明度政策时)需要更换。 Chrome将在8月份的两个阶段(Chrome 62的发行版)中不信任这些证书。
  • 2016年6月1日以后发行的现有证书不受影响。这些证书的所有者不需要重新验证/重新发行,或看到有效期的任何减少。 EV证书将继续拥有EV UI。
  • 尽管如此,赛门铁克还将向谷歌和社区提供审计和报告,以显示其修复导致其违规的错误的进度。他们还将努力向根程序提交新的根证书,以便在技术上可行的方式再次开始验证和颁发证书。

赛门铁克的合作伙伴CA将继续处理发行和验证,直到赛门铁克的新根证书被接受到信托商店。对于任何一家公司来说,这都不算什么,包括经验丰富的CA。虽然一些根源程序(如Mozilla)是透明和有据可查的,但其他(比方说苹果)就像城市传说一样,可以花更长的时间来处理。

赛门铁克可能需要两年或更长时间才能将所有内容重新置于内部。但与此同时,他们的客户将继续能够购买和使用证书,而且没有复杂或不方便的限制。

再次注意,这还不是一个最终的计划。虽然这个过程看起来很艰巨,但考虑到赛门铁克业务的规模是有道理的。赛门铁克星期五表示,“仔细审查这项建议,并将尽快回应社区的意见反馈。”我们预计将尽快进行最后的调整,届时我们将发布有关即将发生的变更和行动的更多细节赛门铁克证书用户需要做好准备。

Mozilla与谷歌类似:它提出了一个仍然需要进行微调的计划。 它与谷歌非常相似,其中一个主要区别是赛门铁克证书将限于400天的有效期。 Mozilla也在辩论这样的想法,即在新的PKI启动时,赛门铁克需要外包CA的职责。 Mozilla意识到赛门铁克将不得不遵循所有根目录中最严格的规则,因此Mozilla正试图将其计划与谷歌的相提并论。

同行业的规范一样,微软和苹果都表示很少,也没有公开声明他们将要做什么。 历史上,他们的根程序更宽松,因此在确定对用户的影响时不太重要。

稿源:the ssl store

WannaCry席卷全球 软件作者到底赚了多少钱?

Jesdoit阅读(289)评论(0)

上周五大规模传播的WannaCry勒索软件让一群网络安全专家意外地团结起来。

WannaCry勒索软件的故事类似于好莱坞剧本,它像野火一样蔓延 - 从欧洲开始 - 感染了超过20万台电脑,其中包括英国国家卫生服务部门的大部分医院和医生办公室关闭非紧急服务。

该勒索软件利用了一个由美国国家安全局(NSA)发现的微软Windows漏洞,随后被影子经纪人泄露,并在两个月前进行了修补(如果您还没有,现在就重新进行补丁)。这种特殊的攻击使得WannaCry在感染组织内的设备方面特别有效。然后,一个匿名研究人员偶然发现了如何通过注册域名来制止攻击。英国媒体在周末曝光了改名研究员的真实身份,微软则把锅甩给了NSA,指责他们惹了大麻烦。

经过一个周末的努力,许多IT专家和研究员都已做好了面对新一周变种危机的感染。如果你是那个勒索软件作者,成功地攻击了全球近25万个设备和主要公司,包括雷诺和联邦快递,你期望这回能挣多少钱?

绑架一台电脑能赚多少钱?

首先,我们来看一下赎金要求。 一旦感染,WannaCry加密你电脑中的文件,并要求在比特币上支付300美元。 三天后,赎金飙升至600美元。

WannaCry Ransom Total

WannaCry提供了三个比特币付款地址,虽然比特币支付方式是匿名的(仅显示发件人和接收方的比特币地址),但所有交易都被公开记录在块中。因此要看出WannaCry作者的收入多少并不是件难事。查看块链接数据可以看出传送的比特币数量,发件人和收件人的比特币地址以及交易时间。

截至周一下午,WannaCry的三个比特币地址已经收获了215笔赎金。但其中35笔低于1美元,15笔低于25美元。许多付款都出自同一个人,很有可能是研究人员在测试这个勒索软件。

另外两笔款项大约在50刀左右——比测试款多,但远不及攻击者要求的赎金。这可能是系统出了错或是受害者和攻击方达成了某种协议。

而剩下的163笔费用则更像是真正的赎金——从168美元到3424美元不等。总计51644美元。超过两万美元的赎金都是在周一完成的交易。

虽然比特币可以直接用于购买一些物品,但是犯罪分子需要能够将其收取的赎金转为美元(或其当地货币),才能用得了。但考虑到该事件引发的巨大关注,要想将比特币安全地转换成真实货币可能是一个问题。

因此,现在这些罪犯并没有真正赚到一分钱。没有任何赎金已经从任何相关的比特币地址撤回或移走。一旦罪犯兑换这笔钱就会暴露身份,因为这笔钱也从来没有被使用过。

 

勒索软件如何“发家致富”?

尽管WannaCry已严重瘫痪,他仍然成功地感染并加密了超过10万台电脑。成千上万的受害者面对勒索只有三个选择:支付赎金,处理数据丢失,或等待研究界开发个解密器。

在接下来的几天内,随着企业和用户对恢复数据的需求,所收集的总赎金将大幅增加,每小时都有更多的赎金在支付。

许多公司的业务都被迫关闭,运维人员没日没夜地加班加点处理感染和估算损失。即使是手里有着所有重要数据备份的公司也要花费数小时的时间恢复机器或确保每台机器都装上补丁。而与此同时,微软提供的MS17-010补丁的带宽费用可能超过了犯罪分子收集的5万美元。

另一方面,这次攻击暴露了那些主流机构缺乏维护机器安全的意识。开个windows自动更新装上两个月前就发布的补丁,早就没WannaCry什么事了。

WannaCry已经变种了,赶快安上补丁才是正事儿!赶紧自救吧!

 

稿源:the ssl store

 

Chrome将证书透明度要求推迟至2018年

Jesdoit阅读(194)评论(0)

Google的证书透明度(CT)项目有望成为SSL生态系统最重要的改进之一。但老话说得好,好的事情值得等待。虽然证书透明度已经开始运行,但对于大多数CA来说,它是可选的。 这意味着CT无法完全发挥作用,因为并不是所有正在颁发的证书都被它知晓。

Google的Chrome浏览器将通过将CT记录强制要求所有希望被信任的SSL证书来解决这个问题。 但是强制性证书透明度合规的日期已经推迟了6个月 - 从今年10月到2018年4月。谷歌在4月底几个星期前宣布了这个消息。这条消息是在Google主持了“CT Days”会议后发布的。这个历时两天的会议集结了CA、CDN、日志操作员以及所有涉及或受证书透明度影响的代表。 而这个会议的结论就,整个行业都需要更多的时间来确保一切都完全准备好,以进行生态系统范围的推广。

Chrome的工程师之一Ryan Sleevi指出,在接下来的六个月里,他们希望看到“除了Chrome之外,还有助于保护其他浏览器用户的部署。”去年,Firefox宣布将支持CT,但尚未提交执行日期。

Chrome还在努力实现一个新的HTTP头,expect-ct,这将允许服务器运营商测试他们的配置和证书在最后期限之前是否都设置正确。

不可否认的是,证书透明度是SSL生态系统的一个重大变化 - 这同时面临技术挑战,对于企业部门来说,他们认为所有证书都可以公开发布。

例如,今年早些时候,东海岸的亚马逊S3云服务中断导致了Venafi的日志失败 - 展示了可靠运行日志的要求。同时,IETF仍在完成一些标准工作

此外,CT还面临一些”隐私问题“,尤其是对于那些主机名公开构成安全隐私风险的企业部门。“名称修改”仍然存在争议 - 这将允许对CT日志中的主机名进行部分审查。谷歌对大多数这些担忧仍然持怀疑态度,嘲讽这些”问题“是过时的威胁模式和对改变的莫名恐慌,而不是合法的风险。

但毫无疑问,证书透明度将为生态系统带来巨大的好处。即便它只是被部分采纳,CT已经抓取到了一定数量威胁

 

稿源:the ssl store

OpenSSL支持TLS1.3特性前瞻

Jesdoit阅读(270)评论(0)

本文由Matt Caswell于2015年5月4日发布在OpenSSL博客。

即将到来的OpenSSL 1.1.1版本将支持TLS 1.3。这个新版本将兼容OpenSSL 1.1.0版本的二进制文件和API。理论上,如果你的应用程序支持OpenSSL 1.1.0,那么当更新可用时,TLS 1.3版本也将自动得到支持,你不需要专门进行安装。但有一些问题仍需要应用程序开发人员和部署人员了解。在这篇博客中,我将谈谈其中的一些问题。

与TLS 1.2及更早版本的区别

TLS 1.3版本是对规范的重大修改。它到底应该叫TLS 2.0还是现在的名字TLS 1.3,还存在一些争论。该版本有重大变化,一些工作方式也非常不同。下面是你可能需要注意的一些问题,简明扼要,不过并不太全面。

  • 有一些新的密码套件仅在TLS 1.3下工作。一些旧的密码套件无法用于TLS 1.3连接。
  • 新的密码套件定义方式不同,且并未详细规定证书类型(如RSA、DSA、ECDSA)或密钥交换机制(如DHE或ECHDE)。这对密码套件的配置有暗示作用。
  • 客户端在客户问候消息(ClientHello)中提供一个“key_share”。这会对“组”配置产生影响。
  • 直到主握手完成以后,会话才会建立。在握手结束和会话建立之间可能会有一个间隙(理论上,会话可能根本不会建立),并可能对会话恢复代码产生影响。
  • 在TLS 1.3版本中,重新磋商是不可能的。
  • 现在大部分握手都会被加密。
  • 更多类型的消息现在可以有扩展(这对定制扩展API和证书透明系统有影响)。
  • 在TLS 1.3连接中不再允许使用DSA证书。

注意,在这一阶段,只支持TLS 1.3。因DTLS 1.3版本的规范刚刚开始制定,目前并不支持OpenSSL。

TLS 1.3标准目前的状态

到我写这篇文章时,TLS 1.3仍是一个草案。TLS工作团队定期会发布该标准的新版草案。实际中,需要对草案进行部署来识别他们使用的具体版本,基于不同草案版本的实现之间无法交互。

OpenSSL 1.1.1至少不会在TLS 1.3发布之前完成。同时,OpenSSL的git主分支包含了我们的TLS 1.3开发代码,可以用于测试(即不用于生产)。你可以在任意OpenSSL版本中通过头文件tls1.h中的宏TLS1_3_VERSION_DRAFT_TXT的值来查看部署的TLS 1.3草案的版本。在该标准的最终版发布后,这个宏会被删除。

你必须使用“enable-tls1_3”选项来“配置”(config或Configure),以编译OpenSSL,使其支持TLS 1.3。

目前,OpenSSL已执行了TLS 1.3的“20版草案”。而很多其他库仍在使用旧版草案。相当多的主流浏览器在使用“18版草案”。这是交互性问题产生的共同来源。18版草案的交互性已被BoringSSL、NSS和picotls测试过。

在OpenSSL的hit源码库中有两个分支:“tls1.3-draft-18”和“tls1.3-draft-19”,都执行旧的TLS 1.3草案版本。为测试其它TLS 1.3版本环境下的交互性,你可能需要使用其中一个分支。注意那些分支被认为是临时的,而且当将来不再需要它们时,可能会被删除。

密码套件

OpenSSL已支持以下5种TLS 1.3的密码套件:

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

其中,前三个是在默认密码套件组中。这意味着如果你没有主动对密码套件进行配置,那么你会自动使用这三个密码套件,并可以进行TLS 1.3磋商。

所有TLS 1.3密码套件也都出现在别名HIGH中。正如你预计的那样,CHACHA20、AES、AES128、AES256、AESGCM、AESCCM和AESCCM8这些密码套件别名都像它们的名称一样,且包含这些密码套件的一个子集。密钥交换和认证属性是TLS 1.2及以前版本中密码套件定义的一部分。在TLS 1.3中不再如此,所以密码套件别名(如ECHHE、ECDSA、RSA及其它相似别名)都不包含任何TLS 1.3密码套件。

如果你主动配置了你的密码套件,那么应该注意确保你没有不小心排除掉所有兼容TLS 1.3的密码套件。如果一个客户端启用了TLS 1.3而未配置TLS 1.3密码套件,那么会立即报错(即使服务器不支持TLS 1.3),出现以下提示:

1

 

140460646909376:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available:ssl/statem/statem_clnt.c:3562:No ciphers enabled for max supported SSL/TLS version

类似地,如果一个服务器启用了TLS 1.3而未配置TLS 1.3密码套件,那么也会立即报错,即使客户端不支持TLS 1.3,提示如下:

1

 

140547390854592:error:141FC0B5:SSL routines:tls_setup_handshake:no ciphers available:ssl/statem/statem_lib.c:108:No ciphers enabled for max supported SSL/TLS version

例如,默认设置一个密码套件选择字符串ECDHE:!COMPLEMENTOFDEFAULT,还使用ECDHE进行密钥交换。但是,ECDHE组中没有TLS 1.3密码套件,所以如果启用了TLS 1.3,那么这种密码套件配置在OpenSSL 1.1.1中将会出错。你可能要指定你想使用的TLS 1.3密码套件来避免出现问题。例如:

1

 

"TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT"

你可以使用openssl ciphers -s -v命令来测试,在给定的密码套件选择字符串中包含那个密码套件:

1

 

$ openssl ciphers -s -v "ECDHE:!COMPLEMENTOFDEFAULT"

确保至少有一个密码套件支持TLS 1.3

在TLS 1.3中,客户端选择一个“组”用来进行密钥交换。在我撰文时,OpenSSL仅支持ECDHE组(当OpenSSL 1.1.1自动发布时,可能就会支持DHE组了)。客户端会在客户端问候消息中为其所选的组发送“key_share”信息到服务器。

支持的组的名单是可配置的。一个客户端可能会选择一个服务器不支持的组。在这种情况下,服务器请求客户端发送一个其新支持的key_share。这意味着仍会建立连接(假设存在一个互相支持的组),会引入一个额外的服务器双向连接——所以会对性能产生影响。在理想情况下,客户端将在第一个实例中选择一个服务器支持的组。

实际上,多数客户端都会为它们的首个key_share使用 X25519或P-256。为实现性能最大化,建议对服务器进行配置,使其至少支持这两个组,客户端为其首个key_share使用其中一个组。这是默认的情况(OpenSSL客户端将使用X25519)。

组配置还控制着TLS 1.2及以前版本中允许的组。如果应用程序在OpenSSL 1.1.0中曾配置过它们的组,那么你应该重新检查配置,以确保其对TLS 1.3仍然有效。第一个被指定的组(即最偏好的组)将会被一个OpenSSL客户端在其首次key_share中使用。

应用程序可以使用SSL_CTX_set1_groups()或一个相似的函数(看这里)配置组列表。如果应用程序使用SSL_CONF风格配置文件,则可以使用Groups或Curves命令(看这里)来进行配置。

会话

在TLS 1.2及以前版本中,一个会话的建立是握手的一部分。这个会话就可以在后续连接中被使用,以实现一个简单握手。一般,在握手完成后,应用程序可能通过使用SSL_get1_session()函数(或类似函数)从会话上得到一个句柄。更多细节请看这里

在TLS 1.3中,直到主握手完成后,会话才会建立。服务器发送一个独立的握手后消息(包含会话细节)到客户端。通常,这会发生在握手结束后不久,也可能会稍晚一些(甚至根本不发生)。

按照规范,建议应用程序每次只使用一个会话(即使不是强制性的)。由于这个原因,一些服务器会向一个客户端发送多个会话消息。为执行“每次使用一个”的建议,应用程序可以使用SSL_CTX_remove_session()把一个使用过的会话标记为不可恢复(从缓存中将其删除)。旧的SSL_get1_session()和相似API可能像TLS 1.2及以前版本中一样运行。具体来说,如果一个客户端应用程序在收到包含会话细节的服务器消息之前就调用SSL_get1_session(),那么仍将返回一个SSL_SESSION对象,任何试图恢复的企图都不会成功,而是会产生一个完整的握手。在服务器发送多个会话的情况下,只有最后一个会话被SSL_get1_session()返回。

客户端应用程序开发者应该考虑使用SSL_CTX_sess_set_new_cb() API(看这里)。这提供一个回调机制,每次新的会话建立时该机制都会被调用。如果服务器发送多个会话消息,就可以为一个连接调用多次。

注意,SSL_CTX_sess_set_new_cb()在OpenSSL 1.1.0中仍然可用。已使用的那个API应用程序仍可以工作,但它们可能会发现,回调机制被调用的时机变了,变成了在握手之后发生。

在主握手完成后,一个OpenSSL服务器将立即尝试发生会话细节到客户端。对服务器应用程序来说,这一握手后的阶段看起来像是主握手的一部分,所以对SSL_get1_session()的调用应该像以前一样继续工作。

定制扩展和证书透明系统

在TLS 1.2及以前版本中,首次客户端问候信息和服务器问候信息可以包括“扩展”。这允许基础规定可以被添加很多额外特性,这些特性可能无法在所有情况下使用,或者在制定基础规定时无法预见。OpenSSL支持大量“内置”扩展。

此外,定制扩展API还为应用程序开发人员提供一些基本功能,以支持没有内置在OpenSSL中的新扩展。

建立在定制扩展API顶层的是“服务器信息”API。这提供了一个更加基础性的接口,可以在运行时进行配置。例如证书透明系统。OpenSSL为证书透明系统的客户端提供内置支持,但没有内置服务器端支持。但是,用“服务器信息”文件就很容易实现。一个包含证书透明系统信息的服务器信息文件可以在OpenSSL中配置,再被正确地发回客户端。

在TLS 1.3中,扩展的使用显著增加,有很多消息包含扩展。此外,一些支持TLS 1.2及以前版本的扩展在TLS 1.3中不再被支持,一些扩展从服务器问候消息转移到了加密扩展消息中。旧的定制扩展API没有能力指定扩展应该关联的消息。

由于这个原因,需要有一个新的定制扩展API。

旧API仍在工作,但定制扩展将只在TLS 1.2及以前版本环境下被添加。想要为所有TLS版本添加定制扩展,应用程序开发人员就需要把他们的应用程序更新到新的API(更多详情看这里)。

“服务器信息”数据格式也已被更新,以包含额外的关于扩展所关联的消息的信息。使用“服务器信息”文件的应用程序可能需要更新到“版本2”的文件格式,才能在TLS 1.3中运行(更多细节看这里这里)。

重新磋商

TLS 1.3没有重新磋商机制,所以在TLS 1.3环境下,对SSL_renegotiate()和SSL_renegotiate_abbreviated()的调用会立即失败。

重新磋商最常见的例子是更新连接密钥。再TLS 1.3中,函数SSL_key_update()可以用于的这个目的(看这里)。

DSA证书

TLS 1.3中不再允许DSA证书。如果你的服务器应用程序正在使用DSA证书,那么TLS 1.3连接将会失败,提示如下:

1

 

140348850206144:error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:ssl/t1_lib.c:2308:

请使用ECDSA或RSA证书。

结论

TLS 1.3代表着一次重大进步,它有一些激动人心的特性,但对粗心的人来说,在更新时可能会有一些风险。大部分时候,这些问题都会有直接的解决办法。应用程序开发人员应该重新检查他们的代码,并考虑为更高效地使用TLS 1.3,是否应该安装所有更新。类似地,部署人员也应该重新检查他们的配置。

稿源: OpenSSL Blog

四月SSL行业新闻回顾

Jesdoit阅读(255)评论(0)

 

稿源: the feisty duck

新型钓鱼攻击:在Chrome、Firefox和Opera的眼皮下暗度成仓

Jesdoit阅读(326)评论(0)

中国信息安全研究人员@郑旭东发现了一种新的“几乎不可能检测到的”钓鱼攻击。他宣称,该漏洞甚至可以骗过互联网上最谨慎的用户。黑客可以利用Chrome、Firefox和Opera浏览器中的已知漏洞使他们的假冒域名显示为合法网站,如苹果、谷歌或亚马逊,以此从用户那里窃取登录信息、财务凭证或其他敏感信息。

通常情况下,对钓鱼攻击最好的防御手段是检查浏览器地址栏,看是否为有效的HTTPS链接。但这样真的就安全了吗?请看下图:

你可能会说,欸这人家域名看起来没毛病,还带着安全链接标记,怎么就成钓鱼网站了?

但这恰恰就是个冒牌货呀!“不仔细检查网站的URL或SSL证书的话,就无法看出网站是否为假冒的了。”郑旭东在博客中说道。

如果你的浏览器地址栏显示带有安全SSL标志的“apple.com”,而页面内容却来自另一个服务器(就像上图显示的那样),那说明你的浏览器易受同形异义字攻击。

来自Wordfence的安全专家还创建了另一个概念验证网站来证明浏览器的这一漏洞。这个网站假冒的是“epic.com”域。

同形异义字攻击在2001年开始为人所知,浏览器厂商一直在试图解决这个问题。它是一种伪装攻击,网站地址栏看上去是合法的,但其实不是。因为地址中的一个或几个字符被伪装的Unicode字符替换了。

对这一点你了解多少并不重要,任何人都可能变成这种“几乎不可能检测到的”钓鱼攻击的受害者。

在国际化域名中,很多代表希腊、西里尔和阿美尼亚字母表的Unicode字符,不仔细看的话,看上去与拉丁字母没有区别,但计算机却会按照完全不同的网址进行处理。

例如,西里尔字母“а”(U+0430)和拉丁字母“a”(U+0041)会被浏览器作为不同字符处理,但在地址栏中都显示为“a”。

默认情况下,很多浏览器使用“Punycode”编码系统在URL中表示unicode字符,以防止同形异义字钓鱼攻击。Punycode是一种特殊的编码系统,浏览器使用这种编码系统将unicode字符转化为国际域名系统支持的ASCII(A-Z,0-9)有限字符集。

例如,中文域“短.co”在Punycode中表示为“xn--s7y.co”。

按照郑旭东的说法,造成该漏洞的原因是,如果有人选择将域名的所有字符都使用某一种外文字符集,并且与目标域极其相似,那么浏览器将以该种语言而不是Punycode形式返回域名。

这一漏洞使得研究人员可以注册一个xn--80ak6aa92e.com这样的域名,并绕过防御系统,在具有该漏洞的所有浏览器中,都会显示为“apple.com”,这样的浏览器包括Chrome、Firefox和Opera,而IE、Microsoft Edge、Apple Safari、Brave和Vivaldi浏览器没有这一漏洞。

这里xn前缀是指ASCII兼容编码前缀,告诉浏览器这个域使用“punycode”编码系统来表示Unicode字符,因为作者使用西里尔字母“а”(U+0430)而不是ASCII字符“a”(U+0041),所以浏览器的防御机制未能奏效。

郑旭东在今年一月向受影响的浏览器厂商报告了这个发现。目前,Mozilla仍在讨论修复程序,而谷歌已在其试验版Chrome Canary 59浏览器中修复了这一漏洞,并将在稳定版Chrome 58中推出永久性修复程序,该版本定于本月晚些时候发布。

同时,他还建议数百万面临这一难以检测到的复杂钓鱼攻击威胁的互联网用户,在其浏览器中关闭Punycode支持,以临时缓解受攻击的风险,并指出了某些钓鱼域名。

目前,Firefox用户可以在设置中手动关闭Punycode URL转换:

  1. 在地址栏输入about:config并按回车。
  2. 在搜索栏输入Punycode
  3. 浏览器设置将显示参数名:IDN_show_punycode,双击或右击并选择切换,将此参数的值由false改为True

在Chrome或Opera浏览器中没有类似的设置来手动关闭Punycode URL转换,所以Chrome用户只能等待几星期后发布的稳定版Chrome 58去修复这一漏洞。

尽管如此,还是可以在应用商店找到一些第三方Chrome扩展/插件,用户可以安装这些扩展/插件,这样他们每次访问域名中包括Unicode字符的网站时,浏览器就会发出警告。

此外,对于像Gmail、Facebook、Twitter、Yahoo或银行网站等重要网站来说,避免误入钓鱼网站的最佳方法,是在地址栏手动输入网站URL,而不建议通过点击某些网站或电子邮件上的链接,以避免遭受这类攻击。

 

稿源:the hacker news\ xudongz.com\ Graham Cluley

CAB Forum:微软的决胜投票很可能无效

Jesdoit阅读(194)评论(0)

由于微软的程序性错误,CAB论坛近期的一次投票备受争议。被认为投出关键票的微软,是这场争议的焦点。

作为SSL证书的行业风向标,CAB论坛由证书颁发机构(CA)和浏览器厂商组成,旨在共同组织颁发公开证书的指导方针和做法。

投票大会194试图纠正最近一次投票造成的非故意性后果:由于文字错误,第193号决议将导致大量“有效证书”在短短几日内失效。这将是CA和他们的客户的麻烦,如果他们想要重新发放或替换现有证书,那么他们需要等待他们的信息被重新验证。

第194号决议的投票期于4月16日关闭,此后CAB论坛主席柯克·霍尔(Kirk Hall)向组委会成员发了一封电子邮件,通知他们投票已经过去了。在CAB论坛中,每个组(CA和浏览器)必须批准一个选票才能通过。当时,所有来自CA的24票都赞成了194号决议,而由于浏览器厂商方面未满足50%赞成票,投票结果一度悬而未决。直到统计到大会三日前微软的投票,浏览器厂商的票数才终于过半。

由于代表微软投票的是其雇员,并不在CAB成员邮件列表里,他的邮件在一开始被拒绝,其他成员都不知道这张票。只有柯克·霍尔因为被CC的原因看到了微软的选择。正因如此,Google的Ryan Sleevi指出,微软的投票不符合操作规定,不应该作数。如果微软的投票被宣布无效,该提案将以失败告终。

如果投票通过,CA的困难将被解救。而一旦失败,他们将需要迅速采取行动处理与以前验证的信息相关的规则变更。但就算微软的投票这次被批无效,再组织一次投票且每张票都符合流程,提案依旧会被通过。

对于围观者来说,google的这种对投票程序和规定的质疑是毫无意义的。微软都投支持票了,还想怎样?虽然在这种情况下没有太多的利害关系,那下一次呢?

CAB论坛章程规定:

2.2 (d) “Upon completion of the discussion period, Members shall have exactly seven calendar days for voting, with the deadline clearly communicated in the ballot and sent via the Public Mail List. All voting will take place via the Public Mail List. Votes not submitted to the Public Mail List will not be considered valid, and will not be counted for any purpose.”

2.2(d)“讨论期结束后,议员应有完整的七个日历日进行表决,截止日期在选票中明确传达,并通过公共邮件列表发送。 所有投票将通过公共邮件列表进行。 未提交给公共邮件列表的投票不被视为有效,不会被视为任何目的。

辩论的内容超出了“已提交”一词的含义。只要邮件已经发出,不管张贴列表里收没收到,都算有效吗? 还是说邮件必须被接收和归档? 在这个具体的(可能预见的)情况下,“通过公共邮件列表进行投票”的要求也表明微软的投票并不符合规定。

不过,Hall表示,微软的投票已被发送到正确的地址并在最后期限内,因此正在点票。 在Sleevi坚持反对意见之后,Hall写道:“一个浏览器尝试阻止另一个浏览器的投票,这是一种不客气的方式。 Google是唯一在这次投票中投票的论坛成员--20个CA和2个浏览器投票为yes。 显然,成员们的共识是赞成这一投票,而且即使不是由我们的服务器转发,技术上微软正式投票。“

在成员互通多封邮件后,Hall提议再重新办一个简易投票来得到最终结果。但这一做法反倒遭到了更强烈的反对。

这次争议体现了当下CAB论坛的窘境。众人不齐心,分歧和争议不断发生。Web PKI的未来存在持续的分歧,特别是撤销检查,证书颁发自动化和证书有效性等问题。论坛最近也出现了治理和知识产权问题,阻碍了许多其他举措和改进。194号投票本来是件小事,但这一争端的结果不仅仅是投票。它将为论坛设定基调。我们是走向不和谐还是合作?

票选的命运尚未确定,双方仍在僵持。未来将如何?每个利益相关方都有自己的期许。CAB论坛的和平之路,且行且珍惜!

 

稿源:the ssl store

 

巴西银行Banrisul被黑 Let's Encrypt成背锅侠

Jesdoit阅读(341)评论(0)

卡巴斯基实验室的Dmitry Besthuzhev和Fabio Assolini在本周的安全分析高峰会上发表了一项针对巴西银行Banrisul的攻击行动,该峰会是卡巴斯基在圣马丁举行的一次会议。

2016年10月,巴西银行网站一整天被黑客完全接管。 攻击者完全破坏了银行的DNS,重新路由和拦截了所有36个银行域名的流量,包括其网络银行和销售点交易。 除了网络钓鱼客户的凭据和活动外,攻击者还向访问者分发恶意软件。

Wired网站对该攻击做出如下总结:

“Absolutely all of the bank’s online operations were under the attacker’s’ control for five to six hours,” says Dmitry Bestuzhev, one of the Kaspersky researchers who analyzed the attack in real time after seeing malware infecting customers from what appeared to be the bank’s fully valid domain. From the hackers’ point of view, as Bestuzhev puts it, the DNS attack meant that “you become the bank. Everything belongs to you now.”

“该银行所有的在线业务被黑客控制长达5-6 个小时”,卡巴斯基研究员Dmitry说道,“也就是说,当时黑客拥有了整个银行!”

尽管卡巴斯基并没有透露银行的具体名称,但证书透明度记录以及部分披露的细节都指向了巴西南部的一家名叫Banrisul的银行。该银行拥有超过250亿美元的资产和500家分行。据卡巴斯基称,该银行尚未披露这一攻击。

攻击者还签发了两张证书


是的,你没有看错,攻击者使用了Let's Encrypt证书,让整个攻击行为看起来更合法,并控制解密数据所需的密钥。用户登录网银时看到的是“HTTPS页面”于是“特别让人放心”。在该攻击场景中,黑客控制了你的DNS,从而能够轻易地请求并确认证书。而对CA来说,你是主机的拥有者,发张证书给你没毛病。大多数CA都会做同样的事。但令人痛心的是,Let's Encrypt又一次成了背锅侠。因为它的免费证书使得匿名使用服务变得容易,而且他们的策略是对高危请求进行标记或者黑名单。上一次背锅,还是前不久的Paypal钓鱼网站证书事件

对普通用户来说,看到网站使用的HTTPS连接足以使他们掉以轻心。而更为细心的用户,可能会通过观察DNS记录或发现网站突然换了CA而有所警觉。但这次媲美偷天换日的攻击,没有使用户起疑心。

银行如何保护自己?对于初学者来说,对DNS的更好的控制和监督至关重要。 Assolini指出,该银行没有使用DNS提供商提供的双因素身份验证选项,这将使得这个帐户更容易接管。

Banrisul也可以加强其HTTPS配置。 HTTP公钥固定(HPKP)是作为HTTP头实现的SSL / TLS的可选安全功能。它允许网站向客户端提供一组被授权用于HTTPS连接的公钥。如果客户端将来连接到该站点并接收到不同的密钥,它将拒绝连接。

HPKP设置起来更加困难,遇到配置不当或密钥管理不善,容易引发故障。但是,它也可以在恶意攻击者控制您的网络并可以以您的名称发布证书(或降级为HTTP)或CA错误发布证书的情况下保护网站。如果HPKP被部署,以前访问过Banrisul网站的用户(将是其大多数客户)将受到保护,免受此攻击。

证书颁发机构授权(CAA)是旨在保护网站免受敌对发行的另一个措施。它允许域选择哪些CA可以颁发证书,每个CA在为所述站点颁发证书之前检查CA。但CAA被设置为DNS记录,在这种情况下,攻击者可能已经能够绕过此保护,即使已被使用。

随着HTTPS安全链接在用户群中的普及,越来越多的网民都会在登陆敏感数据(如银行或电子邮件服务)相关的站点时,注意到网站是否HTTPS。而犯罪分子正是抓住了这一点,正花费额外的时间用SSL证书掩盖他们的攻击。也就是说,这年头部署一张HTTPS证书仅是基本,想要保护自身免受诸如此类的复杂攻击,还得要多花些心思才行呐!

 

稿源: The SSL Store/ Wired