关注网络安全
和行业未来

Facebook将链接结构升级为包含HSTS预加载

HTTP严格传输安全将强制在所有域上进行安全连接

周一上午,Facebook伦敦数据隐私团队宣布已升级其链接结构包含HSTS预加载。 这对于更安全的互联网来说是个好消息,因为这将有助于推进互联网加密。

当今的互联网正不断从不安全的HTTP过渡到更安全的HTTPS。从今年夏天开始,随着Chrome 66的发布,所有使用HTTP的网站都会被谷歌贴上负面标识并发出警告。互联网中所有不加密的网址都会在2019年前“死去”。Facebook的此举无疑是有助于加速变革的。

HSTS或HTTP严格传输安全性是一种HTTP头,一旦由互联网用户下载,就会通过HTTPS强制与该网站建立连接。

通常,您会看到一个网站添加HSTS标头,然后将其自身添加到HSTS预加载列表。 该名单由Google维护,指示浏览器在首次尝试连接时与给定URL建立安全连接。 这反过来又关闭了一个小型攻击媒介,其中一个互联网用户的系统在它的第一个连接上容易受到攻击,然后它就可以下载头部本身。

尽管许多现代浏览器支持HSTS,但有些人仍然使用不支持它的浏览器。 对于这些人,当他们从Facebook或Instagram导航时,我们将能够确保他们与受支持网站的首次连接是安全的,并避免将他们的连接暴露为未加密的流量。 此外,浏览器中的HSTS列表可能已过时。 预加载列表本身只能在浏览器更新到新版本时更新; 并且未预加载的站点可能尚未被浏览器缓存。 最近的研究还表明,一些浏览器只能提供有限的HSTS支持 - 无论是通过在存储1024个条目后遗忘网站,还是仅仅不支持某些网站的HSTS - 意味着对HSTS的全面保护并不总是扩展到使用这些站点。

我们根据两个来源确定哪些链接可以升级到HTTPS。 首先,我们使用Chromium预加载列表,该列表在大多数主流浏览器中都有使用,我们会定期更新。 其次,我们记录来自Facebook上共享网站的HSTS标头。 我们将浏览器预加载列表与使用预加载指令提供服务的任何站点进行补充。
通过迫使用户关注HTTPS链接的手段,Facebook正在帮助加快HTTPS的发展,旨在让人们能更安全高速地加载网页。
稿源:The SSL Store

二月行业新闻回顾

本月大事件:Chrome将标记所有HTTP页面为不安全

Google一直是默认推送HTTPS的主要力量。 多年来,Google表示该计划最终将Chrome浏览器中的所有HTTP连接标记为不安全。 但考虑到普通互联网用户会对太多警告产生疲劳,这不是一个一夜之间就能发生的变化。

但是现今由于HTTPS连接的增加,谷歌默认安全网络的时间已近在咫尺。 今年7月,随着68版的发布,所有HTTP网页的默认警告将登陆Chrome。

这个结果是经过长时间准备的。 Chrome首先在登录表单上显示警告,然后将其扩展到所有输入表单。 此外,许多功能强大的网络功能(如麦克风访问,地理定位或HTTP / 2)仅通过HTTPS提供。同时, Mozilla也作了类似的限制。

短新闻

  • GitHub禁用了旧版TLS版本1.0和1.1的支持。 这一行动已于2017年2月公布。GitHub博客文章提供了一些旧客户端列表,这些客户端存在兼容性问题并且不支持TLS 1.2。 预计更多的网页很快就会开始废弃旧的TLS版本,并且在6月份,PCI信用卡标准将要求禁用TLS 1.0
  • 研究人员在NIST后量子竞争中创建了一个关于基于lattice的算法提案的概述网页。
  • Caddy网络服务器计划了一个遥测项目,在该项目中,它将从页面访问者收集数据,其中包括与TLS连接有关的大量信息。
  • 新的RFC 8314阐述了如何运行一个需要TLS加密的现代邮件服务器。 值得注意的是,对于POP3,IMAP和SMTP使用隐式TLS端口,以前是非官方的,有时候会被视为弃用,现在是TLS的推荐方法。
  • Chrome和Firefox浏览器已开始停止信任旧的赛门铁克证书。该计划公布于2017年8月,但许多网站管理员似乎仍为准备好执行该计划。 Arkadiy TetelmanScott Helme各自检查了使用不受信任的证书的网页。想检查自家网站是否受该事件影响的话可以使用Chrome Canary或Firefox Nightly,或查看Chrome的开发者工具。SSL Lab也出了一个检查受影响证书的工具。
  • Scott Helme在博客文章中讨论了证书生命周期。
  • OpenSSL发布了1.1.1版本的第一个alpha版本。最大的变化是增加了对即将到来的TLS 1.3的支持。
  • TLS 1.3进入终审阶段,这意味着我们很快就会看到最终版本。
  • 研究人员发现了腾讯QQ浏览器中的加密漏洞。 值得注意的是,他们发现中文浏览器使用了Textbook RSA和RSA以及极短且易破解的密钥。
  • 博客文章显示了X.509扩展如何有时用于数据泄露。
  • SSL Lab已经宣布对其评级标准进行修改。 值得注意的是,没有前向保密且没有AEAD的页面将不再获得A评级,易受ROBOT攻击的页面将获得F.
  • Let’s Encrypt之前曾宣布在二月底前支持通配符证书,现日程被延后
  • Scott Helme在Alexa Top 1 Million上发布了关于TLS功能的统计数据

 

稿源:The feisty duck

Firefox要求AppCache使用HTTPS

从Firefox 62起,HTTP页面将无法使用AppCache。

应用程序缓存(AppCache)为希望离线运行其网站的网站管理员提供缓存机制。 现在,它可以用于HTTP以及HTTPS页面。 然而,在2018年计划推出的Firefox 62中,只有HTTPS网页就能包含此功能。 换句话说,Firefox已将AppCache限制为安全上下文。

AppCache不仅能离线运行站点,还是许多网站管理员提高加载速度并减少服务器负载的利器。

如果AppCache在HTTP网站上运行,它可能会造成一些严重的安全问题。用Mozilla的话来说,这是因为“AppCache在重新验证其缓存方面存在局限性,这允许攻击者诱骗浏览器永远不会通过将清单设置为格式不正确的缓存文件来重新验证缓存“。

当您的浏览器加载启用AppCache的网站时,它会以缓存的形式存储该网站的数据。 AppCache API在验证缓存文件时有其自身的局限性。 因此,当用户打开这样的网站时,浏览器将从存储的缓存中提供数据,而不会验证所存储的缓存是否具有相同的格式。

