[Pkg-chromium-maint] Bug#745646: chromium: certificate revocation is not checked

[Vincent Lefevre]

On 2014-05-01 19:57:37 +0200, Giuseppe Iuculano wrote:
> Il 2014-04-30 20:30 Jonathan Nieder ha scritto:
> >However Vincent is right that the CRLSets[1] are a different mechanism
> >than OCSP revocation checking and that CRLSet checking is enabled by
> >default.
> 
> Yes, that's true, but I really can't reproduce this issue. In all my
> installations, CRLset are updated correctly.

How can you explain that on my machines, the CRLset isn't updated?

> >If it is broken then that would indeed be a serious bug.
> 
> I don't think this would be a serious bug. You should consider
> CRLSet only as "better than nothing".

Having login/password stolen because the certification revocation
isn't checked correctly is completely unacceptable.

> Please try to find a real case where you are more secure with it but
> consider that:
> 
> - CRLSet includes at most 2% of the revoked certificates currently published
> by the Internet's certificate authorities

This means that the CRLSet system is completely broken by design.

> - updates to CRLSet appear to often take several days

The shorter is the better. I hope that if an important site (such as
a bank) gets its certificate revoked due to a leak, the CRLSet could
be updated in a few hours...

> - if an attacker can use a revoked certificate, he can intercept traffic, so
> he could also intercept CRLSets updates

In such a case, i.e. after some expire time, the https connection
should be blocked as if the certificate were invalid; the user
should be able to accept if he thinks that's OK. Note that if the
CRLSet update cannot occur, this probably means that the traffic
is intercepted, so that's better to block the https connection
anyway.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)