Re: Return of i18n attacks with the help of wildcard certificates
Paul Hoffman wrote: At 7:09 AM +0100 2/24/09, Kaspar Brand wrote: Kyle Hamilton wrote: Removal of support for wildcards can't be done without PKIX action, if one wants to claim conformance to RFC 3280/5280. Huh? Both these RFCs completely step out of the way when it comes to wildcard certificates - just read the last paragraph of section 4.2.1.7/4.2.1.6. PKIX never did wildcards in its RFCs. Which says: Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics. At 10:50 PM -0800 2/23/09, Kyle Hamilton wrote: RFC 2818 (HTTP Over TLS), section 3.1. RFC 2818 is Informational, not Standards Track. Having said that, it is also widely implemented, and is the main reason that the paragraph above is in the PKIX spec. Just one thing : The use of a wildcard certificate was a misleading red herring in the implementation of the attack. What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Once they have obtained their domain name, attacker can freely use the third-level domain name component to implement any i18n attack they want even if no wildcard certificate is authorized. This is not to say that wildcard certificates are not bad, evil, anything, but that nothing new has been truly brought about that by this attack. So talk about wildcard certificate all you want, but this is a separate discussion from the discussion about the solution for this new i18n attack. And the solution for it will not be wildcard certificate related, will not be easy or obvious, and so needs to be discussed as widely as possible. Also there will be no crypto involved in the solution, as it's not acceptable to choose to just leave ordinary DNS user out in the cold with regard to the attack. So it needs to be discussed on the security group, not crypto. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 02/26/2009 01:49 PM, Jean-Marc Desperrier: Just one thing : The use of a wildcard certificate was a misleading red herring in the implementation of the attack. Yes, I've been saying it all along. What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Dhuuu :-) Once they have obtained their domain name, attacker can freely use the third-level domain name component to implement any i18n attack they want even if no wildcard certificate is authorized. Correct in case the CA doesn't do any additional checking. IMO we should require it. This is not to say that wildcard certificates are not bad, evil, anything Wild cards are not evil and certainly not bad. Wild cards are terrific and a real time saver at least. However it requires a certain responsibility and I'd like to see better verification procedures by CAs. with regard to the attack. So it needs to be discussed on the security group, not crypto. It should be discussed in the new m.d.s.policy group IMO. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: start...@startcom.org Blog: https://blog.startcom.org ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
On 26/02/09 11:49, Jean-Marc Desperrier wrote: What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Actually, our protection had a bug (that is, there were some characters not on our blacklist which should have been). But it's not true that there was no protection. Gerv ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
Gervase Markham wrote: On 26/02/09 11:49, Jean-Marc Desperrier wrote: What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Actually, our protection had a bug (that is, there were some characters not on our blacklist which should have been). But it's not true that there was no protection. Which blacklist ? There's a blacklist inside the browser ? The oppposite seems obviously said here : http://www.mozilla.org/projects/security/tld-idn-policy-list.html « it does not [] require multiple DNS lookups, large character tables in the browser [] » Blacklist at the registrar level can not protect from attacks on the third-level domain name (or fourth, or more). But this being said, I'm coming to think it would be better to take a wider perspective and consider that making security rely on the user being able to *validate* the content of the URL bar is not realistic. You know, you can exclude ╱. But then you start wondering how many user will *really* notice if there's a ∕ or a ⁄, or ʃ, or Ɉ, or ͵ʹ, or ٪, or ޙ ,ހ, ৴, ૮, ८, །, ༼, ᚋ, ᤣ, ⁒, ⅟, ∠ instead of /. And then you begin to think that maybe just having . would work very often, that most user have the most cursory look at the url bar, so that making security depend on the url bar is just bad. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Return of i18n attacks with the help of wildcard certificates
Jean-Marc Desperrier wrote: Which blacklist ? There's a blacklist inside the browser ? Yes. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/modules/libpref/src/init/all.jsrev=3.762mark=704-708#704 The oppposite seems obviously said here : http://www.mozilla.org/projects/security/tld-idn-policy-list.html « it does not [] require multiple DNS lookups, large character tables in the browser [] » Indeed. This is a quite small character list. The large character tables would have been tables of characters that look like each other. Blacklist at the registrar level can not protect from attacks on the third-level domain name (or fourth, or more). Indeed. The key is to make it clear what the hostname is. You know, you can exclude ╱. Yep. But then you start wondering how many user will *really* notice if there's a ∕ or a ⁄, or ʃ, or Ɉ, or ͵ʹ, or ٪, or ޙ ,ހ, ৴, ૮, ८, །, ༼, ᚋ, ᤣ, ⁒, ⅟, ∠ instead of /. Indeed. And then you begin to think that maybe just having . would work very often, that most user have the most cursory look at the url bar, so that making security depend on the url bar is just bad. I happen to think so, yes. -Boris ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
