[关闭]
@EricaHe 2015-12-17T06:01:21.000000Z 字数 3979 阅读 915

Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations

论文笔记 SSL


作者:Chad Brubaker、Suman Jana、Baishakhi Ray、Sarfraz Khurshid、Vitaly Shmatikov

单位:Google、The University of Texas at Austin、University of California, Davis


Abstract & Introduction

论文开发了一种叫做Frankencert的工具,可以自动对SSL/TLS实现的证书认证进行测试。

方法:
1. 随机生成Frankencert——从真实的证书中随机构造生成的一种证书,可以保证语法正确,并且涵盖了各种常见或非常见的extensions和constrains
2. differential test——将生成的Frankencert发送给不同的SSL/TLS实现,如果有实现的表现与其他不同,则可预测此处或许存在问题。

困难:
1. 生成测试证书
证书结构复杂,难以随机生成,或人工制造大量的测试样本,而且对于测试而言,一些在日常使用的证书中不太常见的可能也需要一并考虑在内,以防攻击者伪造证书进行攻击。
2. 解释测试结果
仅仅根据SSL/TLS实现的是否接受一张证书,并不能确切地说明此处发生了什么样的问题,所以自动化测试还要求程序能够正确分析出该实现接受或拒绝一张证书的原因。


Generating Frankencert

Key Challenge:
1. 生成能够被解释的X.509证书
2. 生成的证书要包含有极少或从不在正常证书中出现的部分

由于收集得到的证书都是X.509证书,所以为了测试SSL/TLS实现在面对其他证书时的表现,还另外加了一些证书。

Generating Frankencert

Frankcert生成过程:
随机从证书集中抽取一些证书的一部分来构成证书,除了RSA密钥以及Issuer,这两者是另外赋值的,从而使得Frankencert可以被当做一张中间证书来使用。每张Frankencert的Issuer域必须等于当前证书链中更高一级的证书对象。

从下面的伪代码中可以看出其生成过程。

生成一张Frankencert
生成证书链
获得所有扩展

证书扩展的确定过程:

  1. 确定该张证书存在随机数个扩展
  2. 对每一个扩展,从证书集中随机找一个该扩展的值,赋给当前Frankencert。无论该扩展是否常见,都应等概率地出现在Frankencert中。

一些参数:
1. 用了2个CA作为信任根,各自有一张X.509 version1和X.509 version3证书。
2. 每个证书链包含0-3个Frankencert。然而尽管证书链的构造是无误的,依然有可能会由于一些中间证书的随机内容而被SSL/TLS实现拒绝,例如一张中间证书的keyUsage扩展被标记为keyCertSign。

Generating synthetic mutations

目的:测试SSL/TLS实现在面对符合X.509的ASN.1语法,却不符合X.509规范的证书时是如何表现的。

方法:
1. 获得一张Frankencert中所有扩展的critical bit和extension value
2. 针对每一个extension value,将其替换为一个随机的ASN.1字符串,并可能会将一个空字符插入其中
3. 随机将扩展标记为重要的或不重要的


Testing

通过Frankencert Generator,作者共产生了8127600份Frankencert,发现了208个SSL/TLS实现错误,由62022份Frankencert触发。

Differential Test

如果一份Frankencert引发了SSL/TLS实现间的不同反应,程序就会将该证书进行分类。例如,如果A接受了这份证书,B报出了错误34,C报出了错误1,那么该证书就会被分类到0-34-1这一分类下。
当所有的错误都被发现后,就需要对其进行人工检查,去查看其源代码并分析原因。但并不是每一个错误都一定存在安全漏洞,因为X.509的确有一部分并没有明确规定,而是交由实现自身去进行判断。
这种测试方法应该不存在误报率,但会存在漏报。比如在GnuTLS中存在一个漏洞,由语法上存在问题的证书引发的——这就不会被Frankencert检测到,因为Frankencert都是遵循X.509语法的。同样,在所收集到的证书集中不存在的扩展漏洞自然不会被检测到。


Result

