Google considers warning Internet users about data risks | Hacker News Reader

Google considers warning Internet users about data risks

bbc.com

23 pointscorneliusjac10 comments

Chrome doesn't do full revocation checking by default. Instead they have a non-standard implementation called CRLset which handles specific revocations. To me, revocations is a fundamental part of PKI, so the fact that they don't do it makes me question how secure https really is with Chrome anyway.

> so the fact that they don't do it makes me question how secure https really is with Chrome anyway.

Chrome does revocations. They just don't use the standard mechanisms (which, BTW, you can enable if you want.) CRLsets are Chrome's revocation mechanism.

The problem with the standard mechanism is that if the browser can't reach the online revocation server, it trusts by default (fail-open).

The reason it fails open is that this (i.e., the lack of connectivity to revocation server) a pretty common case -- most captive portals, for example, would not work because they require HTTPS to sign in, while at the same time, disallowing any other network connectivity.

So, we now have a single-point-of-failure in the revocation server, which can be quite easily exploited by an attacker -- simply killing connections to this server will make browsers bypass the check.

The CRLset system closes this hole by periodically pushing revocation lists down to the browser, obviating the need for an online check. (Not to say that CRLset does not have its own problems. It does, but they're less severe.)

CRLset contains a fraction of all actual revocations. As far as I remember Chrome chose this solution to minimize download size. I'm my opinion, if revocation checks only are done sometimes it cannot be trusted. I am not arguing that Chrome e is better or worse than other browsers, just that their current model is broken and give users a false sense of security.

Don't you agree that the current method where the Chrome team choose a limited set of revocations to push to users is broken?

Uh? Chrome uses CRLset in addition to the usual revocation checks (CRL, OCSP).

They disabled OCSP by default in 2012 due to incurred latency and privacy concerns. Are you saying they changed it again?

I've two minds about the proposed change. On one hand, anything that can make it more difficult for governments to engage in dragnet surveillance is a public good. Though, I have reservations that the CA model is not what should be endorsed here. At the risk of regurgitating the same arguments that come up every time with https, I'd much prefer the separation of encryption and authentication in the way browsers echo security back to the user. When logging into a site, I want authentication, when I'm browsing as a guest, encryption alone is fine. The way browsers have thrown self-signed certificates under the bus has only helped to enable state surveillance at its current scale.

It would be nice if there was a way do achieve something like this without generating so many warnings that users ignore them.

Some versions of IE displayed a warning every time you submitted an unencrypted form - as in those days that happened every time someone used a search engine, people disregarded that warning pretty fast!

The equivalent Firefox bug was also recently reopened, too.

https://bugzilla.mozilla.org/show_bug.cgi?id=1041087

Sure and let's yell fire in a crowded movie theater for every showing and see how long it takes for people to ignore the warning.

So which browser can we use instead when they start this dumb idea?

Reply on news.ycombinator.com