3 ms·

The node/express middleware works flawlessly for me. I am really stoked that Let's Encrypt is happening. Writing multi-microservice apps in Node just got a lot

by ruffrey 11y ago

The node/express middleware works flawlessly for me. I am really stoked that Let's Encrypt is happening. Writing multi-microservice apps in Node just got a lot easier to deploy for my side projects and small consulting clients - as well as cheaper. Of course it's safer, you never have to think twice about doing TLS. That said, I'd still opt for a wildcard certificate for anything enterprisey. Thank you to all the people who worked for years to make it happen.

dineshp2 11y ago
> That said, I'd still opt for a wildcard certificate for anything enterprisey. Let's encrypt can be used to generate a certificate for every subdomain, though it's a little more work compared to just using a wild card certificate.
- Jaruzel 11y ago
  If you are running Windows Server as your Webserver (many Enterprise places do), and the version of IIS is <7.5 (i.e. Server 2008, still under extended support until 2020), you can't assign more than one Cert to the same IP which sucks. SNI is only available from Windows Server 2012 onwards, and that doesn't work with Windows XP as the client (Still approx 10% of users globally).
  - wtetzner 11y ago
    Right, but at least you can up to 100 subdomains as SANs on the same certificate.
    - Jaruzel 11y ago
      Agreed, and before LetsEncrypt that was insanely expensive for absolutely no reason whatsoever. I sincerely hope that paying through the nose for Certs becomes something only Enterprise Orgs do, just for the backend support service.
pfg 11y ago
> That said, I'd still opt for a wildcard certificate for anything enterprisey. Many sites use wildcard certs because they're the simplest way of getting SSL for your entire domain. There is one huge problem with that, though: Sharing the private key between different services means that the security of your private key is only as good as the weakest link. If any of your services suffer a compromise that leads to a private key leak (i.e. Heartbleed), all your other services are now vulnerable to MitM as well. Not just that, but weaknesses in your TLS configuration on one service could have implications on other services as well, as demonstrated by the DROWN attack. That is not to say that there are no valid use-cases for wildcard certificates. If you're, for example, hosting a SaaS where each customer gets a custom subdomain, but the infrastructure behind each subdomain is essentially the same, there's no additional risk and wildcards are the perfect solution. If you're just getting a wildcard certificate because it's the most convenient solution, however, you're probably weakening some of your infrastructure in exchange for that.
- avar 11y ago
  You seem to be assuming that there needs to be a distinctive backend codebase for each domain covering the wildcard certificate. This is something entirely orthogonal to the number of certificates. You could have 1000 codebases with different attack vectors under one SSL certificate, or 1 codebase the same attack vectors serving up 1000 SSL certificates.
  - pfg 11y ago
    I'm not sure I follow? What I was trying to say was that it's a good idea to have one key per DISTINCT($attack_surface), which includes anything from physical security to the software stack, in order to limit the damage during a compromise. Throwing wildcards at everything tends to go against that principle, even though I admit there are use-cases where wildcards are entirely appropriate (namely those where each subdomain has the exact same attack surface anyway), and using something else isn't worth the trouble.

by ruffrey 11y ago

dineshp2 11y ago

> That said, I'd still opt for a wildcard certificate for anything enterprisey. Let's encrypt can be used to generate a certificate for every subdomain, though it's a little more work compared to just using a wild card certificate.

Jaruzel 11y ago
If you are running Windows Server as your Webserver (many Enterprise places do), and the version of IIS is <7.5 (i.e. Server 2008, still under extended support until 2020), you can't assign more than one Cert to the same IP which sucks. SNI is only available from Windows Server 2012 onwards, and that doesn't work with Windows XP as the client (Still approx 10% of users globally).
- wtetzner 11y ago
  Right, but at least you can up to 100 subdomains as SANs on the same certificate.
  - Jaruzel 11y ago
    Agreed, and before LetsEncrypt that was insanely expensive for absolutely no reason whatsoever. I sincerely hope that paying through the nose for Certs becomes something only Enterprise Orgs do, just for the backend support service.

pfg 11y ago

> That said, I'd still opt for a wildcard certificate for anything enterprisey. Many sites use wildcard certs because they're the simplest way of getting SSL for your entire domain. There is one huge problem with that, though: Sharing the private key between different services means that the security of your private key is only as good as the weakest link. If any of your services suffer a compromise that leads to a private key leak (i.e. Heartbleed), all your other services are now vulnerable to MitM as well. Not just that, but weaknesses in your TLS configuration on one service could have implications on other services as well, as demonstrated by the DROWN attack. That is not to say that there are no valid use-cases for wildcard certificates. If you're, for example, hosting a SaaS where each customer gets a custom subdomain, but the infrastructure behind each subdomain is essentially the same, there's no additional risk and wildcards are the perfect solution. If you're just getting a wildcard certificate because it's the most convenient solution, however, you're probably weakening some of your infrastructure in exchange for that.

avar 11y ago
You seem to be assuming that there needs to be a distinctive backend codebase for each domain covering the wildcard certificate. This is something entirely orthogonal to the number of certificates. You could have 1000 codebases with different attack vectors under one SSL certificate, or 1 codebase the same attack vectors serving up 1000 SSL certificates.
- pfg 11y ago
  I'm not sure I follow? What I was trying to say was that it's a good idea to have one key per DISTINCT($attack_surface), which includes anything from physical security to the software stack, in order to limit the damage during a compromise. Throwing wildcards at everything tends to go against that principle, even though I admit there are use-cases where wildcards are entirely appropriate (namely those where each subdomain has the exact same attack surface anyway), and using something else isn't worth the trouble.