Transparent SSL/TLS proxy for decrypting and diverting network traffic to other programs, such as UTM services, for deep SSL inspection.
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 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.
This is similar in principle to divert sockets, 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 for the reasons of this difference.
If enabled, the UserAuth option requires network users to log in to the system to use SSLproxy (this feature is currently available on OpenBSD and Linux only). When users are logged in, they should be recorded on the users table in an SQLite3 database. SSLproxy does not create this users table by itself, so it should already exist in the SQLite3 database file configured by the UserDBPath option. The users table should be created using the following SQL statement:
CREATE TABLE USERS(
IP CHAR(45) PRIMARY KEY NOT NULL,
USER CHAR(31) NOT NULL,
ETHER CHAR(17) NOT NULL,
ATIME INT NOT NULL,
DESC CHAR(50)
);
When SSLproxy accepts a connection, it obtains the ethernet address of the client IP address from the arp cache of the system, then compares it with the value in the users table. If the ethernet addresses do not match, the connection is redirected to the login page. SSLproxy also compares the atime value in the users table with the current system time. If the difference is larger than the configured value of the user timeout option, then the connection is redirected to the login page. The atime of the IP address in the users table is updated with the system time while the connection is being terminated. Since this atime update is run using a privsep command, it is expensive. So, to reduce the frequency of such updates, it is deferred until the user idle time is more than half of the timeout period.
If the UserAuth option is enabled, the user owner of the connection is appended at the end of the SSLproxy line, so that the listening program can parse and use this information in its logic and/or logging:
SSLproxy: [127.0.0.1]:34649,[192.168.3.24]:47286,[192.168.111.130]:443,s,soner
If enabled, the ValidateProto option validates protocols in proxy specifications. If a connection cannot pass protocol validation, then it is terminated. This feature currently supports HTTP, POP3, and SMTP protocols.
PassSite option allows certain SSL sites to be excluded from SSL inspection. If a PassSite matches SNI or common names in the SSL certificate, the connection is passed through the proxy without being diverted to the listening program. For example, sites requiring client authentication can be added as PassSite. Per site filters can be defined using client IP addresses, users, and description keywords. Multiple sites can be defined, one on each line.
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.
Requirements
SSLproxy depends on the OpenSSL, libevent 2.x, libpcap and libnet 1.1.x libraries by default; libpcap and libnet are not needed if the mirroring feature is omitted. The build depends on GNU make and a POSIX.2 environment in
PATH. If available, pkg-config is used to locate and configure the dependencies. The optional unit tests depend on the check library.
SSLproxy currently supports the following operating systems and NAT mechanisms:
- FreeBSD: pf rdr and divert-to, ipfw fwd, ipfilter rdr
- OpenBSD: pf rdr-to and divert-to
- Linux: netfilter REDIRECT and TPROXY
- Mac OS X: pf rdr and ipfw fwd
Support for local process information (
-i) is currently available on Mac OS X and FreeBSD.
SSL/TLS features and compatibility greatly depend on the version of OpenSSL linked against. For optimal results, use a recent release of OpenSSL or LibreSSL.
Installation
With the requirements above available, run:
make
make test # optional unit tests
make sudotest # optional unit tests requiring privileges
make install # optional install
Dependencies are autoconfigured using pkg-config. If dependencies are not picked up and fixing
PKG_CONFIG_PATH does not help, you can specify their respective locations manually by setting OPENSSL_BASE, LIBEVENT_BASE, LIBPCAP_BASE, LIBNET_BASE and/or CHECK_BASE to the respective prefixes.
You can override the default install prefix (
/usr/local) by setting PREFIX. For more build options and build-time defaults see GNUmakefile and defaults.h.Documentation
See the manual pages
sslproxy(1) and sslproxy.conf(5) for user documentation. See NEWS.md for release notes listing significant changes between releases and SECURITY.md for information on security vulnerability disclosure.
from https://github.com/sonertari/SSLproxy
-----
Simple zero-config SSL reverse proxy with real autogenerated certificates (LetsEncrypt, self-signed, provided)
-----
Simple zero-config SSL reverse proxy with real autogenerated certificates (LetsEncrypt, self-signed, provided)
ssl-proxy
Simple single-command SSL reverse proxy with autogenerated certificates (LetsEncrypt, self-signed)
A handy and simple way to add SSL to your thing running on a VM--be it your personal jupyter notebook or your team jenkins instance.
ssl-proxy autogenerates SSL certs and proxies HTTPS traffic to an existing HTTP server in a single command.Usage
With auto self-signed certificates
ssl-proxy -from 0.0.0.0:4430 -to 127.0.0.1:8000
This will immediately generate self-signed certificates and begin proxying HTTPS traffic from https://0.0.0.0:4430 to http://127.0.0.1:8000. No need to ever call openssl. It will print the SHA256 fingerprint of the cert being used for you to perform manual certificate verification in the browser if you would like (before you "trust" the cert).
I know
nginx is often used for stuff like this, but I got tired of dealing with the boilerplate and wanted to explore something fun. So I ended up throwing this together.With auto LetsEncrypt SSL certificates
ssl-proxy -from 0.0.0.0:443 -to 127.0.0.1:8000 -domain=mydomain.com
This will immediately generate, fetch, and serve real LetsEncrypt certificates for
mydomain.com and begin proxying HTTPS traffic from https://0.0.0.0:443 to http://127.0.0.1:8000. For now, you need to ensure that ssl-proxy can bind port :443 and that mydomain.com routes to the server running ssl-proxy (as you may have expected, this is not the tool you should be using if you have load-balancing over multiple servers or other deployment configurations).Provide your own certs
ssl-proxy -cert cert.pem -key myKey.pem -from 0.0.0.0:4430 -to 127.0.0.1:8000
You can provide your own existing certs, of course. Jenkins still has issues serving the fullchain certs from letsencrypt properly, so this tool has come in handy for me there.
Redirect HTTP -> HTTPS
Simply include the
-redirectHTTP flag when running the program.Installation
Simply download and uncompress the proper prebuilt binary for your system from the releases tab. Then, add the binary to your path or start using it locally (
./ssl-proxy).
If you're using
wget, you can fetch and uncompress the right binary for your OS using getbin.io as follows:wget -qO- "https://getbin.io/suyashkumar/ssl-proxy" | tar xvz
or with
curl (note you need to provide your os if using curl as one of (darwin, windows, linux) below):curl -LJ "https://getbin.io/suyashkumar/ssl-proxy?os=linux" | tar xvz
Shameless plug:
suyashkumar/getbin (https://getbin.io) is a general tool that can fetch the latest binaries from GitHub releases for your OS. Check it out :).Build from source
Build from source using Docker
You can build
ssl-proxy for all platforms quickly using the included Docker configurations.
If you have
docker-compose installed:docker-compose -f docker-compose.build.yml up
will build linux, osx, and darwin binaries (x86) and place them in a
build/ folder in your current working directory.Build from source locally
You must have Golang installed on your system along with
make and dep. Then simply clone the repository and run make.
No comments:
Post a Comment