假设您已连接到Wi-Fi网络,并且攻击者也已连接。 如果您使用AppCache访问过网站,则您的浏览器必须具有存储缓存。 现在,当攻击者连接到同一个网络时,他/她可以以某种方式操作这个存储的缓存,并且浏览器(AppCache)将无法注意到它,因为它无法验证缓存。 因此,如果攻击者设法操纵缓存并添加iframe(就像嵌入一样),他/她可能会欺骗用户提供他们的机密信息 - 即使在用户与该网络断开连接之后。

想象一下,一个名为example.com的AppCache启用的HTTP站点和一个犯罪分子设法插入一个虚假的微博登录页面。 如果您输入您的电子邮件ID和密码,它将被捕获。 这就是为什么Firefox要将这种AppCache功能限制在HTTPS上的原因。

谷歌在年初的时候曾发话将在今年7月全面标注非HTTPS站点为”不安全“,而事实上这并非一家之言。像谷歌,mozilla这样的主流浏览器厂商近几年正不断深化摈弃HTTP不安全协议的理念。通过限制AppCache来实现安全上下文无疑是大方向上的另一步。

绕过安卓系统SSL验证和证书绑定的四种方法

移动应用程序曾经毫无怨言地忽略了各种各样的SSL错误,并允许你随意地拦截和篡改它们的通信,但是这样的日子已经一去不复返了。相反,大多数现代应用程序至少会检查其收到的证书是否由一个有效的、受信任的证书颁发机构(CA)所颁发。作为渗透测试人员,我们希望让应用程序相信我们的证书是有效且可信的,这样我们就可以对其进行“中间人”(MITM)攻击,并篡改它的通信。在本篇博客中,我将介绍4种技术,你可以使用这些技术来绕过安卓系统中的SSL证书检查:

  • ·向受信任的证书存储库中添加一个自定义的证书颁发机构
  • ·用自定义的证书颁发机构的证书覆盖已打包的证书
  • ·使用Frida来钩住(hook)并绕过SSL证书检查机制
  • ·翻转自定义证书代码

在执行方面,这些方法中既有相当简单的,也有非常先进的——这篇博客将试着对每一种方法都进行探讨,而不会纠缠于特定情况的细节。

SSL“中间人”攻击——为什么?

为什么我们需要特别注意移动应用程序的SSL“中间人”攻击的条件?为了查看移动应用程序的web服务调用并使其变得模糊,我们需要使用一个拦截代理服务器,就像BurpSuite或ZAP那样。当使用代理服务器拦截SSL通信时,来自客户端的SSL连接就会在代理服务器上被终止——代理服务器发送的任何表明自己身份的证书都将使移动应用程序认为,代理服务器就是web服务端点。默认情况下,像Burp这样的工具生成的自签名证书不会有有效的信任链,而如果证书不能被验证为可信的,那么大多数移动应用程序将会终止连接,而不会连接到一个可能不安全的通道上。下面这几项技术都有一个共同的目标,那就是说服移动应用程序信任我们的拦截代理服务器所提供的证书。

第一项技术——向用户证书存储库中添加自定义证书颁发机构

避免SSL错误的最简单方法是拥有一个有效的、受信任的证书。如果你可以在设备上安装新的、受信任的证书颁发机构,这就相对容易一些了——如果操作系统信任你的证书颁发机构,它也会信任由该机构颁发的证书。

安卓系统有两个内置的证书存储库,可以跟踪操作系统所信任的证书颁发机构——一个是系统存储库(保存预先安装的证书颁发机构),另一个是用户存储库(保存用户安装的证书颁发机构)。下面是来自developer.android.com网站的观点:默认情况下,来自所有应用程序的(使用诸如TLS和HTTPS这样的协议的)安全连接都信任系统中预先安装的证书颁发机构,而针对安卓6.0(API等级23)及以下版本系统的应用程序还会信任默认情况下用户添加的证书颁发机构存储库。一个应用程序可以使用base-config配置(应用程序范围内的自定义)和domain-config配置(域范围内的自定义)对其本身的连接进行自定义设置。

这对我们来说意味着什么呢?如果我们正在尝试进行“中间人”攻击的目标应用程序适用于安卓6.0或更低版本系统的话,我们就可以直接将我们的证书颁发机构添加到用户证书颁发机构存储库中。当应用程序验证我们的自定义证书的信任链时,它将会发现我们自定义的证书颁发机构在受信任的证书库中,这样我们的证书就会得到信任了。但是,如果该应用程序适用的安卓版本高于6.0的话,那么它就不会信任用户添加的证书颁发机构存储库了。为了解决这个问题,我们可以编辑应用程序的“manifest”文件,并强制它适用安卓6.0系统。目标API的等级是由“AndroidManifest.xml”文件中的“manifest”元素的“platformBuildVersionCode”属性来指定的。

<manifestxmlns:android="http://schemas.android.com/apk/res/android"package="com.test.app"platformBuildVersionCode="25"platformBuildVersionName="7.1.1">

上述“manifest”元素的“platformBuildVersionCode”属性值为25,我们需要把它改为23。

<manifestxmlns:android="http://schemas.android.com/apk/res/android"package="com.test.app"platformBuildVersionCode="23"platformBuildVersionName="6.0">

在修改了“manifest”文件并重新打包这个应用程序后,它将会信任用户添加的证书颁发机构存储库。

