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

[Michael Gilbert]

control: tag -1 upstream
control: tag -1 -unreproducible

On Sat, May 3, 2014 at 6:41 PM, Vincent Lefevre wrote:
> Control: tags -1 - moreinfo
>
> On 2014-05-02 22:47:02 -0400, Michael Gilbert wrote:
>> On Thu, May 1, 2014 at 2:20 PM, Vincent Lefevre wrote:
>> > 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?
>>
>> It may be that chromium needs to be running for some time before it
>> decides to attempt to fetch the data.  Have you tried leaving it open
>> for a while?
>
> On 5 tests, Chromium always downloads the CRLSet after 21 minutes.
> This means that before these 21 minutes, Chromium may be completely
> insecure concerning https connections. This may not be a problem
> for users who have Chromium permanently running, but for those like
> me who use(d) Chromium from time to time and quit it rather quickly
> (before these 21 minutes), it remains permanently insecure.
>
> Can anyone confirm such a delay?

That's probably how Google intended it, but maybe they didn't fully
contemplate your kind of usage pattern.

> A correct behavior would be one of the followings, at least in cases
> (1) and (2) below:
>   * Chromium should download the CRLSet immediately after start up;
>   * Chromium should ensure that the CRLSet has been downloaded
>     before the first https connection (this would mean that for
>     an early connection, the user has to wait typically for a few
>     seconds, i.e. the time the CRLSet could be downloaded).
>
> There are 4 cases after startup:
>   1. The CRLSet is missing: Downloading it is crucial.
>   2. The CRLSet has expired (after some analysis during the last
>      few days, the expiry time seems to be 4 days in practice):
>      Downloading it is very important.
>   3. The CRLSet has not expired, but is, say, at least 24-hour old
>      (that's just an example, I don't know what the recommended
>      time limit could be): It is better to download it, but this
>      is not critical.
>   4. The CRLSet is very recent: it is better not to try to download
>      it again.

These seem like reasonable suggestions.  I recommend initiating an
upstream discussion with Google on that.

>> >> 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.
>>
>> Google's documentation [0] indicates that CRLSets are mostly for
>> "emergency" situations, whatever that means, so it isn't the solution
>> to the certificate revocation problem that you're looking for.
>
> So, those who say that CRLSets (as implemented by Google) are a
> replacement for OCSP are lying, and Chromium is not secure for
> these many domains that have been ignored by Google (and that
> includes my own domain, for instance). I would like to understand
> why you do not consider this (and the problem mentioned above) as
> a security issue.

Because the current behavior does not violate Google's existing
security model.  You'll need to convince Google that it's an
incomplete solution, not me.

> Also I don't see the point to limit the CRLSet to 250 KB (at least
> for all users): nowadays people download videos and so on, which
> take much more space. Security updates of Chromium itself are also
> much heavier...

Again, a better question for Google.

Best wishes,
Mike