5 ms·

What do you mean by "broadly supported"? Do you want browsers to make it impossible to install custom CAs?

by Buge 7y ago

prepend 7y ago
That’s one way. I think a smarter way would be for browsers to compare the ssl cert in browser with some whitelist of ssl certs from a cdn or browser managed set and block when they differ (ie my browser is showing a different cert for HN than safari knows is valid, block it). There’s quite a few ways to prevent this. Custom CAs are pretty necessary for internal networks so I don’t think they should be blocked whole cloth, but restricting how they can be used so they don’t impersonate real things would be nice.
- Buge 7y ago
  Hmm, I think part of that has already been implemented by certificate transparency. But the reason it didn't block this attack is that CT is only enforced against public CAs, not custom installed CAs. The reason it's not enforced against custom CAs is that for people who do development and need to debug their own traffic, it's not feasible to have them submit to CT logs. It sounds like you want all domains to be divided into 2 categories: testing/internal domains, and real domains. Where in real domains only public CAs with valid CT entries would be trusted, but in testing domains custom CAs are allowed. Maybe we could go even a step further in the division and disallow public CAs from testing domains. There's of course the question of how to distinguish a real donation from a testing domain; maybe this could be done by saying all testing domains must be in a special TLD such as .local or .testing . This might work, but it it's still restricting developers, because if they need to debug some problem they have less options on how to do it. There might be a problem with cookies on the real domain that won't reproduce on the testing domain. And they need to maintain 2 server configs instead of 1, 1 for each domain.

What do you mean by "broadly supported"? Do you want browsers to make it impossible to install custom CAs?

by Buge 7y ago

What do you mean by "broadly supported"? Do you want browsers to make it impossible to install custom CAs?

That’s one way. I think a smarter way would be for browsers to compare the ssl cert in browser with some whitelist of ssl certs from a cdn or browser managed set and block when they differ (ie my browser is showing a different cert for HN than safari knows is valid, block it). There’s quite a few ways to prevent this. Custom CAs are pretty necessary for internal networks so I don’t think they should be blocked whole cloth, but restricting how they can be used so they don’t impersonate real things would be nice.

Buge 7y ago
Hmm, I think part of that has already been implemented by certificate transparency. But the reason it didn't block this attack is that CT is only enforced against public CAs, not custom installed CAs. The reason it's not enforced against custom CAs is that for people who do development and need to debug their own traffic, it's not feasible to have them submit to CT logs. It sounds like you want all domains to be divided into 2 categories: testing/internal domains, and real domains. Where in real domains only public CAs with valid CT entries would be trusted, but in testing domains custom CAs are allowed. Maybe we could go even a step further in the division and disallow public CAs from testing domains. There's of course the question of how to distinguish a real donation from a testing domain; maybe this could be done by saying all testing domains must be in a special TLD such as .local or .testing . This might work, but it it's still restricting developers, because if they need to debug some problem they have less options on how to do it. There might be a problem with cookies on the real domain that won't reproduce on the testing domain. And they need to maintain 2 server configs instead of 1, 1 for each domain.