[Privoxy-devel] WolfSSL support ready for testing

[Fabian Keil]

Roland Rosenfeld <roland at spinnaker.de> wrote on 2024-04-01 at 19:37:35:

> On Mon, 01 Apr 2024, Fabian Keil wrote:
> 
> > > In contrast to the others, this didn't work, since X509_V_OK is part
> > > of an enum in my somewhat outdated wolfssl 5.5.4 and not a precompiler
> > > #define.
> > 
> > Thanks for testing. I made another attempt in b0a88373c96.
> 
> This now works as expected on my system.

Great.
 
> > Privoxy-Regression-Test --check-bad-ssl option already does part of
> > the work.
> 
> Oh, I didn't notice this.  But while this succeeds with mbedtls and
> openssl, it fails with wolfssl here:
> 
> $ env all_proxy=http://localhost:8118/ CURL_CA_BUNDLE=/etc/privoxy/CA/privoxy.crt privoxy-regression-test --check-bad-ssl
> 2024-04-01 19:18:10: Requesting pages from badssl.com with various certificate problems. This will only work if Privoxy has been configured properly and can reach the Internet.
> 2024-04-01 19:18:10: Requesting https://expired.badssl.com/
[...]
> 2024-04-01 19:18:13: Requesting https://incomplete-chain.badssl.com/
> 2024-04-01 19:18:14: Ooops. We expected status code 403, but received: 200.
> 2024-04-01 19:18:14: There were 7 requests that did not result in status code 403!

This is surprising.

Can you please double check that https-inspection was active
and ignore-certificate-errors wasn't?

I never had this problem with any wolfSSL version I tested.

> > Why do you prefer mbedTLS over OpenSSL?
> 
> At the moment howsmyssl.com reports mbedTLS equivalent to no-proxy,
> which sounds as a very good result to me, while OpenSSL allows
> multiple additional cipher_suites, which means less security...
> And I started to https-inspection with mbedtls in Debian 2020 (it's in
> Debian 11 and 12) and I just started to compare the three variants
> this weekend.  Before I change the library, I'd like to be sure, that
> the change improves the situation...

Makes sense.
 
> BTW: Is there a chance that you optimize the 301 "moved permanently"
> of config.privoxy.org/*?
> During my tests I temporarily switched off the proxy, which resulted
> in https://config.privoxy.org/client-tags being cached as
> 
> HTTP/1.1 301 Moved Permanently
> Server: nginx
> Date: Mon, 01 Apr 2024 17:07:13 GMT
> Content-Type: text/html
> Content-Length: 162
> Connection: keep-alive
> Location: https://www.privoxy.org/config/
> 
> After this I had to manually clear my cache, because otherwise
> https://config.privoxy.org/client-tags (and p.p/client-tags etc.) and
> changing some client tag there redirects to
> https://www.privoxy.org/config/, which is quite annoying (for other
> users it may be an even harder problem to fix, that for me).

Indeed.

> Maybe you could change this to 303 or 307 (not fully sure about this)
> or you could add some no-cache or Expires (in 1970) header?

I changed the status code to 302 which seems to prevent the problem.
Can you please confirm this?

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-devel/attachments/20240403/0f96fe78/attachment.bin>