What kind of crash are we talking about? Do you have to trust the certificate or does it crash on the man-in-the-middle warning page? That could be an opportunity for a pretty bad DoS vulnerability.
I didn’t spend too much time investigating it. After a few navigations on a site using this cert, Chrome just exited. It was after trusting the certificate.
The Certification Authority (CA)/Browser Forum baseline requirements (11.1.3) require that before issuing a wildcard certificate, Certificate Authorities ensure that such a certificate is not issued for entries in the Mozilla PSL, e.g. *.co.uk,or that the entity actually owns the entirety of the public suffix
Please read all sub-threads before posting a reply :)
This is an requirement for CA’s, not user agents. This certificate would not be issued by a (public) CA, but it is not invalid for browsers. It is perfectly valid for private CA’s to do this, e.g. so you could MITM all of your workers traffic.
There are two kinds of public suffixes – those defined by ICANN, also included in the public suffix list, and the not really official private definitions in the public suffix list.
And quoting the ICANN advisory on this:
The Certification Authority (CA)/Browser Forum baseline requirements (11.1.3) require that before issuing a wildcard certificate, Certificate Authorities ensure that such a certificate is not issued for entries in the Mozilla PSL, e.g. *.co.uk,or that the entity actually owns the entirety of the public suffix
So while it’s not an RFC, it’s still a standard – and an even stronger at that
it’s still a standard – and an even stronger at that
You are confused. That is not a quote from a standard for web browsers or TLS implementations, but for people who want to make a certificate signing authority that CA/B members (like Mozilla, Google, Microsoft, and so on) would include in their web browsers.
There are lots of reasons to make certificates that Mozilla (For example) would not include in the Firefox web browser, and it is required that valid TLS implementations interpret them according to the actual standard where that’s broader than what you’re reading here.
Sounds like a political limitation, not a technical limitation. Unless SSL consumers start to enforce this on their end, it wouldn’t prevent a malicious CA from issuing a cert like this that could be used to MITM all traffic.
That’s exactly the point – I was expecting browsers to actually implement this spec and verify this for certificates (as I already do this in a limited way in Quasseldroid)
It doesn’t matter at all unless you trust that certificate, or whoever published it. It’s just a self-signed certificate that is valid for any domain. If you don’t trust it, then you don’t trust it, and it will be invalid for any use where you come across it.
Gotcha; I missed the critical detail that it’s self-signed. So to use this in an attack you’d have to trick someone into trusting the cert for some trivial site first.
Exactly. And then they would have to serve some content with that cert that the target would access. There’s essentially no practical way this could be used in an attack except for a man-in-the-middle attack, but you would still need to get the target to trust the certificate first.
Trusting the cert is easy with technical people. I link you guys to my site, with a self signed cert like this. You accept it because you want to see my tech content.
I missed the critical detail that it’s self-signed
You didn’t quite miss it, it’s been misleadingly described by the submitter — they never explicitly mention that this is merely a self-signed certificate, neither in the title here, nor in the GitHub repository. To the contrary, “tested working in Chrome, Firefox” is a false statement, because this self-signed certificate won’t work in either (because, self-signed, duh).
I never say that it’s signed by a CA either 😅 I wasn’t trying to mislead folks, but some seem to have interpreted “SSL certificate” as meaning “CA-issued SSL certificate”. It does work in Chrome and Firefox insofar as it is correctly matched against domain names and is valid for all of them.
This isn’t signed by a trusted CA, so this specific cert can’t intercept all your traffic. However, all it takes is one bad CA to issue a cert like this and… yeah, shut down the Internet.
Or any CA operating under a hostile government, or any CA that’s been hacked. See DigiNotar for just one example of a CA that has issued malicious wildcard certs.
And as you can see it was removed from all browser’s trust stores and soon declared bankrupt (hence, death wish). And that wasn’t even deliberate. I can’t see a CA willfully destroying their own business. Yes, it’s a huge problem if this happens though, and isn’t announced to the public, as the case in the article.
Normally, certificates are doing three separate things here:
Ensuring nobody can read your communications.
Ensuring nobody can modify your communications.
Ensuring you’re communicating with the entity which validly owns the domain.
Most people who are against HTTPS ignore the second point by banging on about how nobody’s reading your webpages and nobody cares, when ISPs have, historically, been quite happy to inject ads into webpages, which HTTPS prevents. This strikes at the third point… except that it doesn’t. It’s self-signed, which defeats the whole mechanism by which you use a certificate to ensure you’re communicating with the entity you think you are. The weird wildcard stuff doesn’t make it any less secure on that front, since anyone can make their own self-signed certificate without wildcards and it would be just as insecure.
If you could get a CA to sign this, it would be dangerous indeed, but CAs have signed bad certificates before. Again, a certificate can be bad and can get signed by an incompetent or corrupt CA without any wildcards.
So this is a neat trick. I’m not sure it demonstrates any weakness which didn’t exist already.
How is a cert that works for every domain better than no encryption? Like, if someone actually uses this then the private key used is openly available on GitHub and all traffic can be MITM.
Shouldn’t it be possible to automate short lived TLS certs that are bonded only to a specific local domain name? Why is a wild-wildcard TLS cert seen as an acceptable approach?
At a prior employer, we a DNS record wildcard for localhost.$domain.com and an ELB with security group access only from our office IPs bonded to our *.$domain.com TLS certificate so we could allow CORs for local development and be HTTPS. That still raised some eyebrows but was considered acceptable on grounds that we firewalled off access to the ELB. It would’ve been even better with a split-horizon DNS to keep access solely in office/in VPN (we were in adtech and unsafe to a degree for “get shit done” - I don’t endorse public A records pointing to 127.0.0.1).
Shouldn’t it be possible to automate short lived TLS certs that are bonded only to a specific local domain name?
Yeah, this is what most HTTPS intercepting proxies end up doing. I created this wild-wildcard cert while I was working on intercepting HTTPS traffic and noticed that generating a new cert for each domain was a little expensive.
Unfortunately (or fortunately, depending on how much you hate ugly hacks 😁), this cert can’t be used in the real world because it eventually crashes Chrome, and presumably other parts of the HTTP stack will have trouble coping as well.
Should be subtitled: Why wildcard certs are a bad idea. As a friend once put it: “I don’t trust anyone with the last name of Rose, I trust Matt Rose”
Convenient for development, convenient for vanity URLs, but questionable for production use.
Also, this cert does cause Chrome to frequently crash, presumably because of the wild amount of wildcard matching.
What kind of crash are we talking about? Do you have to trust the certificate or does it crash on the man-in-the-middle warning page? That could be an opportunity for a pretty bad DoS vulnerability.
I didn’t spend too much time investigating it. After a few navigations on a site using this cert, Chrome just exited. It was after trusting the certificate.
Okay. I’ll test it in an ASAN build.
Edit: I can’t get it to crash either before or after trusting the certificate. Arch Linux, Chromium 83.0.4103.56 ASAN, and the following HTTP server:
Still interesting to explore nonetheless.
The RFC explicitly forbids this kind of use, only allowing the lowest identifier to be a wildcard, and only if it is not a public suffix itself.
This is very surprising that browsers don’t match on this properly.
While it’s a little easier for you to write “the RFC”, it would be helpful for you to mention which RFC for those of us reading.
https://tools.ietf.org/html/rfc6125#section-6.4.3 says SHOULD.
What are you talking about?
Please read all sub-threads before posting a reply :)
This is an requirement for CA’s, not user agents. This certificate would not be issued by a (public) CA, but it is not invalid for browsers. It is perfectly valid for private CA’s to do this, e.g. so you could MITM all of your workers traffic.
Which RFC? How is “public suffix” defined? Does it simply defer to the Public Suffix List?
There are two kinds of public suffixes – those defined by ICANN, also included in the public suffix list, and the not really official private definitions in the public suffix list.
And quoting the ICANN advisory on this:
So while it’s not an RFC, it’s still a standard – and an even stronger at that
You are confused. That is not a quote from a standard for web browsers or TLS implementations, but for people who want to make a certificate signing authority that CA/B members (like Mozilla, Google, Microsoft, and so on) would include in their web browsers.
There are lots of reasons to make certificates that Mozilla (For example) would not include in the Firefox web browser, and it is required that valid TLS implementations interpret them according to the actual standard where that’s broader than what you’re reading here.
Sounds like a political limitation, not a technical limitation. Unless SSL consumers start to enforce this on their end, it wouldn’t prevent a malicious CA from issuing a cert like this that could be used to MITM all traffic.
That’s the state of web PKI in a single sentence.
That’s exactly the point – I was expecting browsers to actually implement this spec and verify this for certificates (as I already do this in a limited way in Quasseldroid)
So, uhh…. what now? Shut down the Internet until this is fixed? Disconnect your wifi router? Never log on to another web site again?
It doesn’t matter at all unless you trust that certificate, or whoever published it. It’s just a self-signed certificate that is valid for any domain. If you don’t trust it, then you don’t trust it, and it will be invalid for any use where you come across it.
Gotcha; I missed the critical detail that it’s self-signed. So to use this in an attack you’d have to trick someone into trusting the cert for some trivial site first.
Exactly. And then they would have to serve some content with that cert that the target would access. There’s essentially no practical way this could be used in an attack except for a man-in-the-middle attack, but you would still need to get the target to trust the certificate first.
Trusting the cert is easy with technical people. I link you guys to my site, with a self signed cert like this. You accept it because you want to see my tech content.
This is a huge issue.
How is this different from using any other self-signed certificate?
Here’s what I think @indirection is getting at:
However, I would hope SSL overrides are hostnane-specific to prevent this type of attack…
Yep that’s exactly it! Thank you.
You didn’t quite miss it, it’s been misleadingly described by the submitter — they never explicitly mention that this is merely a self-signed certificate, neither in the title here, nor in the GitHub repository. To the contrary, “tested working in Chrome, Firefox” is a false statement, because this self-signed certificate won’t work in either (because, self-signed, duh).
I never say that it’s signed by a CA either 😅 I wasn’t trying to mislead folks, but some seem to have interpreted “SSL certificate” as meaning “CA-issued SSL certificate”. It does work in Chrome and Firefox insofar as it is correctly matched against domain names and is valid for all of them.
This isn’t signed by a trusted CA, so this specific cert can’t intercept all your traffic. However, all it takes is one bad CA to issue a cert like this and… yeah, shut down the Internet.
For any CA that has a death wish sure!
Or any CA operating under a hostile government, or any CA that’s been hacked. See DigiNotar for just one example of a CA that has issued malicious wildcard certs.
And as you can see it was removed from all browser’s trust stores and soon declared bankrupt (hence, death wish). And that wasn’t even deliberate. I can’t see a CA willfully destroying their own business. Yes, it’s a huge problem if this happens though, and isn’t announced to the public, as the case in the article.
Normally, certificates are doing three separate things here:
Most people who are against HTTPS ignore the second point by banging on about how nobody’s reading your webpages and nobody cares, when ISPs have, historically, been quite happy to inject ads into webpages, which HTTPS prevents. This strikes at the third point… except that it doesn’t. It’s self-signed, which defeats the whole mechanism by which you use a certificate to ensure you’re communicating with the entity you think you are. The weird wildcard stuff doesn’t make it any less secure on that front, since anyone can make their own self-signed certificate without wildcards and it would be just as insecure.
If you could get a CA to sign this, it would be dangerous indeed, but CAs have signed bad certificates before. Again, a certificate can be bad and can get signed by an incompetent or corrupt CA without any wildcards.
So this is a neat trick. I’m not sure it demonstrates any weakness which didn’t exist already.
That’s a really pretty triangle
How is a cert that works for every domain better than no encryption? Like, if someone actually uses this then the private key used is openly available on GitHub and all traffic can be MITM.
It can be but not after the fact. Encryption still works exactly as intended, just with more opportunities for others to be in the data stream
If you know the key, you can read what people are sending. It’s not rocket science. Privacy doesn’t exist in that situation.
If you know the key used. The cert is not the key used for most data transfer.
Shouldn’t it be possible to automate short lived TLS certs that are bonded only to a specific local domain name? Why is a wild-wildcard TLS cert seen as an acceptable approach?
At a prior employer, we a DNS record wildcard for
localhost.$domain.comand an ELB with security group access only from our office IPs bonded to our*.$domain.comTLS certificate so we could allow CORs for local development and be HTTPS. That still raised some eyebrows but was considered acceptable on grounds that we firewalled off access to the ELB. It would’ve been even better with a split-horizon DNS to keep access solely in office/in VPN (we were in adtech and unsafe to a degree for “get shit done” - I don’t endorse public A records pointing to 127.0.0.1).Yeah, this is what most HTTPS intercepting proxies end up doing. I created this wild-wildcard cert while I was working on intercepting HTTPS traffic and noticed that generating a new cert for each domain was a little expensive.
Unfortunately (or fortunately, depending on how much you hate ugly hacks 😁), this cert can’t be used in the real world because it eventually crashes Chrome, and presumably other parts of the HTTP stack will have trouble coping as well.
I’ve been through a bunch of certificate hell recently, this is absolutely hilarious to me. Much needed amusement. Thanks (: