[Privoxy-devel] Help needed from privoxy developers to make privoxy work with SSLProxy

Fri Apr 19 08:12:45 UTC 2019

Hi Lee, yes I am aware of ProxHTTPSProxyMII and been running and testing it
for quite some time now. It unfortunately does not work well with some
sites: they either don't render well or don't work at all (eg. gmail.com).
Something is not implemented I supposed. With SSLProxy the same sites that
gave issues with ProxHTTPSProxyMII work perfect. In case you have not read
the introduction of SSLProxy, I will paste the info in this mail:

SSLproxy - transparent SSL/TLS proxy for decrypting and diverting network
> traffic to other programs for deep SSL inspection [image: Build Status]
> <https://travis-ci.org/sonertari/SSLproxy>
>
> Copyright (C) 2017-2018, Soner Tari <http://comixwall.org/>.
> https://github.com/sonertari/SSLproxy
>
> Copyright (C) 2009-2018, Daniel Roethlisberger <https://daniel.roe.ch/>.
> https://www.roe.ch/SSLsplit
> <https://github.com/sonertari/SSLproxy#overview>Overview
>
> SSLproxy is a proxy for SSL/TLS encrypted network connections. It is
> intended to be used for decrypting and diverting network traffic to other
> programs, such as UTM services, for deep SSL inspection. See this
> presentation
> <https://drive.google.com/open?id=12YaGIGs0-xfpqMNAY3rzUbIyed-Tso8W> for
> a summary.
>
> SSLproxy is designed to transparently terminate connections that are
> redirected to it using a network address translation engine. SSLproxy then
> terminates SSL/TLS and initiates a new SSL/TLS connection to the original
> destination address. Packets received on the client side are decrypted and
> sent to the program listening on a port given in the proxy specification.
> SSLproxy inserts in the first packet the address and port it is expecting
> to receive the packets back from the program. Upon receiving the packets
> back, SSLproxy re-encrypts and sends them to their original destination.
> The return traffic follows the same path back to the client in reverse
> order.
>
> [image: Mode of Operation Diagram]
> <https://camo.githubusercontent.com/e0257fb77ede4ddf98c1b5a060b992b184f4acd1/68747470733a2f2f64726976652e676f6f676c652e636f6d2f75633f69643d314e5f5979356e4d50445376593859614e4664347348766970794c5771357a4479>
>
> This is similar in principle to divert sockets
> <https://man.openbsd.org/divert.4>, where the packet filter diverts the
> packets to a program listening on a divert socket, and after processing the
> packets the program reinjects them into the kernel. If there is no program
> listening on that divert socket or the program does not reinject the
> packets into the kernel, the connection is effectively blocked. In the case
> of SSLproxy, SSLproxy acts as both the packet filter and the kernel, and
> the communication occurs over networking sockets.
>
> For example, given the following proxy specification:
>
> https 127.0.0.1 8443 up:8080
>
> The SSLproxy listens for HTTPS connections on 127.0.0.1:8443. Upon
> receiving a connection from the Client, it decrypts and diverts the packets
> to a Program listening on 127.0.0.1:8080. After processing the packets,
> the Program gives them back to the SSLproxy listening on a dynamically
> assigned address, which the Program obtains from the first packet in the
> connection. Then the SSLproxy re-encrypts and sends the packets to the
> Server. The response from the Server follows the same path to the Client in
> reverse order.
>
> The program that packets are diverted to should support this mode of
> operation. Specifically, it should be able to recognize the SSLproxy
> address in the first packet, and give the first and subsequent packets back
> to the SSLproxy listening on that address, instead of sending them to the
> original destination as it normally would.
>
> A sample line SSLproxy inserts into the first packet in the connection is
> the following:
>
> SSLproxy: [127.0.0.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s
>
> The first IP:port pair is a dynamically assigned address that the SSLproxy
> expects the program send the packets back to it. The second and third
> IP:port pairs are the actual source and destination addresses of the
> connection respectively. Since the program receives the packets from the
> SSLproxy, it cannot determine the source and destination addresses of the
> packets by itself, hence must rely on the information in this SSLproxy
> line. The last letter is either s or p, for SSL/TLS encrypted or plain
> traffic respectively. This information is also important for the program,
> because it cannot reliably determine if the actual network traffic it is
> processing was encrypted or not.
>
> This mode of operation allows you to divert decrypted packets to remote
> listening programs too. For example, given the following proxy
> specification:
>
> https 127.0.0.1 8443 up:8080 ua:192.168.0.1 ra:192.168.1.1
>
> The ua option tells SSLproxy to divert decrypted packets to
> 192.168.0.1:8080, instead of 127.0.0.1:8080 as in the previous example.
> Also, the ra option tells SSLproxy to listen for returned packets from the
> program on 192.168.1.1. Accordingly, the line SSLproxy inserts into the
> first packet in the connection now becomes:
>
> SSLproxy: [192.168.1.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s
>
> So, the listening program can be running on a machine anywhere in the
> world. Since the packets between SSLproxy and the listening program are
> unencrypted, you should be careful while using such a setup.
>
> SSLproxy supports plain TCP, plain SSL, HTTP, HTTPS, POP3, POP3S, SMTP,
> and SMTPS connections over both IPv4 and IPv6. It also has the ability to
> dynamically upgrade plain TCP to SSL in order to generically support SMTP
> STARTTLS and similar upgrade mechanisms. SSLproxy fully supports Server
> Name Indication (SNI) and is able to work with RSA, DSA and ECDSA keys and
> DHE and ECDHE cipher suites. Depending on the version of OpenSSL, SSLproxy
> supports SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, and optionally SSL 2.0 as
> well.
>
> For SSL and HTTPS connections, SSLproxy generates and signs forged X509v3
> certificates on-the-fly, mimicking the original server certificate's
> subject DN, subjectAltName extension and other characteristics. SSLproxy
> has the ability to use existing certificates of which the private key is
> available, instead of generating forged ones. SSLproxy supports NULL-prefix
> CN certificates but otherwise does not implement exploits against specific
> certificate verification vulnerabilities in SSL/TLS stacks.
>
> SSLproxy implements a number of defences against mechanisms which would
> normally prevent MitM attacks or make them more difficult. SSLproxy can
> deny OCSP requests in a generic way. For HTTP and HTTPS connections,
> SSLproxy mangles headers to prevent server-instructed public key pinning
> (HPKP), avoid strict transport security restrictions (HSTS), avoid
> Certificate Transparency enforcement (Expect-CT) and prevent switching to
> QUIC/SPDY, HTTP/2 or WebSockets (Upgrade, Alternate Protocols). HTTP
> compression, encodings and keep-alive are disabled to make the logs more
> readable.
>
> Another reason to disable persistent connections is to reduce file
> descriptor usage. Accordingly, connections are closed if they remain idle
> for a certain period of time. The default timeout is 120 seconds, which can
> be changed in a configuration file.
>
> SSLproxy verifies upstream certificates by default. If the verification
> fails, the connection is terminated immediately. This is in contrast to
> SSLsplit, because in order to maximize the chances that a connection can be
> successfully split, SSLsplit accepts all certificates by default, including
> self-signed ones. See The Risks of SSL Inspection
> <https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html> for
> the reasons of this difference.
>
> Logging options include traditional SSLproxy connect and content log files
> as well as PCAP files and mirroring decrypted traffic to a network
> interface. Additionally, certificates, master secrets and local process
> information can be logged.
>
> As SSLproxy is based on SSLsplit, this is a modified SSLsplit README file.
> See the manual page sslproxy(1) for details on using SSLproxy and setting
> up the various NAT engines.
>

I think this is an interesting development of SSL intercepting. The author
is not using Privoxy (e2guardian is his preference) so he is not supporting
Privoxy in the foreseeable future. I would like to help but am not a
developer/programmer so coding is out of the question at this moment. Maybe
some of you find this interesting enough to at least take a look at this?

Thank you so much for taking time in this. I appreciate it a lot!

Best regards, Eric Chan

On Thu, 18 Apr 2019 at 21:17, Lee <ler762 at gmail.com> wrote:

> Fabian,
>
> What ever happened with
> https://lists.privoxy.org/pipermail/privoxy-devel/2017-May/000149.html
>
>
> On 4/18/19, Whispered Ocean <ec at tasale.com> wrote:
> > Hi there,
>
> Hi Eric,
>
> Take a look at
> https://sourceforge.net/p/ijbswa/mailman/message/34535224/
>
> I've never tried it, but it looks like ProxHTTPSProxyMII allows you to
> use privoxy to filter https sites without requiring any changes to
> privoxy.
>
> Regards,
> Lee
>
>
> > My name is Eric Chan and am a user of Privoxy (not a developer). I have
> > recently tested a software called SSLProxy:
> > https://github.com/sonertari/SSLproxy. It is a SSL intercepting proxy
> that
> > works really well.
> >
> > I want to let all privoxy developers know that with SSLProxy, SSL
> > intercepting and encrypting of SSL traffic will be readily available to
> > privoxy with minimal efforts (patches). The SSLProxy developer will be
> more
> > than happy to give you all the details how his software works. Please
> read
> > the information on github for more info.
> >
> > I reckon SSL traffic still cannot be intercepted now by privoxy. Now the
> > internet is transitioning to encrypted traffic and soon privoxy will
> become
> > irrelevant if it still cannot intercept SSL. I will be very sad to see
> > privoxy become obsolete in the future.
> >
> > Thank you very much for your time and efforts in developing privoxy! I
> > appreciate it!
> >
> > ---
> > ec
>

-- 
---
ec