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

Wed Sep 11 09:30:37 UTC 2013

Hi Ryan, 

There's nothing to prevent any sub CA owner from issuing multiple level
domains regardless of whether the CA has Constraints or not.  The advantage
with Constraints is you can't issue a working certfiiacte for domains you
don't own (obvious but as this is a public posting I wanted to make sure it
was clear).  The BR's themselves were specifically reworded to align with
Mozilla's policy to remove the need for mandatory external auditing.  CA's
can still opt to do this but the wording of Ballot 105 was clear in that
audits are still required at the same level (3% or more) across the board
(Constrained or not) and BR compliance rules are to be flowed down to the
Sub CA by the CA.   So there's no big change other than the independence of
the party that looks at the results.  If the CA doesn't care about it's
brand/image and knowingly passes bad domain examples then why on earth are
they a CA in the first place?  As Ryan Hurst highlighted in a reply post to
this thread we'll be moving by the end of 2013 to 100% checking of all
'technical' aspects of our Sub CAs and letting the Name Constraints
themselves verify the Subject/Vetting aspects.

Several times during the discussions on Name Constraints people eluded to
weaknesses due to the addition of the Constraints, however, this isn't
accurate as those weaknesses (like belong able to issue as a multi level
wildcard) are there in all cases.  Name Constraints bolsters security in
other areas.  It doesn't weaken the system.  As such I just wanted to make
sure Name Constraints doesn't get a bad rap in threads like this.

In the paypal.com.domain.net example the URL is usually hosted by someone
somewhere on some hosting platform and resolved by DNS and rendered by the
browser so as with everything there are multiple parties that have some
ability to help protect the innocent.   One way in the example below where
you do refeer o name constraints would be to show the user the Organization
details the CA fixed into the name Constrained SubCA and therefore pulled up
in the the Subscriber certificate in the Chrome to highlight it wasn't
Paypal..but that's a Subject (pun intended) for another day ;-)

Steve

From:  Ryan Sleevi <sleevi at google.com>
Date:  Tuesday, 10 September 2013 20:57
To:  Eddy Nigg <eddy_nigg at startcom.org>
Cc:  "public at cabforum.org" <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
<http://mydomain.com> , in which the CA fully vetted that ownership for
mydomain.com <http://mydomain.com> , then I would be able to issue
certificates for anydomain.com.mydomain.com
<http://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
<http://mydomain.com> , I could create any degree of spoofables for
anydomaincom.mydomain.com <http://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 <http://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 <http://paypal.com.dom.net>
>  
>  Or to make it more obvious:
>  
>  
> https://www.paypal.com.some.net/us/cgi-bin/webscr?cmd=_flow&SESSION=KKIncv649J
> Dbg
>  
>  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 <http://sharepoint.com.some.com>
> *.microsoftonline.com.some.com <http://microsoftonline.com.some.com>
>  *.outlook.com.shamir.adallom.com <http://outlook.com.shamir.adallom.com>
> *.office365.com.some.com <http://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
> 
> 
> _______________________________________________ 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/20130911/9be528c6/attachment-0003.html>