On Fri, 24 Nov 2017 12:25:40 +0000 Gervase Markham via dev-security-policy <[email protected]> wrote:
> Validate example.com -> add "www.example.com": seems fine to me, and a > reasonable accommodation to a common customer desire. > > Validate www.example.com -> add "example.com": not at all fine. > > Validate *.example.com -> add "example.com": still dodgy IMO. All of these can be a problem, and I would like us to have as the end goal forbidding all these practices, but I recognise that it's unrealistic to achieve that in the short term. The thing is, extraneous names on a certificate present a subtle security flaw, even if control over those names was validated properly Extraneous names can appear in a CSR as a result of the applicant making a bad security choice. But that's not our domain here, bad choices by Relying Parties or Applicants are their problem. Bad choices by the CAs can harm everybody and we should be trying to move things in the right direction on that front. Anyway, let me illustrate the risk: Suppose I have two HTTPS servers named charlie and dave, charlie provides web pages on https://www.example.com/, https://example.com/, and also a not-for-humans API service https://example.com:8443/ Meanwhile dave provides https://forum.example.com/, https://blog.example.com/ and https://demo.example.com. It defaults to forum because we have some Internet Explorer users who expect that to work. As the IT manager I obtain two certificates, one for charlie and one for dave. I am slightly surprised that the one for dave, for which I requested *.example.com, ends up being *.example.com and example.com because of my chosen CA's "free upgrade". But I see no immediate problem with this and wave it through. For charlie I just have a certificate naming www.example.com and example.com as expected. Now, a Bad Guy discovers a bug in the crappy PHP forum software I am using which lets them read items from the error logs of the forum software by mangling parameters to an image request, if for example an erroneous HTTP POST is made they get to see all the details this way... But the Bad Guy is smart, they don't use this bug to annoy forum dwellers. Instead they sign up for a forum account, if necessary buying a cheap product from me with a throw-away card so that they can join. Then they MITM one or more valuable customers. When the customer uses a POST API at https://example.com:8443/ the Bad Guy can't interpose their own service because of the Web PKI (hooray) but they can redirect the packets to dave which will present a certificate valid for https://example.com:8443/ even though that's not what I needed or asked for, and unable to recognise requests for example.com it will default to the forum software... The forum software doesn't understand the API calls, it will log everything it sees as an error, and the Bad Guy can read that using the forum software bug. As I said, we can't stop Subscribers from choosing to expose themselves to this risk without making the Web PKI annoying to the point of being unusable. But CAs can and should try to encourage subscribers to put less names on a certificate, not more, including by gradually eliminating policies that add extra names "free". Part of the way forward is for software vendors to help their Customers to ask for the right certificate. It's crazy that many popular web servers won't even help you cook up a CSR for the names actually being served by that server for example, so that unless they're pretty savvy we're left guessing which names the customer really "needs". _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
