3 ms·

does this mean you can collide legitimate certificates on these hosting providers? like someone is hosting www.foo.com can I upload a www.foo.com certificate th

does this mean you can collide legitimate certificates on these hosting providers? like someone is hosting www.foo.com can I upload a www.foo.com certificate then it will choose which cert to use based on some random factors. or maybe it only works on names that haven't been uploaded so i can block someone from uploading certificates for a future domain they might want to use.

tscs37 9y ago
I'd say no, though it depends on the provider. Afaict the vulnerability is simply "users can upload arbitrary certs and have the server use them based on SNI", which does have some legitimate use cases (private CA)
jo909 9y ago
Maybe, but that is a different issue. If as a hosting provider I have accounts for foo.com and bar.com, I certainly need to make sure to never reply to requests for foo.com with data from the account bar.com. But I might still allow the account bar.com to upload a certificate that includes bar.com www.bar.com bar.io getbar.com or any other domain name even if those are not registered in my platform. So what if bar.io is actually not owned by the same person as bar.com? The DNS for bar.io does not point to my platform, no real user will connect to me. If an attacker is also able to change the DNS for bar.io (say by an MITM attack in a public wifi) it is of no real consequence that he uses my platform. He could just as well respond with an IP completely of his own and do everything himself. That is why we have SSL in the first place.
- benmmurphy 9y ago
  so if someone has www.foo.com registered with a provider (but has wildcard DNS pointing *.foo.com to the provider) would it be possible for someone who has another domain bar.com to upload a cert that would be used for x.foo.com. because even though no content would be served from bar.com that is kind of a weird situation. like i think the way ACME tls-sni works is broken because it should be using the DNS hierarchy to make the SNI request [maybe something like: 773c7d.13445a.acme.foo.com] but maybe some providers are still broken even with this fix because they let people upload certs with names that belong to other clients.

tscs37 9y ago

I'd say no, though it depends on the provider. Afaict the vulnerability is simply "users can upload arbitrary certs and have the server use them based on SNI", which does have some legitimate use cases (private CA)

jo909 9y ago

Maybe, but that is a different issue. If as a hosting provider I have accounts for foo.com and bar.com, I certainly need to make sure to never reply to requests for foo.com with data from the account bar.com. But I might still allow the account bar.com to upload a certificate that includes bar.com www.bar.com bar.io getbar.com or any other domain name even if those are not registered in my platform. So what if bar.io is actually not owned by the same person as bar.com? The DNS for bar.io does not point to my platform, no real user will connect to me. If an attacker is also able to change the DNS for bar.io (say by an MITM attack in a public wifi) it is of no real consequence that he uses my platform. He could just as well respond with an IP completely of his own and do everything himself. That is why we have SSL in the first place.

benmmurphy 9y ago
so if someone has www.foo.com registered with a provider (but has wildcard DNS pointing *.foo.com to the provider) would it be possible for someone who has another domain bar.com to upload a cert that would be used for x.foo.com. because even though no content would be served from bar.com that is kind of a weird situation. like i think the way ACME tls-sni works is broken because it should be using the DNS hierarchy to make the SNI request [maybe something like: 773c7d.13445a.acme.foo.com] but maybe some providers are still broken even with this fix because they let people upload certs with names that belong to other clients.