[Privoxy-devel] HTTPS filtering in Privoxy

Fabian Keil fk at fabiankeil.de
Sun Jun 4 13:39:58 UTC 2017


Beeblebrox <zaphod at berentweb.com> wrote:

> I had been thinking about asking this for some time but just got around
> to it. I'm very happy about this development as it ensures the future
> of privoxy (considering the mass migration to tools like lets-encrypt).
> 
> I would add ideas for consideration and if possible, implementation at
> some date. IDK how difficult these would be, so a proposal:
> 
> 1) Optional toggle to enable SSL key-quality-check, with small message
> at top of page from privoxy about check result. As an example, this tool:
> https://news.netcraft.com/archives/2013/09/06/perfect-forward-secrecy-in-the-netcraft-extension.html
> web-based checking mechanism:
> https://www.ssllabs.com/ssltest/analyze.html

This would require a lot of code and doesn't seem useful enough
to me to be worth it.

It also seems more appropriate to use an external filter for this
anyway.

While FEATURE_EXTERNAL_FILTERS is experimental and not reliable
(or even available) for all platforms, improving it would probably
still be a lot less work than adding the required code to Privoxy
itself.

> 2) Optional toggle to force SSL when and if available, like EFF's
> HTTPS-everywhere. Granted, there is tcpcrypt.org, and this can already
> be set up as downstream proxy by privoxy forward-rule, but it has
> several problems a) looks like development is inactive b) seems to
> require raw sockets, which I'm not going to allow in my FreeBSD privoxy
> Jail :)) and c) requires some inane firewall rules (presumably for
> control sockets)

Privoxy can already rewrite URLs today. Once the TLS/SSL code
has been integrated "forcing SSL" should simply require a client
header filter that changes the protocol from http to https or
a redirect action that does it with a redirect.

> Finally, a choice for libressl over openssl (but you're already there
> probably)

The proposed patch doesn't use OpenSSL but mbedtls.

As Privoxy is licensed under the GNU GPLv2, the license mixes
used by OpenSSL and LibReSSL currently make them unattractive
from a license compliance point of view.

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/20170604/9ff41de6/attachment.bin>


More information about the Privoxy-devel mailing list