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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
