Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 :) –  user185 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 '13 at 13:42
show 1 more comment

3 Answers

up vote 13 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 '13 at 14:42
1  
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 '13 at 14:49
1  
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 '13 at 7:56
add comment

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
add comment

Ultimately, many of the vulnerabilities noted in these answers come from mixing levels of trust. But if you understand how wildcard certs work, you can mitigate these vulnerabilities for particular use cases. I think that explaining this in more detail will improve the usefulness of this question and its answers.

Unless all of the systems in your domain have the same trust level, using a wildcard cert to cover all systems under your control is a bad idea. But you can use DNS subdomains as a segmentation tool. as Hendrik said, since wildcards do not traverse subdomains, you can restrict a wildcard cert to a specific namespace. For example, if you had a CDN farm, you could wildcard just *.cdn.example.com. This keeps hosts in example.com itself (like www.example.com) separate, and you could issue a separate cert for www.example.com.

As AviD mentioned from OWASP, internal workstations, development systems etc. belong in lower trust levels. However, hosts like these should be in their own internal domain space anyway (like prv.example.com). Since wildcards do not traverse subdomains, a *.example.com cert cannot be applied to prv.example.com hosts. (This would keep public and private properties separate, but obviously does not segregate private properties from one another. Other subdomain wildcards could be used, mapped to appropriate trust levels).

While this eWeek article notes that the private key can be shared across multiple hosts, this SSLShopper rebuttal says that some issuers (like DigiCert) allow you to generate separate private keys for each wildcarded host. This does reduce some of the usefulness of wildcard certs, but definitely mitigates the shared-private-keys problem, and might be helpful in some circumstances. Otherwise, this Entrust article and the whitepaper PDF that it references discuss best practices for managing private keys when used with wildcard certs.

Finally, resorting to argument by authority... if Google is using wildcard certs for some of their properties, they must not be universally bad:

Qualys SSL Labs screenshot for youtube.com cert

:-)

share|improve this answer
add comment

Your Answer

 
discard

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