[Privoxy-devel] 0004-Enable-building-Privoxy-with-OpenSSL

[Fabian Keil]

Lee <ler762 at protonmail.com> wrote on 2023-08-09 at 07:37:00:

> On Wednesday, August 9th, 2023 at 5:19 AM, Fabian Keil wrote:
> 
> > The patch looks reasonable to me, but please split it
> > in two using one for the changes to openssl.c and project.h
> > and one for the change to windows/MYconfigure.
> 
> OK.. but are the changes to openssl.c and/or project.h necessary for anything besides Windows?
> I don't mind splitting it into two patches - I'd just like to understand the reasoning.

In general, I prefer small commits as I consider them
easier to review and more convenient when bisecting in
case of regressions.

Looking at your commit 96a448cdd70b I now think it could
even have been split in two again, one commit with the
changes to project.h which I assume where required
to get this to build (in which case this could have
been mentioned in the commit message) and another one
with the change to openssl.c to prevent the "crashes".

I also think the line "windows: Enable building Privoxy with OpenSSL"
is a bit misleading as the commit does not actually change
the TLS library (while the commit a87d1d6ab does).

I think a line like "windows: Fix the build with OpenSSL"
would be more appropriate as leading line for commit 96a448cdd.

In general I try to produce good commit messages myself
but of course I'm not perfect either and, for example,
regret that I didn't add another paragraph or two for
53748ca8ca.

Probably the developer manual should contain a couple
of example commit messages ...

> > What is the motivation behind the patch?
> 
> The big one was Mbed-tls does _not_ do TLS 1.3; OpenSSL does.
> My understanding is that TLS 1.3 is the only secure version.

I agree that using TLSv1.3 is preferable to TLSv1.2.

> A minor concern was related to fingerprinting.  Anyone using
> Privoxy with https-inspection enabled would stand out since
> FF and (i believe)Chrome use TLS1.3

I suspect that Privoxy users with https-inspection enabled
will still stand out if someone is carefully looking at the
TLS handshake but I agree that using TLS 1.2 is even easier
to detect.

Of course using HTTP/1.1 instead of HTTP/2 can be detected
as well.

> > Did you measure
> > better performance than with MbedTLS (which would not surprise
> > me giving my own benchmarks at [0])? If yes, you may want
> > to mention it in the commit message.
> 
> No, I didn't measure performance.  IMO security trumps
> performance, so I didn't care if it was faster or slower.

I agree that security trumps performance.

> > One issue I see with the patch is that using an external
> > Apache2-licensed library like OpenSSL 3.x requires the
> > Privoxy binary to be distributed under GPLv3 (or later)
> > instead of GPLv2 or later so the win32_blurb[] in win32.c
> > may need a modification before the next release so we don't
> > mislead our users.
> 
> Didn't Mbed-TLS require changing the Privoxy license to GPLv2 or 3?

In e8baaf115bc I changed the license for pcrs.c to GPLv2
or later after getting permission from Andreas.

This was necessary to be able to legally distribute a Privoxy
binary that is linked to an mbedTLS version that is distributed
under the Apache 2 license.

> I thought I was safe enabling privoxy to use openssl..

I'm not saying that it can't be legally done but OpenSSL
is not a system library on Windows so linking to it isn't
covered by this "special exception" in the GPLv2:

|                                                   However, as a
| special exception, the source code distributed need not include
| anything that is normally distributed (in either source or binary
| form) with the major components (compiler, kernel, and so on) of the
| operating system on which the executable runs, unless that component
| itself accompanies the executable.

Therefore, in my opinion, a Privoxy binary for Windows that is linked
to and distributed with an OpenSSL library under the Apache 2 license
has to be distributed under the GPLv3 or later instead of GPLv2 or
later.

As it looks like more recent MbedTLS versions are licensed
under the Apache 2 license now as well we seem to have a
problem either way ...

As I mentioned before I intend to commit the WolfSSL support in
the near future and hope that it works well enough on Windows that
you can enable it instead of OpenSSL or MbedTLS.

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/20230810/8dae7ef2/attachment.bin>