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

Ryan Sleevi sleevi at google.com
Wed Sep 11 21:14:25 UTC 2013


On Wed, Sep 11, 2013 at 2:30 AM, Steve Roylance <
steve.roylance at globalsign.com> wrote:

> 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.
>

I'm not sure how you saw it being NC getting a bad rap - NC are indeed a
much more flexible form of a wildcard cert, and that's a wonderfully good
thing compared to the alternatives that exist today - such as relying on
contractual controls or technical controls implemented at the CA side,
rather than technical controls that can be implemented in the UA side.

I'm not particularly convinced of the value of audits for such constrained
certificates. Because their ability to issue is restricted to their
constrained names, the most 'damage' they can do is limited to their named
scope - which is exactly what the audits are trying to do (limit the
damage).

Mozilla's policy only requires that technically-constrained CAs be
"operated" consistent with their policy - but there are no audit
requirements. As such, I would suggest that there is still skew between
what the BRs state and what programs like Mozilla require, but I would
leave that for someone from Mozilla to comment. Put differently, I'm not
sure what value (security or otherwise) is afforded by having the BRs
require auditing technically constrained sub-CAs - that seems to me a
brand-identity issue that CAs MAY choose to do, rather than a critical
security issue that the CA/B Forum MUST address or that root programs MUST
require.


>
> 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 ;-)
>
>
Which again goes back to the point that it's user agents, not CAs, that are
effective in the fight against phishing.


> 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, 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
>>
>>
> _______________________________________________ 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/db6f46c3/attachment-0003.html>


More information about the Public mailing list