Can’t I trust the Postal Service? Part 2 – the certificate.

In part 1 of this mini-series, I talked about how the US Postal Service had deployed only part of the certificate that they had bought, and that this resulted in either an irritating dialog (in IE 6, and other browsers), or a page that warned you not to go farther (in IE 7).

I’d like to reiterate my advice that when you see a certificate problem, you should not continue to the web site. Again, the certificate problem warnings indicate that the site has failed to prove to you that they are who they claim to be. At that point, you say “I cannot trust the web site – I must use the brick-and-mortar store, or the phone”, and you don’t carry on into the web site.

[I asked the same question of an Internet Explorer presenter at Tech-Ed (Markellos Diorinos), and he gave the same answer - unless you are the owner of the web site, or a security researcher, don't try and debug certificate errors, just assume you cannot trust the site and walk away. Remember, it's not about trusting or not trusting the Postal Service, it's about how you deal with the site to which you've connected, which has claimed that it can identify itself as the Postal Service, and then singularly failed to do so.]

Now we go to the next step – looking at the certificate that is in use.

I was surprised to see the following item appear in the certificate’s details:

So, this isn’t a certificate for just the web site in question – this is a certificate for any web site in the usps.gov domain.

Okay, this is a technically valid certificate – but is it good security?

I’m not sure that I can go quite as far as to say “no”, but it’s certainly something I would shy away from.

Why?

  • Purchase cost
    It costs a lot more to get a wildcard certificate than it does to get a single host certificate.
    Not quite as much as to get a certificate authority certificate, but definitely significantly more, so that it only makes financial sense if there’s something that you absolutely cannot do without using a wildcard certificate.
  • Deployment cost
    When you use a wildcard certificate across several sites within your domain, you have to give that wildcard certificate to all site administrators, or install it for them on all sites within your domain. This means that the administrator of one of your secure sites is a huge step closer to being able to spoof any of your secure sites.
  • Increased attack surface
    Several of your sites are now sharing the same private key; if someone attacks one site successfully, they can now pretend to be any of your other sites.
  • Revocation cost
    Say the worst happens, and you discover that the private key has been exposed to unauthorised parties – not necessarily through an external attack, but possibly because the administrator of one of these sites has left your employment; you now want to revoke the key – so again, you have to re-deploy the new certificate to all of your web sites and administrators.
  • Third-party hosting
    Large companies like the Postal Service often outsource the development and hosting of web sites. When you give a third party a certificate for the site they are hosting, you really don’t want them to be able to spoof others of your sites. That’s part of the point of certificates.

There are doubtless some other good reasons why wild-card certificates might be bad. Why would you use them, then?

  • Purchase cost
    While the cost is more than that of buying a single certificate, there is a number of sites (depending on your CA) for which it is cheaper to buy a wildcard certificate, rather than multiple individual certificates
  • Small business
    If you’re a small business, where you are the sole administrator for a dozen websites under your domain, the cost of deployment is the same for a wildcard certificate as for a single certificate.
  • Server co-hosting
    Again, possibly more for small businesses, if you are running several web sites on the same IP address and port combination, you can only give out one certificate when people connect. This may require a wildcard certificate, although this is generally a suggestion that you either separate these sites out to their own IP addresses, or treat them as a single host with multiple applications. Wildcard certificates don’t help with cross-domain server co-hosting.
  • Certificate management
    It’s easier to maintain a backup copy of one key than a dozen.

Quite frankly, I don’t think any of these arguments really outweigh the risks. Maybe you will, or maybe there are some reasons that I haven’t given – what’s your take on wild-card certificates? Is there something I’ve missed, either for or against?

4 thoughts on “Can’t I trust the Postal Service? Part 2 – the certificate.”

  1. Thanks for teh discussion. We have been discussing this internally, and are trying to come up with risk profile.

    Of your Negitives, 3 are associated with cost, these are realtivly easily quantified, and in reality most will be motivated to to go with wildcards to reduce costs (its why we are condisering it) so that just becomes an excercise to ensure you are capturing all teh end to end costs.

    Your final point re 3rd party hosting is valid, but avoidable. I agree that if you go for wildcards you can’t outsource that domain. In fact you need to make sure you control your domain very tightly.

    Which leaves us with increased attack surface. How likly is it for someone to “crack” your certificate? Hopefully not very or else the entire SSL infrastructure is worthless. So I assume that you are saying if you have multiple copies of a certificate that increases the chance someone will compromise one of them, and steal the certificate.

    So I guess it comes down to how confidant you are your server is secure, and that if it becomes compromised you will notice it before the attacker can take advantage of it.

  2. No, it comes down to how confident you are that every one of your servers are secure. There’s a big difference.
    If you use individual certificates for individual services (which may be spread across several servers), the strength of each certificate is dependent on the weakest of the servers within that service – but not dependent on the strength of any server outside the service.
    If you use a wildcard certificate for any service within your domain, then every server in your domain may be spoofed if an attacker can get at any one of those servers that uses a wildcard certificate.
    Note that this also means that you can’t use a non-wildcard certificate to get “better security” inside your domain, because the wildcard certificate will still work to spoof that site. (e.g. if you registered certificates at *.example.com and securesite.example.com, an attacker who gets the key for *.example.com can use that certificate to pretend to be securesite.example.com also)

  3. It was at a usps.gov site, but the site has been changed since then – now all usps.gov references get redirected to usps.com.
    So you won’t be able to replicate the issue with live references to existing sites. You’ll have to rely on my historical description.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>