Closed Thorsten-Sick closed 9 years ago
Firefox is already doing a fairly good job of preventing downgrade attacks between TLS versions, using the TLS_FALLBACK_SCSV. And I believe it has a fix for the logjam downgrade attack as well. Chrome is similar, and also provides us less access to the crypto APIs, which might make this feature impossible.
In general, we probably want to lean in the direction of letting the browsers choose the cipher suite settings. Sometimes, when an attack is very new and we can deploy an update to users quickly, we may deploy a quick fix. But I think adding a feature to block certain cipher suites for certain sites is likely to lead to more breakage.
We did not really investigate the cipher suite situation (would include setting up an experimental network to "hack" the browser). I also think the browsers are currently handling that quite well. Only special case could be for sites that want more security (like banking). There we could enforce a minimum encryption quality. Or have a client side DB for banks covering the cipher suites they support.
We (Avira) are building a secure browser based on chromium. We already wrote some features that extend the feature set of chromium. We also contributed to chromium. For the crypto api (that is currently missing): We could just write one - if the benefits are large enough. But I already found some other features in chromium (mixed content blocker) that I'd address first.
Closing this because I think it's better left up to the browsers for now.
This is a RFC:
For critical pages (banking) it could be helpful to have a minimum crypto quality stored in the browser for each page. If the TLS-handshake results in a worse ciper-suite being used, the connection is aborted. This could prevent crypto-downgrade attacks.
What do you think ?
Will be implemented by Avira for Chrome