[cabfpub] [cabfman] Deceptive SSL cert issued for fake Chase domain

Ryan Hurst ryan.hurst at globalsign.com
Tue Sep 10 20:09:18 UTC 2013


Yes,



This is a problem; in our environment we audit for these issues in subcas;
we are automating those audits with investments around CT at this time.



Just because a CA is technically constrained doesn’t mean the CA no longer
has responsibility for keeping an eye on their practices.



As for the homograph examples, in our new platform in particular we fraud
analytics  which considers many things including problems in this space.



We will be applying those same checks to our auditing regime we apply to
constrained CAs via automation mentioned above.



Ryan



*From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
Behalf Of *Ryan Sleevi
*Sent:* Tuesday, September 10, 2013 12:58 PM
*To:* Eddy Nigg (StartCom Ltd.)
*Cc:* public at cabforum.org
*Subject:* Re: [cabfpub] [cabfman] Deceptive SSL cert issued for fake Chase
domain



Eddy,



I'm not sure whether CAs either can really be effective here in mitigating
this, at least in the scope of subdomains. I think this is especially true
when considering Mozilla's policy to allow technically constrained sub-CAs
to issue certificates that are not audited to the BRs.



If I were to obtain a technically constrained sub-CA for mydomain.com, in
which the CA fully vetted that ownership for mydomain.com, then I would be
able to issue certificates for anydomain.com.mydomain.com. That is, a
technically constrained sub-CA behaves like a multi-level wildcard
certificate.



Likewise, given a wildcard certificate for *.mydomain.com, I could create
any degree of spoofables for anydomaincom.mydomain.com. I suspect (but I'm
not intimately familiar with) the possibility of Punycoding some degree
there. I know this has been a point that Brad Hill has raised in the past.



I think when it comes to anti-phishing, this is something that may be
better handled by the UAs, at least with respect to subdomains. You can
already see this in UAs that highlight things like the "effective TLD+1" in
their address bar, scrolling in particular to that location (eg: see Chrome
on mobile platforms). That's not to say it's a perfect solution, by far,
but it's a much more scalable solution that recognizes where the strengths
and weaknesses are - and I think having CAs try to validate subdomains on
the eTLD+1 is realistically a weakness that won't be solved effectively.



I think we still need to have the BRs concerned about spoofables at the
eTLD+1 level, and still need to be concerned about high-risk requests, but
when it comes to subdomains, I don't lose much sleep on this matter, at
least when it comes to certificate issuance.



Put differently, I do not think the lock icon can be reasonably be
considered an anti-phishing mitigation. It merely is an indication of the
connection/encryption to the domain in question.



On Tue, Sep 10, 2013 at 12:39 PM, Eddy Nigg (StartCom Ltd.) <
eddy_nigg at startcom.org> wrote:


On 09/10/2013 08:13 PM, From Jeremy Rowley:

I know we’ve performed similar (non-malicious) experiments with DV certs to
see how easy it would be to phish a banking domain.  It’s pretty easy.  I
think this is a good launching point to discuss how we can improve the BRs
in a manner that prevents these types of phishing attacks.





In this respect I have a hot topic I'm supposed to check with the CAB
Forum, this comes convenient....

>From time to time we get requests for certificates that contain possible
domains within the host name, for example:

*domain.com.dom.net*

Now we have made an effort to disallow this practice as much as possible
recently because it could be easily abused:

*paypal.com.dom.net*

Or to make it more obvious:

*
https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649JDbg
*

As it happens, some CAs issue such potentially confusing certificates and
we ourselves get every while requests for them. In particular also from
companies that provide or want proxy services and in order to mask the
names as much as possible it looks something like this (this is from a real
request):

*.sharepoint.com.some.com     *.microsoftonline.com.some.com
*.outlook.com.shamir.adallom.com     *.office365.com.some.com

Which again could easily confuse a relying party which might or might not
know about the MITM going on.

I would like to know what the stance of the membership here is on this
topic, in particular software vendors. And if there is room to clarify this
via regulation by the BR. Otherwise there is probably no point in punishing
our clients when others or they can get it easily elsewhere.

Regards



Signer:

Eddy Nigg, COO/CTO



StartCom Ltd. <http://www.startcom.org>

XMPP:

startcom at startcom.org

Blog:

Join the Revolution! <http://blog.startcom.org>

Twitter:

Follow Me <http://twitter.com/eddy_nigg>






_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130910/a2e2278b/attachment-0003.html>


More information about the Public mailing list