[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <81EA1BCE-3C7A-4CBE-BF3E-227CBAD368B6@apple.com>
Date: Thu, 11 Mar 2010 11:42:11 -0800
From: Geoff Keating <geoffk@...le.com>
To: oss-security@...ts.openwall.com
Cc: Ludwig Nussel <ludwig.nussel@...e.de>,
libesmtp@...fford.uklinux.net,
security@...ntu.com
Subject: Re: CVE Request: libesmtp does not check NULL bytes in commonName
On 11/03/2010, at 6:58 AM, Brian Stafford wrote:
> I find myself coming back to RFC 2818 being a reasonable choice since it is flexible and (almost) clear, and since HTTPS, as a major user of TLS, is, I assume, well analysed for security implications wrt certificate validation.
> Is it the case that for STARTTLS in SMTP what we are really interested in is encrypting the data on the wire and authentication is only of secondary importance? Do we know what the best current practice is among CAs when it comes to issuing certificates for STARTTLS?
The best current practice for CAs is probably expressed in the EV certificate requirements documents, which say that there should be no wildcards at all---and after reading this discussion, I think you can see why.
I doubt it makes sense, from a CA perspective, to ever issue a certificate with wildcard(s) anywhere but leftmost. Certainly there should never be a certificate which has a wildcard for the top-level (or second-level) domain, as that would imply the applicant controls the entire internet, and applicants which actually do control the whole internet (Akamai, I'm looking at you) can be issued CA intermediate certificates instead, which are better for auditing and control.
STARTTLS is a bit different than HTTPS, because in most SMTP configurations there's a trivial fallback attack (pretend to be the other server, and don't offer STARTTLS) so here the confidentiality aspects are the most important, to prevent passive sniffing.
Somewhere there's a draft RFC that goes into recommendations for certificate validation in much more detail, but I've lost it, and it's a draft and not yet complete.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
