[Privoxy-users] Why fail to open secure connection to the client incidentally, and what's the proper cleaning strategy for the generated certificates?

[Fabian Keil]

Wen Yue <miles.wy.1 at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-users/attachments/20210317/f70e353a/attachment.bin>