Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 10 down vote favorite

In a comment on this answer, AviD says:

"There are numerous security issues with wildcard SSL certs."

So, what are the problems? I understand that the same private key is being used in multiple contexts, but given that I could host all of my applications under the same host name I don't see this as a 'new' issue introduced by wildcard certificates.

share|improve this question
Hug? What does "pentest" even mean? – curiousguy Oct 19 '11 at 2:14
1  
@curiousguy pentest is an abbreviation for penetration testing. Penetration testing is a controlled scenario when a person or team act as adversary and attempt to penetrate the protections in place (bypass security). – this.josh Oct 19 '11 at 6:49
1  
@this.josh So what security protections did they bypassed? – curiousguy Oct 19 '11 at 10:53
1  
@curiousguy that's what I'm hoping the answers to this question might reveal :) – Graham Lee Oct 20 '11 at 8:36
Consider that poor phrasing on my part. It would more likely be an issue for an audit. E.g. from OWASP: "You should refrain from using wildcard certificates. Though they are expedient at circumventing annoying user prompts, they also violate the principal of least privilege and asks the user to trust all machines, including developer's machines, the secretary's machine in the lobby and the sign-in kiosk.". – AviD♦ Mar 10 at 13:42
show 1 more comment

2 Answers

up vote 7 down vote accepted

A "wildcard certificate" is a certificate which contains, as possible server name, a name which contains a "*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.

In the certification business for Web sites, there are four main actors:

  • The SSL server itself.
  • The vendor of the Web browser which the client will use.
  • The human user, who controls to some extent what the client browser will do.
  • The CA who issued the certificate to the server.

Wildcard certificates don't imply extra vulnerabilities for the SSL server; indeed, the SSL server has no interest in looking at its own certificate. That certificate is for the benefits of clients, to convince them that the public key contained in the certificate is indeed the public key of the genuine SSL server. The SSL server knows its own public/private key pair and does not need to be convinced about it.

The human user has no idea what a public key is. What he sees is a padlock icon and, more importantly, the intended server name: that's the name at the right of "https://" and before the next "/". The Web browser is supposed to handle the technical details of verifying that the name is right, i.e. validation of the server certificate, and verification that the name matches that which is written in the said certificate. If the browser does not do this job, then it will be viewed as sloppy and not assuming its role, which can have serious commercial consequences, possibly even legal. Similarly, the CA is contractually bound to follow defined procedures for identifying SSL server owners so that fake certificates will be hard to obtain for attackers (contract is between the CA and its über-CA, recursively, up to the root CA which is itself bound by a pact with the OS or browser vendor, who accepted to include the root CA key in the OS or browser under defined conditions).

What this amounts to, is that the browser and the CA must, in practice, pamper the user through the verification process. They are more or less under obligation (by law or, even stricter, by business considerations) to prevent the user from being swindled through fake sites which look legit. The boundary between the user's job and the browser/CA job is not clearly defined, and has historically moved. In Days of Yore, I mean ten years ago or so, browsers just printed out the raw URL, and it was up to the human user to find the server name in it. This lead forged site operators (i.e. "phishing sites") to use URL which are technically valid, but misleading, like this one:

https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html

Since human users are, well, human, and most of them read left-to-right (most rich and gullible scam targets are still in Western countries), they will begin on the left, see www.paypal.com, stop at the colon sign ("too technical"), and be scammed.

In reaction, browser vendors have acknowledged that the URL-parsing abilities of human users are not as good as was initially assumed, and thus recent browsers highlight the domain part. In the case above, this would be xcvhjvb.com, and certainly not anything with paypal.com in it. Now comes the part where wildcard certificates enter the game. If the owner of xcvhjvb.com buys a wildcard certificate containing "*.xcvhjvb.com", then he can setup a phishing site called:

https://PayPal-payment-interface-login-session.xcvhjvb.com/confirm.html

which will be accepted by the browser (it matches the wildcard name), and is still likely to catch unwary users (and there are many...). This name could have been bought by the attacker without resorting to wildcards, but then the CA employees would have seen the name with obvious fraudulent attempt (good CA do a human validation of every request for certificates, or at least raise alerts for names which are very long and/or contain known bank names in them).

Therefore, wildcard certificates decrease the effectiveness of fraud-containment measures on the CA side. This is like a blank signature from the CA. If wildcard-based phishing attempts become more commonplace, one can expect that one or several of the following measures will come into existence:

  • Browsers highlight only the parts of the domain name which matches non-wildcard elements in the certificate.
  • CA require heavier paperwork and contracts for wildcard certificates (and these will be more expensive).
  • Browsers deactivate support for wildcard certificates altogether.

I actually expect all three measures to be applied within the next the years. I could be totally wrong about it (that's the problem with predicting the future) but this is still my gut feeling.

Nitpickingly, we can also point out that wildcard certificates are useful for sharing the same key pair between different server names, which makes it more probable that the private key will be shared between different server machines. Traveling private keys are a security risk in their own right; the more a private key wanders around, the less "private" it remains.

share|improve this answer
I'm still not convinced there are no scenarios where this would put the web server at risk. For example, if the wildcard cert is shared between two sites, of different sensitivity levels - say, a public website and an internal accounting app - vulnerabilities in the publicly accessible website could possibly affect the private accounting app, no? – AviD♦ Mar 11 at 14:42
Ah, that's something other. It is not the wildcard which triggers a vulnerability, but sharing the private key. If a server contains a private key, and the server is hijacked, then the key is revealed and this impacts every other system using that key (although, arguably, the problem is still on the client, not on the server: you won't penetrate a server by knowing its SSL private key, but you may create a fake server or decrypt client/server traffic). – Thomas Pornin Mar 11 at 14:49
Well, yeah, but sharing the cert (and of course the private key) between more than one site is kind of implied by having a wildcard (otherwise, why bother?). This seems to be one of the risks of using a wildcard cert. Moreover, it's not just about sharing the private key - even if you only install the cert on the low-trust server (e.g. public website), it will not help to have a specific, non-wildcard cert for the more-sensitive site. Having a wildcard cert is like the joker in the pack - it can be absolutely anything you want it to be. – AviD♦ Mar 12 at 7:56
up vote 10 down vote

It is bad practice to spread the same private key across multiple servers providing different service: Any exploited security issues in any service will reveal the private key used for everything.

But it is common to use wildcard certificates to isolate user contributed web content in user specific subdomains to leverage the same origin policy. The same approach is commonly used to render untrusted portlets. It's part of the Open Social "standard".

At my workplace we develop a software which contains an open social implementation and uses the wildcard setup. Customer installations have been subjected to penetration tests. The wildcard setup was not criticized.

share|improve this answer
3  
To be quite clear, this isn't an issue with wildcard certificates at all - there is nothing about them that makes them inherently less secure. They can be (and indeed, are often) used for only a single service (see the linked question - that's exactly how that asker would have deployed it), and a non-wildcard certificate is just as commonly deployed in multiple services. While use for multiple services certainly increases risk, it's complete nonsense to make a blanket statement that implies that a wildcard certificate will "fail a pentest" where another certificate would not. – Shane Madden Oct 18 '11 at 16:24
@ShaneMadden you are basically saying the same thing, I did. But the person who made that statement might not see your reply to my posting. – Hendrik Brummermann♦ Oct 18 '11 at 16:45
Yeah - I completely agree with your answer and was just trying to elaborate a bit, sorry I didn't make that apparent. – Shane Madden Oct 18 '11 at 17:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.