另外,如果需要在特定版本的系统上运行的话,我们可以在APK的配置文件“/res/xml/network_security_config.xml”中专门定义一个信任锚点。例如,以下文件定义了一个新的受信任的证书颁发机构,它需要存储在“/res/raw/my_ca”目录下(这个例子来自https://developer.android.com/training/articles/security-config.html):

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>

  <base-config>

    <trust-anchors>

      <certificatessrc="@raw/my_ca"/>

    </trust-anchors>

  </base-config>

</network-security-config>

如果应用程序只是验证所提供的证书是否有效,那么这项技术应该可以让你建立一个成功的“中间人”攻击条件。

第二项技术——用自定义证书覆盖已封装的证书

假如,你成功地将证书安装到用户添加的证书颁发机构存储库中了,应用程序也适用于安卓6.0系统,并且当你尝试浏览其他的在SSL保护下的资源时证书也会显示为有效,但是应用程序仍然会发生SSL错误,那这是怎么回事呢?其实,开发人员可能已经采取了额外的措施来限制应用程序所信任的证书颁发机构库。回想一下上一项技术,我们设置了一个自定义的信任锚点,并为一个证书提供了路径——而这也正是开发人员可以用来保护他们的应用程序不受SSL拦截的方法。

如果一个自定义的证书链正在被一个应用程序分发,那么提取APK文件并使用我们自定义的证书颁发机构覆盖系统所提供的证书颁发机构,就可以使我们用于拦截的证书得到信任。请注意,在某些情况下,可能会对信任链进行额外的验证,因此这种方法可能会产生复杂的结果。

使用APK Studio这样的工具打开APK文件,可以明显地发现与已部署应用程序捆绑在一起的证书。在上面的图片中,证书位于“assets”目录下。用我们自定义的证书颁发机构来覆盖这个非常贴切地被命名为“UniversalRootCA”的证书,应该就可以让我们骗过应用程序使之接受我们的证书了。

第三项技术——Frida钩子

如果安装你自己的证书颁发机构还不足以成功地代理SSL通信,那就说明应用程序可能正在执行某种SSL绑定或额外的SSL验证。通常,为了绕过这种类型的验证,我们需要劫持应用程序的代码,并干扰验证过程本身。这种类型的干扰过去往往被限制在被破解/越狱的手机上,但在Frida小工具的帮助下,现在可以用来控制安卓应用程序,并且可以在没有获得设备root权限的情况下取得完整的Frida功能。

如果你以前执行过移动应用程序渗透测试的话,那么你对Frida框架可能会很熟悉。全面讲解Frida的功能超出了这篇博客的范围,但在更高层次上,它是一个允许你在应用程序运行时篡改其代码的框架。通常来说,Frida将作为一个独立的程序运行在操作系统上——但这需要取得设备的root权限。为了避免这种情况,我们可以把Frida小工具注入到目标APK文件中。Frida小工具包含了Frida的大部分功能,但它被封装在一个动态库中,该库在目标应用程序运行时加载,它允许你对目标应用程序的代码进行控制和修改。

为了加载Frida小工具,我们需要提取APK文件,插入动态库,以及编辑一些smali语言的代码,这样我们的动态库就成为了应用程序启动时第一个调用的东西,然后重新打包APK文件并安装它。这整个过程都被John Kozyrakis详细地记录在这里了,你最好把这个过程手动操作一遍,以便了解这一切是如何共同工作的。不过,为了节省时间,我们还可以使用另一种工具——Objection。这个工具使整个过程自动进行,并且只需要向命令行提供目标APK文件。

C:\ >objection patchapk -s test_app.apk

No architecture specified. Determining it using `adb`...

Detected target device architecture as: armeabi-v7a

Github FridaGadget is v10.6.28, local is v10.6.13. Updating...

Downloading armeabi-v7a library to C:\.objection\android\armeabi-v7a\libfrida-gadget.so.xz...

Unpacking C:\.objection\android\armeabi-v7a\libfrida-gadget.so.xz...

Cleaning up downloaded archives...

Using Gadget version: 10.6.28

Unpacking test_app.apk

App already has android.permission.INTERNET

Reading smali from: C:\Temp\tmp8dxqks1u.apktemp\smali\com/test/app/TestMainActivity.smali

Injecting loadLibrary call at line: 10

Writing patched smali back to: C:\Temp\tmp8dxqks1u.apktemp\smali\com/test/app/TestMainActivity.smali

Creating library path: C:\Temp\tmp8dxqks1u.apktemp\lib\armeabi-v7a

Copying Frida gadget to libs path...

Rebuilding the APK with the frida-gadget loaded...

Built new APK with injected loadLibrary and frida-gadget

Signing new APK.

jar signed.

Signed the new APK

Performing zipalign

Zipaling completed

Copying final apk from C:\Users\cwass\AppData\Local\Temp\tmp8dxqks1u.apktemp.aligned.objection.apk to current directory...

Cleaning up temp files...

在此之后,在我们的工作目录上,应该就有了一个名为“test_app.objection.apk”的文件——默认情况下,objection工具会在原始APK文件名上附加一个“.objection”。我们可以像安装任何其他APK文件一样安装这个APK文件——adb install test_app.objection.apk命令应该会把它推送到我们已连接的设备上。在我们的目标设备上安装了已被objection工具修改过的APK文件之后,运行该应用程序应该会导致其启动时出现暂停。此时,我们可以连接到一个Frida服务器,该服务器应该正在对设备进行侦听。如果你更喜欢使用Frida工具的话,那就这么做:

C:\>frida-ps -U

PID  Name

----  ------

6383  Gadget

 

C:\>frida -U gadget

____

/ _| Frida 10.3.14 - A world-class dynamic instrumentation framework

| (_| |

>_| Commands:

/_/ |_| help -> Displays the help system

. . . . object? -> Display information about 'object'

. . . . exit/quit -> Exit

. . . .

. . . . More info at http://www.frida.re/docs/home/

 

[Motorola Moto G (5) Plus::gadget]-> Java.available

true

另外,Objection工具还支持与Frida侦听服务器之间的交互,这可以通过使用“explore”命令来实现:

C:\>objection explore

___||_  |_|___ ___||_|_|___ ___

| . | . || | -_|  _|_| | . |   |

|___|___|_||___|___|_||_|___|_|_|

|___|(object)inject(ion) v1.2.2

 

Runtime Mobile Exploration

by: @leonjza from @sensepost

 

[tab] for command suggestions

com.test.app on (motorola: 7.0) [usb] # android hooking search classes TrustManager

android.security.net.config.RootTrustManager

android.app.trust.ITrustManager$Stub$Proxy

android.app.trust.ITrustManager

android.security.net.config.NetworkSecurityTrustManager

android.security.net.config.RootTrustManagerFactorySpi

android.app.trust.TrustManager

android.app.trust.ITrustManager$Stub

com.android.org.conscrypt.TrustManagerImpl

com.android.org.conscrypt.TrustManagerImpl$ExtendedKeyUsagePKIXCertPathChecker

com.android.org.conscrypt.TrustManagerImpl$TrustAnchorComparator

com.android.org.conscrypt.TrustManagerFactoryImpl

javax.net.ssl.TrustManagerFactory$1

javax.net.ssl.TrustManager

javax.net.ssl.TrustManagerFactory

javax.net.ssl.X509TrustManager

javax.net.ssl.TrustManagerFactorySpi

javax.net.ssl.X509ExtendedTrustManager

[Ljavax.net.ssl.TrustManager;

此时,你应该能够从内置的绕过SSL绑定的功能中获益:

com.test.appon (motorola: 7.0) [usb] # androidsslpinningdisable

Job: 2f633f86-f252-4a57-958e-6b46ac8d69d1-Starting

[6b46ac8d69d1][android-ssl-pinning-bypass]Custom, EmptyTrustManagerready

Job: 2f633f86-f252-4a57-958e-6b46ac8d69d1Started

第四项技术——翻转自定义证书验证代码

最后,开发人员可能会选择提供他们自己的SSL库,而不是依赖于系统库来处理SSL证书验证。如果是这种情况的话,我们可能需要提取APK文件并将smali语言转换回Java语言,这样我们就可以查找负责处理证书验证的代码了。

使用“dex2jar”命令,语句如下:

C:\>d2j-dex2jar.bat "C:\test_app.apk"

dex2jar C:\test_app.apk -> .\test_app-dex2jar.jar

由此产生的.jar文件应该可以在你所喜欢的Java翻转工具(如JD-GUI)中打开了。

一旦你找到了负责证书验证的代码,你就既可以选择把它完全替换,也可以用Frida工具来钩住你想要的函数。为了避免重新构建整个应用程序,通常来说,只篡改负责证书验证的功能会更加高效。使用第三项技术中的方法可以让你对应用程序进行控制——在那里,你应该能够使用Frida命令行工具或Objection界面来钩住一个函数,你觉得哪个方法好用就用哪个。

结语

上文提到的技术应该可以让你拦截安卓系统的SSL通信了,还可以让你绕过开发人员部署的一些常规的防御手段。此外,这篇博客还简要介绍了Objection和Frida工具——绕过SSL绑定和其它防御的能力仅仅是这两种工具所提供的极多功能中的一小部分。我希望这篇博客能够帮助人们开始了解安卓系统移动应用程序安全测试中的各种技术,并且能够阐明通过多种方法绕过指定的安全机制的重要性。

 

稿源:netspi

一月行业新闻回顾

本月大事件:云厂商漏洞致Let's Encrypt禁用SNI域验证

近日,不少云厂商的都面临着允许签发未经授权的Let's Encrypt证书的控诉。虽说问题出在云厂商,但Let's Encrypt毅然决然地禁用了相应的验证方法。

FransRosén发现他可以使用ACME协议中的SNI验证方法为某些云厂商托管的域颁发证书,并明确提到了Heroku和Amazon CloudFront。

问题的核心在于,这些服务供应商允许用户上传证书,然后系统将自动向具有相应服务器名称的TLS请求提供服务。ACME SNI验证方法使用以.acme.invalid结尾的临时证书。

在问题被曝光后,Let's Encrypt立即禁用了TLS-SNI-01验证方法。Let's Encrypt随后决定,除了少数特例,它将永久禁用。据悉,较新的TLS-SNI-02方法也很脆弱。考虑到这个问题的新的TLS-SNI-03方法正在开发中,目前用户应该切换到HTTP或DNS验证方法。

短新闻回顾

三年有效期SSL证书将于2018年3月1日下架

.......过了这村,你就只买得到两年证书了......

自2018年3月1日起,三年期SSL证书将无法购置。该变化是由证书颁发机构和浏览器厂商论坛CAB Forum制定的。

如果你用了很久的SSL证书,你或许知道以前还有五年期证书。然而随着互联网的发展和加密方式的变迁,每五年换一次证书会让你的网站在各种新型攻击下变得脆弱不堪。

于是为了用户安全,浏览器厂商不断地压缩证书有效期的周期。更新证书是很有必要的,它不仅保证了您的安全实施是最新的,还告诉CA们您的网站仍值得信赖。

虽然缩短证书有效期怎么看都像是CA想让客户多花钱,但成天想着把周期压到90天的却是谷歌。但无论何时,经常性地替换证书从保障安全的角度来说永远都是最重要的。

试想五年前,我们用的密钥套件是哪一款?SHA-1啊!一款被吐槽了N年的不安全的密钥套件。虽说现在所有老证书都不得不由于SHA-1的原因重新签发,但这正应证了本文的观点——越旧的证书越没保障。

需要重现签发证书的另一个原因是CA必须重新验证你。这可以确保您的信息是最新的,并且您仍然有权为您的域名颁发证书。 请记住,浏览器正在向用户表明他们可以信任与您的网站的连接,因为您已经受到可信第三方的审查。 就像驾驶执照一样,您偶尔也必须与第三方办理登机手续,以确保所有内容都是最新的。

所以,从3月1日开始,两年是您使用任何SSL证书所能获得的最长使用期限。 这一改变不影响EV证书,因为介于EV SSL收到的信任级别(唯一的绿色指标),两年本就是其最高年限。

具体的办法如下:

  • 如果您的SSL证书在2018年3月1日前签发,您的证书有效期将不受影响
  • 所有2018年3月1日之后签发的证书,最高有效期仅2年(825天)
  • DV和OV证书只能用825天

过了825天,CA 要重新对你进行验证。而且这也是追溯性的,所以无论你现在的证书是多么旧,它都是在825天内计算的。 由于日期将近,验证过程中涉及的时间可能有所增加,因为CA将被迫更频繁地重新验证。

什么情况下需要重新签发证书呢?

  • 给证书添加新域名的时候
  • 给证书移除老域名的时候
  • 给证书换一个域名的时候
  • 更改组织信息的时候
  • 证书发重的时候

如果您正计划在接下来的三年里做以上的调整,换一张两年期证书并及早更新它即可。

最后,CAB论坛还有一些关于删除某些域名控制验证方法(如Whois查询)的喋喋不休的问题。有兴趣的读者可戳https://cabforum.org/ 查看。

 

稿源:The ssl store

DigiCert将于2月1日开始记录SSL证书

证书透明制将于2018年4月变为强制。

从2018年2月1日其,DigiCert将默认把所有新签发的SSL证书提交到证书透明制记录中。

Clint Wilson,DigiCert技术部产品经理在博客中透露了这项决定的细节:

为了提高我们客户的安全性和鼓励采用,我们正在进行这项改变,使之超越Google在2018年4月生效的整个行业要求。自2015年以来,CT logging只是对EV证书的要求。

这项改变将自动从2月1日起执行。您自该日起及以后的所有由DigiCert签发的证书都将成为“SCTs”——签名证书时间戳的一部分。

这些内容直接嵌入到证书中,并告诉客户端软件(如Web浏览器)证书已被记录。 当谷歌浏览器在四月份开始执行CT合规时,您的证书将已经兼容。 除非您不希望记录您的证书,否则您不需要执行任何操作。

该举措将只影响DigiCert证书。赛门铁克品牌旗下的产品(如:Symantec, RapidSSL, GeoTrust和Thawte)已在早前应谷歌要求记录所有新证书。

什么是证书透明制?

证书透明制是一个日志机制,用于通过增加透明度层的方式帮助强化PKI,并且有助于发现误签发证书。简单来说,从2018年3月开始,每个认证机构都需要记录每个公开信任的SSL证书。 证书将被记录在公共数据库(日志),证书可以很容易地被搜索和监控。如此,又能使网站所有者能够看到为其域名颁发的全面证书列表,从而更好地监督CA的活动。

如果证书没进入日志该怎么办?

从2018年4月开始,所有新颁发的证书将被要求记录。 如果您的证书是在2018年4月之前发布的,那么将不会有任何处罚。 但是,如果您的证书是在截止日期之后发出的,并且没有出现在CT日志中,则它将被视为自签名或过期证书。 也就是说,它会收到浏览器警告。

 

稿源:The ssl store

Cloudflare: 为什么TLS 1.3还没有部署在浏览器中?(二)

Cloudflare: 为什么TLS 1.3还没有部署在浏览器中?(一)

引入一个新版本

为兼容未来而设计一个协议是非常困难的,因为如果没有反馈机制,那么很容易犯错误。这是TLS版本协商的例子:如果你部署错误的话,除了假想的未来版本,不会有任何问题发生。这样,对于开发人员来说,没有任何迹象表明这一部署是有漏洞的,因此可能没有人会注意到错误的发生。也就是说,直到部署了新版本的协议并且你的实现失败之前,你都不会注意到,但是到那个时候,已经部署了代码,并且每个人都需要花费数年的时间来升级。实际上,一些服务器未能正确处理“未来”的TLS版本的情况应该是在意料之中的。

TLS的版本协商机制尽管简单,但实际上它是协议设计反模式的一个例子。它演示了一种所谓“僵化”的协议设计。如果一个协议是用一个灵活的结构设计的,但是这种灵活性在实践中从来没有被使用过,那么一些部署就会假定它是永远不变的。Adam Langley将这一现象与生锈相比较。如果你很少打开一扇门,那么它的铰链就很可能会生锈。TLS的协议协商机制就是这样的铰链。

大约在TLS 1.2部署的时候,围绕设计一个雄心勃勃的新版本TLS的讨论开始了。人们准备将它称为TLS 1.3,而版本号选择的自然是3.4(或(3,4))。到2016年年中,TLS 1.3草案已经经过了15次迭代,版本号和协商机制基本上都已经设计好了,在这个时候,浏览器已经消除了不安全的回退。人们假定,那些未能正确执行TLS版本协商机制的服务器已经吸取了POODLE漏洞的教训,并最终正确地实现了版本协商。但事实却并非如此。又一次地。

当收到3.4版本的问候信息时,大部分支持TLS 1.2的服务器会断开连接,而不是以3.3进行响应。Hanno Böck、David Benjamin、SSL Lab团队和其他一些人进行的互联网测试证明,TLS 1.3的失败率很高,在许多测试中超过了3%。这与升级到TLS 1.2时所面临的情况完全相同。历史重演了。

这一意想不到的挫折为参与协议设计的人员带来了一场危机。浏览器不希望重新启用不安全的降级以致于在接下来的5年里再次为协议协商而面临艰苦的工作。但是,如果不降级,使用TLS 1.3将会为了这些用户而破坏互联网的3%。我们能做什么呢?

有争议的选择是,接受David Benjamin的建议,使第一个TLS 1.3消息(客户端问候信息)看起来像是TLS 1.2。客户端的版本号被更改为(3,3),并引入了一个新的“版本”扩展,其中包括所支持的版本列表。如果服务器支持TLS 1.3(3,3)或更早版本的话,那么它将返回一个这样的服务器问候信息(3,4)。在TLS 1.3的16号草案中,包含了这个新的“改进”的协议协商逻辑。

这个机制可以正常运转。大多数服务器对这种更改都能兼容,并能轻易退回到TLS 1.2,从而忽略了新的扩展。但这并不是故事的结局。僵化是一种变化无常的现象。它不仅影响客户端和服务器,而且还影响到与协议进行交互的网络上的一切。

现实世界中有太多的中间设备

我们博客的读者们可能还记得今年早些时候的一篇关于HTTPS拦截的文章。在这篇文章中,我们探讨了一项研究,它测量了现实中有多少“安全”的HTTPS连接被处于浏览器和web服务器之间的某个地方的监听软件或硬件所拦截并解码。也有一些被动式检查的中间设备,用来解析TLS协议,并阻止或转移那些基于可见数据的连接,例如那些使用TLS连接中的主机名信息服务(服务器名称指示)来阻止“被封禁”网站的互联网服务提供商(ISP)。

为了检查流量,这些网络设备需要部分或全部实现TLS。支持TLS的每一个新设备都引入了一个TLS实现,该实现可以假定协议应该如何执行。有越多的实现,就越有可能出现僵化现象。

在2017年2月,Chrome和Firefox两个浏览器都开始为他们的一部分客户提供TLS 1.3支持。结果出乎意料地可怕。与预期相比,TLS 1.3连接的失败比例要高得多。那么对于一些用户来说,情况就是:不管访问的是什么网站,TLS 1.2都可以正常运转,但是TLS 1.3却不行。

TLS 1.3的18号草案的成功率如下:

Firefox浏览器访问Cloudflare,

TLS 1.2成功率为97.8%,

TLS 1.3成功率为96.1%。

Chrome浏览器访问Gmail,

TLS 1.2成功率为98.3%,

TLS 1.3成功率为92.3%。

经过一些调查,发现一些被广泛部署的中间设备,无论是主动拦截还是被动检查,都会导致连接失败。

由于TLS协议在其整个历史上大体都是一样的,因此一些网络设备对该协议怎样随时间变化做出了假设。而当面对一个突破了这些假设的新版本时,这些设备就会遭遇不同方式的失败。

在TLS 1.3中改变的一些TLS特性仅仅是表面上的。例如,自从SSLv3被移除之后,ChangeCipherSpec、session_id以及压缩字段之类的东西就成为了协议的一部分。人们认为,这些字段对于一些中间设备来说成为了TLS的基本特性,而移除它们会导致连接失败情况的激增。

如果使用一个协议的时间足够长,并且具有类似的格式,那么围绕该协议构建工具的人们会假设该格式保持不变。这通常不是开发人员有意的选择,而是在实践中使用协议的意外结果。网络设备的开发人员可能并不理解互联网上使用的每个协议,因此他们经常测试他们在网络上看到的内容。如果一个原本应该很灵活的协议有一部分内容在实践中一直没有改变,那么就会有人认为它永远不会改变。而这很可能会实现更多的部署。

把所有的责任都推给这些中间设备的具体实现者是虚伪的。是的,他们创建了错误的TLS实现,但是如果我们换一种方式思考的话,其中TLS设计的本意就很容易导致这种失败。是实现者来实现协议的本质,而不是协议设计者的意图或规定文本来实现。在复杂的生态系统中,有多个实现者,那么未使用的节点就会“生锈”。

去除那些20年来已经成为了的协议的一部分的特性并且期望它仍然继续正常工作是一种痴心妄想。

让TLS 1.3正常工作

上个月在新加坡举行的IETF会议上,为了解决这一问题,针对TLS 1.3提出了一项新的更改。这项更改是基于Facebook公司的Kyle Nekritz的一个想法:让TLS 1.3对于中间设备看起来像TLS 1.2。这项更改重新引入了被删除的协议的许多部分(session_id、ChangeCipherSpec、一个空压缩字段),并引入了一些其它的更改,这使得对于那些存在缺陷的中间设备来说,TLS 1.3无论从哪个方面看起来都像是TLS 1.2。

这些更改的几次迭代是由BoringSSL公司开发的,并在Chrome浏览器中进行了几个月的测试。Facebook公司也进行了一些类似的实验,这两支团队对同一组更改进行了试验。

Chrome浏览器试验成功率:

TLS 1.2成功率为98.6%

试验更改(Github的PR1091)成功率为98.8%

Firefox浏览器试验成功率:

TLS 1.2成功率为98.42%

试验更改(Github的PR1091)成功率为98.37%

这些试验表明,可以修改TLS 1.3,使其与中间设备兼容。它们也显示出僵化现象。正如我们在前一节中所描述的,在客户端问候信息中,唯一可能会“生锈”的东西——版本协商——的确“生锈”了。这导致了16号草案的产生,该草案将版本协商转移到一个扩展上。作为客户端和服务器之间的中间层,中间设备也关心服务器的问候信息。这条信息有更多的“铰链”,它被认为是灵活的,但事实证明并非如此。几乎所有的这些都已经“生锈”了。新的“对中间设备友好”的更改将这一现实考虑在内。这些试验的更改被加入到TLS 1.3的22号草案的规定中。

确保这种问题不会再次发生

原始的协议协商机制已经被不可恢复地毁坏了。这意味着它可能无法在未来某个版本的TLS中使用而不会有严重的破坏。然而,许多其它的协议协商特性仍然是灵活的,例如密码套件的选择和扩展。保持这样的状态是非常棒的。

去年,Adam Langley写了一篇非常好的博客(https://www.imperialviolet.org/2016/05/16/agility.html),是关于加密协议设计的,和本文探讨的领域类似。在这篇文章中,他提出了这样一句格言:“只要有一个节点,就要让它保持润滑。”这对协议设计者来说是一个很好的建议。僵化现象是真实存在的,就像我们在TLS 1.3中看到的那样。

沿着这条路线,David Benjamin提出了一种方法,使那些最重要的节点始终保持润滑。他对TLS的润滑建议是,在协议应兼容新的值的地方,设计出随机抛出的值。如果主流实现在实际的部署中散布未知的密码、扩展和版本,那么实现者将不得不正确地处理它们。这种润滑就像是互联网上的WD-40润滑剂一样。

需要注意的一点是,润滑的目的是防止服务器僵化,而不是中间设备,因此在TLS中仍有可能出现更多类型的润滑。

即使是使用了润滑剂,人们还是发现,直到2017年12月,有一些服务器仍然对TLS 1.3不兼容。润滑剂只能识别那些对未知扩展不兼容的服务器,但是一些服务器可能仍然不能兼容特定扩展的id。例如,RSA的BSAFE库使用了扩展id 40来进行一个名为“extended_random”的试验性扩展,它与一个理论上的NSA后门有关。扩展id 40恰好是TLS 1.3密钥共享所使用的id。David Benjamin报告说,这个库仍然被一些打印机所使用,这使得它们无法兼容TLS 1.3。Matthew Green对这个兼容性问题进行了详细的描述。

帮助我们理解这个问题

Cloudflare公司一直在与Mozilla Firefox浏览器团队合作,以帮助测试这一现象,谷歌公司和Facebook公司也一直在做自己的测试。这些试验很难进行,因为开发人员需要将协议的变体引入到浏览器中,这可能导致用户需要花费浏览器的整个发布周期的时间(通常是几个月)才能看到问题。Cloudflare现在(有希望)支持最新的兼容中间设备的TLS 1.3草案版本(22号草案),但我们总是有可能找到一个与这个版本不兼容的中间设备。

为了避开浏览器的发布周期,我们走了一个捷径。我们建立了一个网站,通过这个网站,你可以站在浏览器的角度来查看TLS 1.3是否正常工作。这个测试是由我们的密码学实习生Peter Wu开发的。它使用Adobe Flash,因为这是唯一一种广泛应用的跨平台的可以从浏览器访问原始套接字的方式。

它是这样工作的:

  • 我们将我们的基于golang的TLS 1.3客户端库(TLS-tris)交叉编译为JavaScript;
  • 我们构建了一个JavaScript库(称为jssock),它通过Adobe Flash在底层的套接字接口网络上实现了tls-tris;
  • 我们使用TLS 1.2和TLS 1.3连接到远程服务器,并比较结果。

如果存在不匹配的情况,Cloudflare将从连接的两端收集信息并将其发送回去以进行分析。

我们非常期待浏览器能默认启用TLS1.3。这个实验有望帮助证明,最新的技术将是用户的升级更安全!

 

稿源:Cloudflare

Cloudflare: 为什么TLS 1.3还没有部署在浏览器中?(一)

在像互联网这样复杂的生态系统中升级安全协议是很困难的。你需要更新客户端和服务器,还要确保两者之间的所有设施都能继续正常运转。目前,互联网正处于这一升级过程之中。传输层安全(TLS)协议是一种确保web浏览机密性的协议(但许多人仍然坚持使用SSL)。目前,TLS协议正在经历其诞生以来的第一次重大修改。去年,Cloudflare公司成为第一个在服务器端默认支持TLS 1.3的主要供应商商。我们期待客户端供应商们也会紧随其后,在所有主流浏览器中支持该版本。但是,自Cloudflare公司的TLS 1.3发布以来,已经有一年多的时间了,还没有一个主要浏览器默认启用了TLS 1.3。

简单来说,还没有部署TLS 1.3的原因就在于中间设备:即那些用于监控和(有时用于)拦截企业环境和移动网络中的HTTPS通信的网络设备。其中一些中间设备错误地部署了TLS 1.2,而现在,这正在阻止了各大浏览器发布支持TLS 1.3的版本。然而,仅仅指责网络设备供应商就太虚伪了。这件事情的深层真相是,最初设计TLS 1.3的时候,它与互联网长期以来的发展方式并不兼容。本文将深入探讨产生这个问题的原因和过程。

为了给这次讨论提供数据支持,Cloudflare编写了一个工具,可以检查你的网络是否与TLS 1.3兼容:

https://tls13.mitm.watch/

版本协商机制过去是如何在TLS中工作的

传输层安全协议(TLS)是使HTTPS实现安全web浏览的主力。TLS协议是由上世纪90年代后期的安全套接层协议(SSL)改写而来的。TLS协议目前有三个版本:1.0、1.1和1.2。该协议非常灵活,可以以不同的方式发展。较小的更改可以合并为“扩展”(例如OCSP和证书透明系统),而更大的、更基础性的更改通常需要发布一个新版本。到目前为止,TLS 1.3是该协议有史以来最大的变化,完全改变了原有的加密方式,并引入了0-RTT等特性。

并不是每个客户端和服务器都支持同一版本的TLS协议,这使得升级协议变得不可能——因此大多数主机同时支持多个版本。为了在连接时上使用同一版本的协议,客户端和服务器必须协商一致。TLS协议版本的协商非常简单。客户端将其支持的协议的最新版本告知服务器,而服务器则以双方都支持的协议最新版本最新版本进行应答。

TLS协议的版本用两个字节的值表示。由于TLS是由SSLv3改写而来的,所以从字面上看,TLS协议中只有次级版本号增加了:

SSLv3是3.0版本,

TLS 1.0是3.1版本,

TLS 1.1是3.2版本,

TLS 1.2是3.3版本,等等。

当使用TLS协议连接到服务器时,客户端在连接开始时发送其所支持的最高版本:

(3, 3) → server

一个支持相同版本协议的服务器回复一条以相同的两字节版本号开始的消息。

(3, 3) → server

client ← (3, 3)

或者,如果服务器只支持旧版本的协议,它可以用旧版本进行回复。例如,如果服务器只能支持TLS 1.0,那么它就可以这样回复:

(3, 3) → server

client ← (3, 1) 

如果客户端支持由服务器返回的协议版本,那么双方将继续使用该版本的TLS协议,并建立一个安全连接。而如果客户端和服务器没有共同支持的版本,那么连接将会失败。

这次协商的目的是为了兼容未来。如果客户端发送的协议版本比服务器所支持的版本要高,那么服务器应该仍然可以以其支持的任何版本来回应。例如,如果一个客户端发送(3,8)到一个支持TLS 1.2的服务器,那么该服务器应该只会返回(3,3),并仍然按照TLS 1.2协议进行握手。

很简单,对吧?但实际上,有些服务器并没能正确地实现这一点,而这导致了一系列事件,这些事件让web用户暴露在严重的安全漏洞之下。

POODLE漏洞与降级之跳

对TLS的最后一次重大升级是引入了TLS 1.2。在TLS 1.2部署到浏览器的过程中发现,某些TLS 1.0服务器没有正确地完成版本协商。当一个以TLS进行连接的客户端宣布支持TLS 1.2的时候,有缺陷的服务器将会断开连接,而不是与客户端协商一个它所支持的TLS版本(如TLS 1.0)。

浏览器处理这种情况可以有三个选择:

  1. 启用TLS 1.2,这样将会有一部分网站将停止工作;
  2. 延迟TLS 1.2的部署,直到这些有缺陷的服务器被修复;
  3. 如果连接失败,则使用旧版本的TLS重试。

人们对浏览器的一个期望是,当它们进行更新时,网站会正常工作。但是,有缺陷而导致一更新就崩溃的服务器数量太多了,所以第1个选项被排除了。到现在为止,TLS 1.2已经发布一年时间了,,然而服务器的问题仍未能解决,而继续等待看起来也不会解决这个问题,所以第2个选项也被排除了。这使得第3个选项成为了唯一可行的选择。

为了启用TLS 1.2,同时使它们的用户满意,大多数浏览器都部署了所谓的“不安全降级”。当浏览器连接到一个站点时,如果遇到连接失败的情况,它们会再次尝试使用TLS 1.1,然后尝试TLS 1.0,如果再失败,则尝试SSLv3。这种降级逻辑“修复”了这些有缺陷的服务器······但其代价是建立的连接速度很慢。

然而,不安全降级之所以称为“不安全”是有原因的。客户端降级是由一种特定类型的网络故障触发的,这种故障很容易伪装。从客户端的角度来看,没有办法判断这个故障是由一个有缺陷的服务器引起的,还是由一个刚好处于该网络所在的网络路径上的黑客的攻击所造成的。这就意味着,即使服务器和客户端都支持新的协议版本,网络攻击者也可以注入虚假的网络故障,诱骗客户端来使用SSLv3连接到服务器。在这个时候,SSLv3协议中并没有已公开的严重漏洞,所以这看起来并不是一个大的问题。然后POODLE漏洞发生了。

2014年10月,Bodo Möller公布了POODLE漏洞,这是SSLv3协议中一个严重的安全漏洞,它允许网络内的攻击者能够毫不费力地披露网络中的加密信息。因为TLS 1.0协议已经在客户端和服务器上都被广泛部署,所以在web上只有很少的连接使用SSLv3协议,这本应能够确保它们的安全。但是,不安全降级功能使得攻击者可以在客户端和服务器双方都支持SSLv3协议的情况下(大多数情况下都支持)将任何连接降级到SSLv3。这一“降级之跳”,将POODLE漏洞从一件奇闻变成了可能影响大部分网络的严重漏洞。

修复POODLE漏洞,消除不安全降级

对POODLE漏洞的修复是:

  1. 在客户端或服务器端禁用SSLv3协议;
  2. 启用一个名为SCSV的新的TLS功能。

在POODLE漏洞被发现之前的几个月,Adam Langley和Adam Langley顺便提出了SCSV。简单地说,当由于网络错误而需要重新尝试连接时,客户端通过SCSV将一个名为“降级金丝雀”的指示器添加到它的客户端问候信息中。如果服务器支持的协议版本比客户端问候信息中发布的版本更高,服务器就会查看这个指示器,服务器可能会假设降级攻击正在发生,并关闭这个连接。这是一个很好的功能,但它不是必选的,并且需要客户端和服务器都进行更新,这使得许多web用户仍然暴露在风险之中。

浏览器立即取消了对SSLv3的支持,除了对一些只支持SSLv3的网站造成影响之外,几乎没有什么别的影响。使用旧版浏览器的用户必须依赖web服务器来禁用SSLv3。Cloudflare公司立即为其客户做了这一工作,而大多数网站也是如此,但是根据SSL Pulse的数据,即使是在2017年年末,仍有超过10%的网站继续支持SSLv3。

关闭SSLv3对于解决POODLE漏洞来说是个可行的方案,因为SSLv3对互联网来说并不重要。这就提出了一个问题:如果在TLS 1.0中存在严重的漏洞,那么会发生什么事?TLS 1.0目前仍然被广泛使用和依赖,在浏览器中禁用它将会把大约10%的用户拒之门外。另外,尽管对于解决不安全降级的问题,SCSV是一个很好的方案,但许多服务器并不支持这一功能。在TLS 1.0中,确保用户安全的唯一选项是禁用不安全的回退。

对于大多数没有正确部署版本协商机制的网站来说,客户端不得不多次重新连接,这样的糟糕表现持续了数年时间,现在这些网站已经修复了它们的服务器。这使得一些浏览器能够消除这种不安全的回退:

Firefox浏览器和Chrome浏览器分别在2015和2016年解决了这个问题。因此,当面对目前出现的新的TLS 1.0漏洞时,这两个浏览器的用户处于更安全的位置。

 

稿源: Cloudflare

十二月行业新闻回顾

本月大事件:暴雪、电子艺界、微软等接连发生私钥暴露

近日,不少软件供应商被曝在他们的软件中发送用于数字证书的私钥。这一做法会导致安全漏洞。一旦私钥被发现,将会不可避免地导致证书的撤销。这些案例包括暴雪的战网,电子艺界的Origin,微软的Dynamics 365 for Operations,以及德国官方律师通信软件beA。当软件需要运行本地HTTPS服务器,这种情况就会发生,通常是为了允许让网页和本地软件进行通信。

暴雪捆绑战网的证书和密钥

Tavis Ormandy发现,暴雪的battle.net软件嵌入了由GoDaddy签署的localbattle.net域名证书。该域指向本地IP 127.0.0.1。由于软件在本地运行HTTPS服务器,这自动意味着软件必须包含私钥。因此这种情况被认为是一个密码泄露问题。根据基准要求的证书颁发机构的一套规则,如果向证书颁发机构报告密钥泄漏,证书必须在24小时内撤销。

除了密码泄露,这种证书也可以允许攻击。中间人攻击者可以通过改变战网的DNS回复来将连接重定向至攻击者控制的服务器。由于攻击者可以从软件中提取证书和私钥,所以他可以冒充该服务器。

在证书被撤销之后,暴雪改变了battle.net在本地生成了一个证书,该证书被导入到系统的证书库中。由于私钥是在每个系统上随机生成的,所以如果执行得当,这是一个可接受的解决方案。然而,在Reddit上的一个帖子中,许多用户错误地将新安装的根证书理解为安全风险。

随后,暴雪客户端的另一个由Digicert签名的localbattle.net嵌入式有效证书也被发现。在某些情形下,即使初始修复已完成,这个证书仍会被使用。作为另一个密码泄露问题,该证书再次被撤销。

电子艺界也为其Origin软件使用了一个公开信任的证书,用于clienttolocalhostonly.com域。该证书现已被撤销,该软件使用HTTP连接而不是HTTPS。

在这两种情况下,软件都试图使用公开信任的证书创建本地HTTPS服务器。这是不可接受的。最近,W3C同意了一个可能的解决方案:浏览器可以考虑连接到安全上下文的本地IP 127.0.0.1部分,即使它们是通过HTTP创建的。这不会造成安全问题,因为到本地IP的连接永远不会通过任何网络。 Firefox和Chrome已经支持这个功能。

HTTPS中间人攻击对抗所有德国律师

Markus Drenger在圣诞节前几天发现,德国联邦酒吧(Bundesrechtsanwaltskammer,BRAK)提供的通讯软件有一个非常类似的问题。Besondere elektronisches Anwaltspostfach (beA),直译为“特殊电子律师信箱”,是由Atos公司开发的。其web界面与bealocalhost.de域指向127.0.0.1,TeleSec为该域颁发了一个证书。

按道理说,所有的德国律师都必须在1月1日前用上beA,但这个软件到现在都没法用。该证书撤销后,德国联邦律师事务所试图提供一个快速解决方案,并为bealocalhost.de创建了一个自签名的根证书。律师被要求将这个证书导入当地的根证书商店。然而这一做法让事情变得更糟。因为这是一个私钥是软件的一部分的根证书,它允许任何人可以任意为该域名签发证书。攻击者甚至可以假装谷歌来实施中间人攻击,而所有德国律师都被要求安装该证书。

这个问题在德国媒体Golem.de被登载后,德国联邦酒吧立即关闭了该系统。从那时起一直处于离线状态。值得指出的是,捆绑证书不是beA唯一的安全问题:软件也有一个端到端的加密问题,服务器仍然容易受到ROBOT攻击。

毫无疑问,Atos摊上大事了......

远程登录到Dynamics 365允许提取通配符证书的私钥

微软的Dynamics 365 for Operations发生了另一个稍微不同的情况,即公开信任的证书的私钥被泄露。软件开发人员Matthias Gliwka发现,Dynamics 365的沙箱实例使用通配符证书来提供Web界面。客户可以使用rdesktop协议登录到他们的实例,因而Gliwka能够提取私钥。

在几个月的时间里,微软忽略了Gliwka的报道。然而,在自由新闻工作者Hanno Böck了解到这个案例之后,Mozilla和负责的认证机构Digicert都被告知。此后,微软被迫迅速解决这个问题。证书已被吊销,Dynamics 365的新实例为每个实例使用单独创建的证书。

短新闻回顾

稿源: Feisty duck