

Google considers warning Internet users about data risks - corneliusjac
http://www.bbc.com/news/technology-30505970

======
internetisthesh
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.

~~~
zeroxfe
> 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.)

~~~
internetisthesh
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?

------
pragmar
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.

------
michaelt
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!

------
diafygi
The equivalent Firefox bug was also recently reopened, too.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1041087](https://bugzilla.mozilla.org/show_bug.cgi?id=1041087)

------
300bps
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.

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

