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?
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.
> >> 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.
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...
BTW, I'm using Iceweasel with security.OCSP.require set to true, and
haven't noticed any problem at all.
--
Vincent Lefèvre <vinc...@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)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
