关注网络安全
和行业未来

什么?你的私钥泄漏了?

Jesdoit阅读(3)评论(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阅读(123)评论(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阅读(193)评论(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阅读(156)评论(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阅读(212)评论(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阅读(237)评论(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阅读(244)评论(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阅读(483)评论(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

 

虚张声势?谷歌将强制证书透明度期限挪至Chrome68

Jesdoit阅读(403)评论(1)

说好的四月三十日没能实现,强制证书透明度还得等到七月份。

上周我们在文章中提到,所有在2018年4月30日签发的SSL证书都必须记载到证书透明日志,不然用户在浏览网站时就会收到整页的不安全警告。然而事与愿违,尽管从证书透明制诞生以来各大浏览器厂商都在尝试将其实践,谷歌去年还给了证书颁发机构一年的时间、推迟了进程。

而这回,谷歌给的信息显得更含糊,让人难以解读。 例如,CT截止日期已过,但谷歌直到7月份才开始执行。 谷歌其实可以明确表示,这只会影响在截止日期之后发布证书的网站。也就是说,2018年4月30日之前发布的任何证书都不用载入证书透明制。

事实上,4月30日的截止日期是针对证书颁发机构的。这仅仅是业内变动,与客户无关。如果现在一家CA给你发了张没进证书透明制的证书,那基本上是误签发没跑了。要是你运气不太好,真得了张这样的证书,你在Chrome 68发布之前(7月中旬)还有机会做调整。等到7月份Chrome 68正式版发布了,使用不进证书透明制的证书才会真正波及您的用户。

有一个方法可以帮助您查看自家的证书是不是符合标准,会不会触发警告:

希望测试新颁发证书以符合合规性的站点操作员和CA可以从Chrome 67开始在开发者工具中使用这个功能。“安全”面板将提供有关连接和证书的详细信息,包括连接和证书是否适当地支持证书透明。或者,对于想要测试被主动阻止的使用非法证书的站点管理员,可以通过以下命令行标识来实现:

--enable-features=”EnforceCTForNewCerts<EnforceCTTrial” --force-fieldtrials=”EnforceCTTrial/Group1” --force-fieldtrial-params=”EnforceCTTrial.Group1:date/1525132800”

因此请大家不要担心。证书颁发机构们早就花了几年的时间成为CT认证了。大多数用户的警告将不会在7月生效。

 

稿源:The ssl store

四月行业新闻回顾

Jesdoit阅读(270)评论(0)

本月大事件:证书透明记录成强制

从4月30日开始,Chrome浏览器将要求所有新证书符合证书透明度。 这是证书生态系统中的一项重大变化,已经准备了好几年。 证书透明度在许多证书颁发机构发现错误的案例中已经发挥了重要作用。

证书透明度的核心思想相对简单:所有公开发布的证书都存储在公共附加日志中。 这些允许每个人检查是否已颁发其域名的非法证书。 为了显示证书已经被记录,在TLS握手期间必须提供两个所谓的签名证书时间戳(SCT)。 SCT是来自日志的已签署声明,用来确认已提交证书。

交付SCT有不同的方式,但最常见的方法是直接将其添加到证书本身。大多数证书颁发机构会自动执行此操作,因此网站操作员无需手动执行任何操作。由于CA在颁发证书之前不能记录证书,因此这些嵌入证书的SCT需要颁发的证书须包含特殊的扩展名,并且与最终证书相同,除非它缺少SCT。

那么问题来了,是不是只记录预证书就行,而不用包括最终的证书呢?Let's Encrypt最初决定只记录预证书,但如今也开始尝试记录最终证书

尽管证书透明度日志记录现在是新证书的一项要求,但流氓或受感染的CA仍然可以通过回溯来创建未记录的证书。 这可以通过使用Expect-CT标头来防止。

Hardenize服务添加了对证书透明度合规性的检查

短新闻

稿源: feisty duck