tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: officially signed packages

On Apr 7, 2014, at 23:25 , Fredrik Pettai <> wrote:
> On Apr 7, 2014, at 22:51 , Thomas Klausner <> wrote:
>> On Mon, Apr 07, 2014 at 05:50:53PM +0200, Alistair Crooks wrote:
>>> Personally, I would never trust a CA-signed cert for this use case,
>> I'm probably missing something, but what's the problem with including
>> one CA root certificate with pkgsrc, created by TNF, and certifying
>> bulk builders with it?
> I think he rants at the commercial CA industry.
> Anyway, read the paper, it seems none of the open source implementation 
> (which are the most popular ones) they tested managed to handle all the 
> different certificate parameters correct for all given situations…

TL;DR version:

We design, implement, and apply the first methodology for large-scale testing 
of certificate validation logic in SSL/TLS implementations. Our first 
ingredient is "frankencerts," synthetic certificates that are randomly mutated 
from parts of real certificates and thus include unusual combinations of 
extensions and constraints. Our second ingredient is differential testing: if 
one SSL/TLS implementation accepts a certificate while another rejects the same 
certificate, we use the discrepancy as an oracle for finding flaws in 
individual implementations.

Differential testing with frankencerts uncovered 208 discrepancies between 
popular SSL/TLS implementations such as OpenSSL, NSS, CyaSSL, GnuTLS, PolarSSL, 
MatrixSSL, etc. Many of them are caused by serious security vulnerabilities. 
For example, any server with a valid X.509 version 1 certificate can act as a 
rogue certificate authority and issue fake certificates for any domain, 
enabling man-in-the-middle attacks against MatrixSSL and GnuTLS. Several 
implementations also accept certificate authorities created by unauthorized 
issuers, as well as certificates not intended for server authentication.

We also found serious vulnerabilities in how users are warned about certificate 
validation errors. When presented with an expired, self-signed certificate, 
NSS, Safari, and Chrome (on Linux) report that the certificate has expired — a 
low-risk, often ignored error — but not that the connection is insecure against 
a man-in-the-middle attack.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Home | Main Index | Thread Index | Old Index