通过找到的208个错误中,作者分析并将其归并为15个造成该错误的根本原因,如下表所示。

Result

A.Incorrect checking of basic constraints

  1. Untrusted version 1 & 2 intermediate certificate
    由于在X.509 version 3之前,是没有基础约束的,所以如果没有外部另外的检查的话,X.509 version 1证书(或verison 2)应该被拒绝。然而MatrixSSL和GnuTLS都接受了包含version 1(或2)证书的证书链。
  2. Version 1 certificate with valid basic constraints
  3. Intermediate CA not authorized to issue further intermediate CA certificates
    高一级的证书可以通过pathLenConstraint域来规定它之后可以跟随多少个中间证书,所以之后的所有证书都不能让这个path length变得更长,从而即便之后的证书中出现了伪装的证书,这一限制也能在一定程度上起到保护的作用。然而,MatrixSSL忽视了对path length的检查。还有另一种情况,一张path length为0的中间证书后跟了一张叶子证书,而这张叶子证书也是一张CA证书,按照X.509的标准,这是可以接受的,但只有GnuTLS和MatrixSSL接受了这一证书——即在这一部分,真正完全正确实现的只有GnuTLS。

B.Incorrect checking of name constraints

上级CA可以限制下级CA的签发域名范围,但是GnuTLS、MatrixSSL和CyaSSL忽略了这一步的检查。

C.Incorrect checking of time

X.509都有notBefore和notAfter的时间戳,但PolarSSL忽视了notBefore时间戳的检查,而当检查notAfter时,它用了当地时间,而不是GMT或任何指定的时区。

D.Incorrect checking of key usage

  1. CA certificate not authorized for signing other certificates
    所有用于证书链中的CA证书,必须在其key usage中包含keyCertSign。而GnuTLS、CyaSSL和MatrixSSL没有对CA证书的key usage扩展做检查,使得攻击者可以使用任意无关的CA key来伪造证书。
  2. Server certificate not authorized for use in SSL/TLS handshake
    PolarSSL、GnuTLS、CyaSSL和MatrixSSL没有对叶子证书的key usage扩展做检查,使得本身只是用于做认证代码的证书可以伪装成服务器来欺骗使用了这些库的用户。
  3. Server certificate not authorized for server authentication
    PolarSSL、GnuTLS、CyaSSL和MatrixSSL没有检查extended key usage扩展。如果一张证书在key usage中允许一切操作,而在extended key usage中只允许做TLS客户端的认证(或除了服务器认证外的任何用处),这些库将会允许其用于服务器认证。

E.Other discrepancies in extension checks

  1. Unknown critical extensions
    如果一个被标记为重要的扩展并不能被识别的话,应该拒绝该证书。而GnuTLS、CyaSSL和MatrixSSL接受了它们。
  2. Malformed extension values
    一个非重要的扩展,如果其值语法正确,但却是非法的,那么应该拒绝该证书。OpenSSL、GnuTLS、CyaSSL和MatrixSSL接受了。
  3. Inconsistencies in the definition of self-signed
    如果一份证书是自签名的,却带有合法的证书链,GnuTLS和MatrixSSL会接受这张证书。
  4. Inconsistencies between the certificate's Authority Key Identifier and its issuer
    AKI(Authority Key Identifier)扩展旨在区别由同一个签发者签发的不同证书。然而,如果一个具有AKI扩展的、由A签发的证书,其AKI指明该证书由B签发,一些库接受了,另一些则拒绝了。
    当AKI扩展的序列号域为空时,GnuTLS会接受这张证书。但如果该域不为空,且不符合签发者的序列号时,GnuTLS将拒绝该证书。

F. "Users...don't go for the commercial CA racket"

G.Security problems in error reporting
E:Expired
I:Bad issuer
N:Bad name
此处输入图片的描述

H.Other checks

  1. Weak cyrptographic hash functions
    MD5证书——前缀碰撞攻击
    此处输入图片的描述
  2. Short keys
    只有Opera对512位的RSA密钥做出了提示。
  3. Additional checks
    additional checks
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注