Re: Why fail to open secure connection to the client incidentally, and what's the proper cleaning strategy for the generated certificates?

Thanks very much for your informative && inspiring reply!

On Thu, Mar 18, 2021 at 1:47 AM Fabian Keil <[email protected]> wrote:

> Wen Yue <[email protected]> wrote on 2021-03-17:
>
> > Do you know which client is causing the messages?
> > > Has the client been configured to accept Privoxy's CA certificate?
>
> >  I'm using google chrome v89.0.4389.82 (x86_64) on macosx v10.15.6
> > catalina. The browser is configured to running in
> > '--ignore-certificate-errors' mode so it accepts all the certs generated
> > by privoxy.
>
> It may help to enable "debug 8" to see the headers of the CONNECT
> request. Maybe the problematic requests aren't coming from Chrome.
>
> The TLS negotiation can also fail if the client tries to tunnel
> another protocol through Privoxy.
>
> > I re-checked these log msg today, there's nothing severe about the client
> > connection but this one:
> >
> > 2021-03-16 22:36:07.730 7f45887d0700 Error: X509 PEM cert len 16694 is
> > > larger than buffer len 16383
> > > 2021-03-16 22:36:19.148 7f47bbfff700 Error: X509 PEM cert len 16694 is
> > > larger than buffer len 16383
> > >
> >
> > I've no idea what happened.
>
> Privoxy 3.0.32 uses buffers with a fixed size to temporarily store
> the certificates in case the server certificate can't be validated
> (in which case the user may want to inspect the certificates).
>
> The message indicates that a certificate was too large to fit
> into the buffer and got truncated. If Privoxy was able to verify
> the certificate sent by the web server this doesn't matter.
>
> I'm currently testing a patch to use dynamically allocated buffers
> which should fix this issue.
>
> > and this one:
> >
> > >  2021-03-16 22:35:39.682 7f459e7fc700 Error: A website key already
> > > exists but there's no matching certificate. Removing
> > > /tmp/privoxyTmp/certGen/3094d58afb18197cbc2b403c036290ea.pem before
> > > creating a new key and certificate.
> >
> >
> > is this message related to my certificate-cleaning strategy? Looks like
> > something is deleted when required.
>
> While this could be a result of your certificate-cleaning strategy
> it could also be the result of a previous misconfiguration.
>
> You could check if there are keys (*.pem files) left over without
> matching certificates (*.crt files) and remove them.
>
> > The best cleaning strategy depends on your goals.
> > >
> > > How did you choose 11 hours?
> > >
> >
> > The 11 hours strategy is arbitrary, I just 'feel' that would be okey.
> > Could you tell me any aspects need to consider when define the cleaning
> > strategy? thank you.
>
> Privoxy creates certificates that are valid for 90 days so certificates
> that are older than that can't be reused and have to be regenerated when
> needed anyway.
>
> On Debian GNU/Linux there is therefore a Cron job to delete certificates
> older than 90 days:
>
> https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=debian/privoxy.cron.daily;hb=HEAD
>
> If file system space is an issue, it may make sense to delete certificates
> earlier, for example by limiting the number of certificates to a certain
> value or by starting to delete certificates if they use too much space.
>
> If the file system is tracking the access time, one could consider
> the access time to decide which certificates to delete first.
>
> On a modern system creating new certificates and keys should only take
> a couple of milliseconds, though, so it's not that expensive.
>
> On my laptop I don't automatically delete keys and don't worry about
> space. The oldest certificate/key pair is from 2020-03-01, there are
> currently 6254 pairs and they only use 57 MB of space.
>
> We also have the following item on our TODO list:
> | 200) Add a config directive that causes Privoxy to remove all
> |      host certificates before exiting.
> https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=TODO;hb=HEAD#l534
>
> Of course that's mostly useful on systems that are restarted
> frequently anyway (for example my laptop).
>
> Fabian
>


-- 
Regards.
Wen Yue