13 ms·

I get that this feels un-pure, but what is the actual damage of validating against cached intermediate certs? The only concrete thing the author cites is harder

I get that this feels un-pure, but what is the actual damage of validating against cached intermediate certs? The only concrete thing the author cites is harder debugging, but that's a pretty weak objection.

jimmyl02 3y ago
I think it's mainly the change in behavior that could be viewed as concerning. As a user of a website, if the order of websites you visited after browser startup impacts the success or invalid certificate error I feel like it's a pretty confusing experience. I definitely didn't know this before and if I saw this behavior I would be pretty confused.
anonacct37 3y ago
The actual damage is that it's pretty common (my last team has this happen) for a team to setup a cert, verify it works, and then when they deploy the cert it works some of the time or "works on my machine" and so the failures seem really random and by definition hard to reproduce because you have to restart chrome to reproduce. Probably the tl;Dr is that validating against a persistent cache like Firefox is fine. Validating against an ephemeral cache with chrome is likely to cause a lot of breaking.
- KAMSPioneer 3y ago
  Sort of a corollary to your point: if an admin sets up a website and verifies with Firefox (or Chromium, whatever), and then later the server needs to communicate with...basically any tool that speaks HTTPS but isn't a web browser, then there will be many tears shed by that admin. For instance, you stand up a server, and then a user complains their script using cURL, wget, etc. doesn't work, and if you aren't paying attention you'll have no idea why. Inb4 why can't the OS certificate store just do the same thing: I suspect people will tend to install OS updates less frequently that browser updates, so it will tend to be less reliable.
  - anon4242 3y ago
    This is why you should do `openssl s_client -connect <your site>` to verify TLS when changing your server's TLS certs.
  - remram 3y ago
    This happens to me, every time IT renews that one certificate the API stops working. The website works fine and that's all some people check.
minitech 3y ago
Seems like a potential fingerprinting risk, but I haven’t checked if the actual implementation is built to guard against that somehow.
anon4242 3y ago
It's a potential Heisenbug for (some of) your javascript code. Sometimes things work on some machines and sometimes it doesn't. Unless you have the cert-chain misconfig in your brain-cache you'd probably spend hours debugging confusing bug reports from customers that you fail to reproduce reliably. So it's not just harder to debug, it causes bugs (and indirectly bug-reports you'll need to investigate).
remram 3y ago
The problem is that it masks the error. Then you have all kinds of websites that only work in some browsers, or have an API that is not accessible from some automated tools unless you enable "insecure mode", and everybody is worse off. It also makes implementing new browsers more complicated, and thus the ecosystem less open. All that to hide a configuration error that would take a second to fix in the first place.

jimmyl02 3y ago

I think it's mainly the change in behavior that could be viewed as concerning. As a user of a website, if the order of websites you visited after browser startup impacts the success or invalid certificate error I feel like it's a pretty confusing experience. I definitely didn't know this before and if I saw this behavior I would be pretty confused.

anonacct37 3y ago

The actual damage is that it's pretty common (my last team has this happen) for a team to setup a cert, verify it works, and then when they deploy the cert it works some of the time or "works on my machine" and so the failures seem really random and by definition hard to reproduce because you have to restart chrome to reproduce. Probably the tl;Dr is that validating against a persistent cache like Firefox is fine. Validating against an ephemeral cache with chrome is likely to cause a lot of breaking.

KAMSPioneer 3y ago
Sort of a corollary to your point: if an admin sets up a website and verifies with Firefox (or Chromium, whatever), and then later the server needs to communicate with...basically any tool that speaks HTTPS but isn't a web browser, then there will be many tears shed by that admin. For instance, you stand up a server, and then a user complains their script using cURL, wget, etc. doesn't work, and if you aren't paying attention you'll have no idea why. Inb4 why can't the OS certificate store just do the same thing: I suspect people will tend to install OS updates less frequently that browser updates, so it will tend to be less reliable.
- anon4242 3y ago
  This is why you should do `openssl s_client -connect <your site>` to verify TLS when changing your server's TLS certs.
- remram 3y ago
  This happens to me, every time IT renews that one certificate the API stops working. The website works fine and that's all some people check.

minitech 3y ago

Seems like a potential fingerprinting risk, but I haven’t checked if the actual implementation is built to guard against that somehow.

anon4242 3y ago

It's a potential Heisenbug for (some of) your javascript code. Sometimes things work on some machines and sometimes it doesn't. Unless you have the cert-chain misconfig in your brain-cache you'd probably spend hours debugging confusing bug reports from customers that you fail to reproduce reliably. So it's not just harder to debug, it causes bugs (and indirectly bug-reports you'll need to investigate).

remram 3y ago

The problem is that it masks the error. Then you have all kinds of websites that only work in some browsers, or have an API that is not accessible from some automated tools unless you enable "insecure mode", and everybody is worse off. It also makes implementing new browsers more complicated, and thus the ecosystem less open. All that to hide a configuration error that would take a second to fix in the first place.