On 10/12/10 10:50 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: >>> I consider the conservative approach of MSIE/SChannel and Firefox to >>> allow a tail wildcard on the leftmost DNS label, in addition to a >>> full wildcard, sensitive risk management combined with minimal complexity. >> >> As I said before, I don't think this "risk management" argument is real. > > The rist management argument is VERY real. > > Recall the numbers: > : > : http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ > : > : - 382860 total sites (hostnames) returned a cert > : - 94438 of total sites used a wildcard cert (24%) > : - 5% of total sites use the wildcard cert with CN=*.blogger.com > : ... other blogging/mass-hosting sites similarly high usage > : > : Only a handful (5) use the "f*.example.com" form; all those were certs > : issued by the GoDaddy and starfieldtech.com CAs. > > > Full wildcard certs are dangerous, because they will match any host > in a domain (which makes them a much more interesting target for > credential-stealing).
How so? If I can steal credentials such that I have access to verifying addresses for example.com, then I can convince a CA to issue whatever certificates I want. If the "example.com" property is valuable then the differences between example.com, *.example.com, and foo* or *oo or f*o.example.com are negligible. I really doubt that any thief is going to be significantly more attracted to stealing credentials because he knows that he can go to a CA and get *.example.com instead of "merely" foo*.example.com and www*.example.com and so on. And if that were the case then it would simply be a matter of CA-shopping (which the bad guys already do). > I assume that a non-negligible of those servers that are currently using > full wildcards could be using tail-match wildcards instead -- something > which could reduce the risk for some of the other servers in a domain. If folks were really interested in risk mitigation then presumably they'd be using things like SRV-IDs (limits the damage to a particular service type), EKU, name constraints, locking down canonical email addresses, etc., or at least not using wildcard certs in any way and requesting only certificates for named application services (e.g., mail.example.com instead of m*.example.com or *.example.com). Character matching on www* seems a lot less valuable than many other measures an organization could take. Furthermore, there is no way for an application service provider to signal to application clients that they should not accept wildcard certificates, so the primary benefits here accrue to the provider -- in which case they can simply define their own organizational policies and procedures for certificate requests, and perhaps communicate those to their favorite CAs. Finally, figuring out which measures are most effective at mitigating risk would require a breadth of research (analysis of various attacks etc.) that is beyond the scope of this I-D. > The reason why tail-wildcards are rarely used is probably not that server > operators do not like them We have no way of knowing whether application service providers like them or not, absent surveys of some kind. > or browsers would not support them, > but that there are currently not enough CAs offering them. > > Now instead of killing something which would help the risk managment > of server operaters, server-id-check should describe tail-wildcards > on the leftmost DNS label as an alternative to full wildcards as a MAY. The logical conclusion from your line of reasoning is to forbid all wildcard certificates, whether full-label, tail, head, torso, or anything else, but you don't seem to want to go that far. Why not? And why are tail wildcards so much safer than head or torso wildcards? Note that at least two technology communities have forbidden wildcard certificates: 1. RFC 5992 forbids wildcard certificates in the SIP community. 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates under its "Extended Valuation Certificates" profile. So there is some precedent for forbidding wildcard certificates. Is that a best current practice? Should this I-D state that wildcard certificates (of whatever variety) are NOT RECOMMENDED? Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
