4

Is there anything inherently more insecure about using a wildcard SSL certificate over a regular SSL certificate?

We are looking to implement a subdomained web application (a la FreshBooks and BaseCamp, where users pick a subdomain), and one of our team members is concerned that a wildcard SSL approach is not secure enough (if so, how do FreshBooks and BaseCamp do it?!?).

The alternate solution is to use a single subdomain, like https://ssl.domain.com and when a user types in http://user.domain.com we set the subdomain in the session, and immediately redirect the user's future requests to "https://ssl.domain.com" and use the session information to show the user's information.

My concern is that if a user wants to send a link to their domain to a friend, they will copy/paste the URL in the browser (now https://ssl.domain.com) which will be our main home page, and not the user's home page.

BTW, if I have missed a major best-practice for this kind of scenario, please let me know.

user9517
  • 115,471
  • 20
  • 215
  • 297
iopener
  • 187
  • 12

5 Answers5

6

To my knowledge, there is no difference between wildcard and normal certificates. So long as you have full control over domain.com's DNS, then there's no reason not to use a wildcard. In fact, I would recommend it in your case. What are your specific concerns with them?

(IMO, Redirects such as the one you suggest are always a bit of a fudge when they're visible to the end user.)

SmallClanger
  • 9,127
  • 1
  • 32
  • 47
3

From a technical aspect it would be just as secure. You would still be using the same encryption you would with a non-wildcard cert. What is it that they are saying is less secure?

HostBits
  • 11,796
  • 1
  • 25
  • 39
3

I agree with the other answers, that wildcard certificates are not inherently insecure.

However it is possible to introduce a security problem by using wildcard certificates incorrectly. The following security problem would not happen if your certificates are valid for only one domain each.

Imagine that you initially have a single server hosting all the subdomains. The adversary signs up for your service and gets assigned the domain evil.example.com. This like all your other customers is covered by the certificate for *.example.com.

The adversary arranges for evil.example.com to receive lots of traffic, so eventually that domain gets allocated a dedicated server. Now you have two physical servers with identical certificate.

At this point the adversary starts performing MITM attacks (whether that happens through DNS poisoning or malicious APs is not important). The adversary directs users of legitimate.example.com to the IP address of evil.example.com. Since the certificate says *.example.com it is valid.

However the dedicated server for evil.example.com doesn't know the domain name legitimate.example.com, so it responds with the content from the default vhost, which is going to be evil.example.com because this dedicated server doesn't have any other domains.

This attack scenario can be avoided if every server holding the certificate can respond to requests for all the subdomains. It is perfectly acceptable, if this sometimes means proxying the request from one server to another. As long as the proxying itself is secured against MITM attacks.

In a proper configuration the dedicated server for evil.example.com would only start receiving requests for legitimate.example.com once the adversary attempts to perform a MITM attack on users. It won't be able to server the content and instead proxies the request to the real server hosting legitimate.example.com.

If the adversary is given sufficient control over the dedicated server hosting evil.example.com to disable that proxying, then you do have a real security problem.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • It can also be avoided by making the default vhost be a "sorry there is a problem" vhost. – Peter Green Nov 27 '16 at 22:31
  • @PeterGreen That would limit the damage, but in that case the adversary acting as described would cause a DoS attack in which it appears as though the problem is a fault on the legitimate server rather than an attack on the intermediate network. – kasperd Nov 27 '16 at 23:09
2

As SmallClanger points out, so long as you have full control over the domain and any possible sub-domains, there's not inherent security problems. One possible drawback is that you can't get a Wildcard EV Cert, so no green bar for the few users that look for it.

Chris S
  • 77,945
  • 11
  • 124
  • 216
  • This is the thing that makes me wonder. If the wildcard won't give us a green bar, and providers consistently offer lower "insurance" payments if compromised (wildcard = $10K, EV = $150K), it seems as though there is something inherently less trustworthy with the wildcard. Is it just that they are more likely to be used on multiple boxes, and therefore pass through many hands, and therefore be more likely to be compromised? – iopener Apr 26 '11 at 16:50
  • @iopener, yeah, that's basically the train of thought is that wildcard certs are more likely to be on more boxes and you're less likely to be careful with them... Wildcards are also cheaper, hence less insurance as well. – Chris S Apr 26 '11 at 17:33
2

Wildcard certificates bring additional risk in some scenarios. Whether those scenarios are applicable to you and if-so whether you consider the added risk acceptable is something you will have to determine in context.

Lets say all your subdomains are on one server. In this case it makes virtualy no difference security wise whether your have a wildcard cert, a multi-name cert or seperate certificates for each site. If an attacker compromises your server to the point they scan steal the private keys for the certs they can probablly steal all of them not just the one.

Now lets say you add another subdomain which should have higher security than the existing ones, maybe a payments site. You put that subdomain on it's own server and get it it's own cert.

If you used seperate certs or a multi-name cert on the first server the the certificate/key from the first server could not be used to impersonate the second server.

If you used a wildcard cert on the first server than the certificate/key from the first server could be used to impersonate the second server.

P.S. certificate "insurance" is snakeoil.

Peter Green
  • 4,211
  • 12
  • 30