Re: Return of i18n attacks with the help of wildcard certificates
On 03/03/09 14:30, Jean-Marc Desperrier wrote: What about a white version of the hostname display for http sites ? Because it's not reliable information due to MITM. And trying to tell users white means don't trust it, blue or green means do trust it is far harder than trust it if it's present. 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
Florian Weimer wrote: Most users are not subject to MITM attacks This may or may not be true given the prevalence of wireless networks out there... we've had a number of reports of in-the-wild MITM attacks by wireless network operators. but they do receive all kinds of URL lures. Yes, most of these are trying to phish sites that are normally SSL, so we should be making it very easy to tell when a site is not SSL or doesn't have the expected hostname over SSL. Making non-SSL sites look more like SSL ones even by similarly highlighting the hostname is asking for trouble. -Boris ___ 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 03/04/2009 03:36 PM, Boris Zbarsky: Florian Weimer wrote: Most users are not subject to MITM attacks This may or may not be true given the prevalence of wireless networks out there... we've had a number of reports of in-the-wild MITM attacks by wireless network operators. Yes, many routers and WiFi products are configured by default to allow such attacks. I can confirm more complaints arriving also at the CA I work. Yes, most of these are trying to phish sites that are normally SSL, so we should be making it very easy to tell when a site is not SSL or doesn't have the expected hostname over SSL. Making non-SSL sites look more like SSL ones even by similarly highlighting the hostname is asking for trouble. Actually this is correct too. How can we indicated to a user that this site really should be secured? When do we expect SSL? On submit or on password fields in a form (as the starting page should be really secured too, not only the POST target)? Could there be indicators which makes the user aware that this is not an SSL secured site (since regular http doesn't throw neither a warning nor any other annoyance)? -- 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
Eddy Nigg wrote: [...] When do we expect SSL? On submit or on password fields in a form[...] IF page contains form AND form contains password field THEN flash insecure form warning Could be done. But there would better be a cross browser agreement on this. And coupled with a way to offer (low/no)-cost SSL to everybody. ___ 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 4-Mar-09, at 8:36 AM, Boris Zbarsky wrote: Florian Weimer wrote: Most users are not subject to MITM attacks This may or may not be true given the prevalence of wireless networks out there... we've had a number of reports of in-the-wild MITM attacks by wireless network operators. but they do receive all kinds of URL lures. Yes, most of these are trying to phish sites that are normally SSL, so we should be making it very easy to tell when a site is not SSL or doesn't have the expected hostname over SSL. Making non-SSL sites look more like SSL ones even by similarly highlighting the hostname is asking for trouble. I haven't chimed in much here yet, but suffice it to say that I agree with everything Boris is saying. I have very little appetite for calling out domains (or other url components) on http connections as a way to provide *security* context, because that context is illusory. As Jean-Marc has pointed out - there's value in thinking about whether and how we want to encourage the broader use of SSL. So far the changes we have made in terms of security UI have been aimed at teasing apart the promises that various deployment methods actually make. For EV, we give extra visibility to organization name because it's the most consumable piece of information, for DV we emphasize the domain name (to greater or lesser extents depending on the state of debate over browser.identity.ssl_domain_display). For invalid or self- signed certs, we make a pretty visibly big deal about the fact that you're not getting the security you might think, since your safe from eavesdropper communications might well be going TO the eavesdroppers. I don't think we should labour under the illusion that better SSL UI will prevent phishing, though. Certainly, for proactive and observant users, who attend to the indicators we put in chrome, it will help. Certainly there's *some* value in making those indicators easier to understand, so that more users might find them helpful. But phishing by and large continues not to use SSL which is why we include things like an anti-phishing, anti-malware filter as well. It's great that our error pages were so daunting that Moxie went to significant lengths to avoid them, but the most I think a phisher is likely to do to synthesize security indicators is the lock-as-favicon trick. Which is precisely why we have moved away from using a padlock in the location bar as a sign of security: no website can spoof the EV appearance of the site identity button and, with the ssl_domain_display pref set to non-zero, (and appropriate care given to IDN issues), they can't for regular SSL either. Cheers, J --- Johnathan Nightingale Human Shield john...@mozilla.com ___ 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 03/04/2009 04:18 PM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] When do we expect SSL? On submit or on password fields in a form[...] IF page contains form AND form contains password field THEN flash insecure form warning Could be done. But there would better be a cross browser agreement on this. And coupled with a way to offer (low/no)-cost SSL to everybody. The later exists already for a long time (and you most likely know about it): www.startssl.com -- 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 03/04/2009 04:28 PM, Johnathan Nightingale: no website can spoof the EV appearance of the site identity button and, with the ssl_domain_display pref set to non-zero, (and appropriate care given to IDN issues), they can't for regular SSL either. Right, and I'm extremely glad that we are going this route. I also suggest to look on ways to signal to the user when we really expect a secured site (see Jean-Marc's message). It's extremely annoying to confirm every form submission when unsecured (it's my current setting) - if we could indicate only on password fields or other suspicious combination's (as phishers would most likely start avoiding the password tag altogether), it would be a useful indicator. -- 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
This kind of thing? https://addons.mozilla.org/en-US/firefox/addon/8128 On 4-Mar-09, at 9:42 AM, Eddy Nigg wrote: On 03/04/2009 04:28 PM, Johnathan Nightingale: no website can spoof the EV appearance of the site identity button and, with the ssl_domain_display pref set to non-zero, (and appropriate care given to IDN issues), they can't for regular SSL either. Right, and I'm extremely glad that we are going this route. I also suggest to look on ways to signal to the user when we really expect a secured site (see Jean-Marc's message). It's extremely annoying to confirm every form submission when unsecured (it's my current setting) - if we could indicate only on password fields or other suspicious combination's (as phishers would most likely start avoiding the password tag altogether), it would be a useful indicator. -- 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 --- Johnathan Nightingale Human Shield john...@mozilla.com ___ 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 03/04/2009 04:48 PM, Johnathan Nightingale: This kind of thing? https://addons.mozilla.org/en-US/firefox/addon/8128 It looks nice! I think it should also turn red if the starting page is unsecured, not only the landing page, but technically this would not be correct. However I'd fee uncomfortable to click on a form without prior knowing what to expect on submit (which CA or an exception). Specially for the EV sites it would be useless to know about it only after hitting submit. -- 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
Gervase Markham wrote: [...] We just turned hostname display UI for SSL on, according to The Burning Edge... This is a nice change, I found out about it on the burning edge too :-) But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? ___ 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 03/03/2009 04:30 PM, Jean-Marc Desperrier: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? YEAH! -- 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
Jean-Marc Desperrier wrote: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? Wait. Why does the domain matter at all for non-SSL connections? It's not like we have any guarantees against MITM here... -Boris ___ 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
Boris Zbarsky wrote: Jean-Marc Desperrier wrote: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? Wait. Why does the domain matter at all for non-SSL connections? It's not like we have any guarantees against MITM here... Well, we don't have the option to change the world, and in practice people just *do* send important login/password on http connections. You do have a point though, maybe it's time to think if there's a way by which mozilla could push toward more use of https to protect sensitive data. ___ 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 03/03/2009 05:51 PM, Boris Zbarsky: Jean-Marc Desperrier wrote: But, and as the link Eddy just reported shows, the attack is far from being only for SSL. I think we should reconsider the options available to make the domain name more visible for http connexions. What about a white version of the hostname display for http sites ? Wait. Why does the domain matter at all for non-SSL connections? It's not like we have any guarantees against MITM here... If we train users to watch out for positive SSL indicators and warn before submitting any information I think this should not be necessary. However I could imagine a re-vamped UI where the actual domain name is more prominent and the real URL less important for the average user. Something like this: ++-+ || +-+ |SSL | DOMAIN.COM | URL| || +-+ ++-+ The URL part might be only optional or hide and reappear on mouse-over. -- 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 27/02/09 14:48, Boris Zbarsky wrote: It's not clear to me that the person who added the list even knew the page existed. Neil added the list, and he wrote the second half of the page. So there was mutual knowledge. The list isn't documented on the page because, strictly speaking, it's not relevant. It seems like the right thing to do is to make the this is the hostname of the site ui somehow more prominent. Or possibly this is the tld+2 of the site or something. Some UI mockups would probably help more than anything else. We just turned hostname display UI for SSL on, according to The Burning Edge... 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
Subject was [Fwd: Facebook message - Received Messages Quickly] I've received it a few minutes ago. The URL doesn't us SSL, but it shows exactly what I posted in this thread not long ago...see forwarded message below: Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org/ Jabber: h...@startcom.org xmpp:h...@startcom.org Phone: +1.213.341.0390 Original Message Subject:Facebook message - Received Messages Quickly Date: Tue, 3 Mar 2009 00:23:25 + From: Facebook Message Center messa...@facebook.com To: certmas...@startcom.org Personal Message To You From your friends at facebook video server: Subject: Review - My family invite you out for lunch, don't hesitate! Read Description for a link to part 1 Original Video added by group member. You will see a link to Open Your Personal Message Manager. Selecting this link will take you to the log in page where you can browse new messages. Proceed to open full message text: http://login.facebook.permissions.videomessageid-q9k6d8abp.sessionnewid83.com/home.htm?/CEBMainServlet/LOGIN=v1yzhoqvrtc8gmf Sincerely, Maura Kent. Facebook 2009 Message Center. -- 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
Boris Zbarsky wrote: 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 I'm left with the feeling this really should have been more widely documented. The existence of that protection was really hard to guess from the tld-idn-policy-list.html page : - this did not stop Moxie Marlinspike from finding U+2571 was not protected and using it in an attack demonstration - this did stop anyone from reviewing the list and telling you U+2571 was missing. Once again, security through obscurity failed. I don't know if it was really intended to be security trough obscurity (it was public in bugzilla/the source code), but the end result looked very similar. But this means that there's a work around for this attack that's usable right now. I'll publish it separately. [...] 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. Good. But can a small committee find good solutions, or build consensus about them ? ___ 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: I'm left with the feeling this really should have been more widely documented. Could be! The existence of that protection was really hard to guess from the tld-idn-policy-list.html page : It's not clear to me that the person who added the list even knew the page existed. Good. But can a small committee find good solutions, or build consensus about them ? No idea what you're asking here... It seems like the right thing to do is to make the this is the hostname of the site ui somehow more prominent. Or possibly this is the tld+2 of the site or something. Some UI mockups would probably help more than anything else. -Boris ___ 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
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
Re: Return of i18n attacks with the help of wildcard certificates
Nelson Bolyard wrote: [...] Wildcards are not an essential part of this attack. They merely were a convenience for this demonstration, but the attack could have been done without using a wildcard cert. Even eliminating wildcard certs altogether would not stop this attack. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. Yes, there is, and yes, it is. So why is it still security restricted when the problem is out in the open ? Yes, the way of exploiting the failure without a wildcard cert is apparently not yet out in the open. But : - it's either a matter of days or hours - CA are still issuing wildcard certificates, so attackers don't need to know a wildcard is not really required to exploit the failure - I don't expect there will be any effort to try to stop CA from issuing dangerous wildcard certificates, since it won't solve the problem at large. ___ 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/23/2009 02:35 PM, Jean-Marc Desperrier: - I don't expect there will be any effort to try to stop CA from issuing dangerous wildcard certificates, since it won't solve the problem at large. This isn't the cure of the problem, wild cards are very useful! The problem is the validation requirement for wild cards. I think and believe that considering current business practices and fees charged for wild cards it is reasonable to require at least identity validation - similar to the same requirement for code signing. -- 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
Eddy Nigg wrote: On 02/19/2009 03:30 PM, Jean-Marc Desperrier: Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n attack using a *.ijjk.cn certificate. http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf .cn is authorized for i18n, and the * will match anything, allowing all the classic i18n based attacks. This was striking: Get a domain-validated SSL wildcard cert for *.ijjk.cn Yes, it's surprising how some of such attacks seem obvious *after* they have been done, but it takes so long to realize it can be done. The md5 collision between a normal and a *CA* certificate was similar for me, how the fuck did we not think earlier, when it was already obvious someone would soon create a collision between two real md5 certs, that they just had to do that to make the attack really effective. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. PS : I think this discussion should be on mozilla.dev.security since it's about a security vulnerability, not crypto and not security.policy. Does everyone share my opinion ? (I'm setting the follow-up there) ___ 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/20/2009 05:55 PM, Jean-Marc Desperrier: Get a domain-validated SSL wildcard cert for *.ijjk.cn Yes, it's surprising how some of such attacks seem obvious *after* they have been done, but it takes so long to realize it can be done. Not exactly. I found it striking because we've been discussing it (look for Comodo inclusion request of approximately April last year), however my concerns were not addressed really (besides adding it to the problematic practices which had no effect on the CA in question anyway). The md5 collision between a normal and a *CA* certificate was similar for me, how the fuck did we not think earlier, when it was already obvious someone would soon create a collision between two real md5 certs, that they just had to do that to make the attack really effective. Right, even though I still consider it to be an effort usually not done by the cheap phishers. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. For which one, MD5 or DV wild cards? For MD5 there is a bug, for DV wild cards not. PS : I think this discussion should be on mozilla.dev.security since it's about a security vulnerability, not crypto and not security.policy. Does everyone share my opinion ? (I'm setting the follow-up there) Incidentally it should be held on the new mailing list we've got security+policy issues (mozilla.dev.security.policy), not on security I think. -- 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
Jean-Marc Desperrier wrote, On 2009-02-20 07:55: Eddy Nigg wrote: On 02/19/2009 03:30 PM, Jean-Marc Desperrier: Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n attack using a *.ijjk.cn certificate. http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf .cn is authorized for i18n, and the * will match anything, allowing all the classic i18n based attacks. This was striking: Get a domain-validated SSL wildcard cert for *.ijjk.cn Wildcards are not an essential part of this attack. They merely were a convenience for this demonstration, but the attack could have been done without using a wildcard cert. Even eliminating wildcard certs altogether would not stop this attack. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. Yes, there is, and yes, it is. ___ 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 Feb 20, 7:55 am, Jean-Marc Desperrier jmd...@alussinan.org wrote: Eddy Nigg wrote: On 02/19/2009 03:30 PM, Jean-Marc Desperrier: Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n attack using a *.ijjk.cn certificate. http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-D... .cn is authorized for i18n, and the * will match anything, allowing all the classic i18n based attacks. This was striking: Get a domain-validated SSL wildcard cert for *.ijjk.cn Yes, it's surprising how some of such attacks seem obvious *after* they have been done, but it takes so long to realize it can be done. The md5 collision between a normal and a *CA* certificate was similar for me, how the fuck did we not think earlier, when it was already obvious someone would soon create a collision between two real md5 certs, that they just had to do that to make the attack really effective. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. PS : I think this discussion should be on mozilla.dev.security since it's about a security vulnerability, not crypto and not security.policy. Does everyone share my opinion ? (I'm setting the follow-up there) I have no idea as to how to submit an idea to the Mozilla dev team, but it seems to me that a step towards a solution might include color- coding portions of the URL to indicate which is the domain that's authenticated by SSL. For example: Black on White- https:// White on blue - www.pnc.com Black on light red - /pages/of/junk/index.html Yes, it still requires a user to notice the change and make a decision based on that, but having a strong visual indicator is a step in the right direction, IMHO. ___ 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
If you'd like to try out something similar, you can go to about:config and set browser.identity.ssl_domain_display to 1 (1st level domain only) or 2 (entire domain name). Lucas. On Feb 20, 2009, at 11:06 AM, evilredsca...@gmail.com wrote: On Feb 20, 7:55 am, Jean-Marc Desperrier jmd...@alussinan.org wrote: Eddy Nigg wrote: On 02/19/2009 03:30 PM, Jean-Marc Desperrier: Moxie Marlinspike in Black Hat has just demonstrated a very serious i18n attack using a *.ijjk.cn certificate. http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-D ... .cn is authorized for i18n, and the * will match anything, allowing all the classic i18n based attacks. This was striking: Get a domain-validated SSL wildcard cert for *.ijjk.cn Yes, it's surprising how some of such attacks seem obvious *after* they have been done, but it takes so long to realize it can be done. The md5 collision between a normal and a *CA* certificate was similar for me, how the fuck did we not think earlier, when it was already obvious someone would soon create a collision between two real md5 certs, that they just had to do that to make the attack really effective. This being said : Is there already a bug open for this ? The only thing that stops me opening it myself is that it might already exist but be security restricted. PS : I think this discussion should be on mozilla.dev.security since it's about a security vulnerability, not crypto and not security.policy. Does everyone share my opinion ? (I'm setting the follow-up there) I have no idea as to how to submit an idea to the Mozilla dev team, but it seems to me that a step towards a solution might include color- coding portions of the URL to indicate which is the domain that's authenticated by SSL. For example: Black on White- https:// White on blue - www.pnc.com Black on light red - /pages/of/junk/index.html Yes, it still requires a user to notice the change and make a decision based on that, but having a strong visual indicator is a step in the right direction, IMHO. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
