Is SSLsplit the right tool to intercept and re-encrypt HTTPS traffic on a wifi router?
I'm looking to do a vulnerability research on products running on a variety of devices by intercepting their HTTPS traffic, but I don't want to modify the devices aside from installing a custom cert.
It seems SSLsplit does what I want, as it allows for "connections [to be] transparently intercepted through a network address translation engine and redirected to SSLsplit". From what I understand, these NAT rules don't have to be defined on the device that is running the application being MITM-ed, and I can customize iptables to redirect router traffic through SSLsplit on a device running Fruity Wifi or OpenWRT.
Is SSLsplit with modified iptables rules sufficient and a reasonable way to go about this, or would I have to modify other parts of the Linux networking system, as well?
NOTE : The system I am trying to build requires devices to have a cert installed to the trusted root store to "opt in" to this interception. I am not trying to build a system to intercept arbitrary traffic from unwilling devices.
You have two parts here: The SSLsplit which acts as the web server clients are connecting to, and NAT which swaps out destination addresses in packets to redirect them to the SSLsplit server.
NAT needs to be set up on the router that the client devices use, changing the destination address of the packets from the actual destination server to the SSLsplit server.
Then SSLsplit can pick up the connection and do its thing: connecting to the foreign host (available in the TLS handshake) and forwarding the response.
So, the only thing from networking perspective is that you need to make sure clients get such network options that their default gateway points to a router doing the NAT.
In short, yes it can be the right tool, but in fact it makes no odds if you are using SSLStrip, SSLSplit, mitmproxy or any other tool that can do your job, you should only beware of the way it works.
As @Quantim mentioned, this is not possible without installing/having custom cert/CA in device behind the router since it needs custom CA to act as a man-in-the-middle for SSL connections and it needs to be able to generate and sign certificates that the victim trusts. Thereby the victim must have the attacker’s root CA certificate in its trust store. Explaining how CAs work and how you can achieve your desirable result using the mentioned tools is beyond the scope of this answer, but depending on the type of client - desktop browser or mobile phone - you should note that installing the root certificates differs a bit.
SSLsplit works quite similar to other transparent SSL proxy tools - like mitmproxy which has more features and is more complex. It acts as a man-in-the-middle between the client and the actual server. Provided that traffic is being redirected to the server on which SSLsplit is running and listening by changing the default gateway, ARP spoofing, forging DNS entries or any other means. In other words, as you might have guessed, SSLsplit picks up SSL connections in a way that pretends to be the actual server that the client is connecting to and is willing to communicate with. In fact it dynamically generates a certificate and signs it with the private key of a CA certificate that the client must - is going to - trust.
So to answer your question "Is SSLsplit the right tool to intercept and re-encrypt HTTPS traffic on a wifi router?", yes it can be, but do you know enough to do so? If yes so, go and hit the jackpot with your research.
And to answer "Is SSLsplit with modified iptables rules sufficient and a reasonable way to go about this, or would I have to modify other parts of the Linux networking system, as well?", I should say that if you have correctly configured your IPTables rule-sets, and NAT/DNAT rules, and if your clients can consider the CA cert as trusted, yes that'll be sufficient - with modified iptables rule-sets and redirecting clients' traffic to the server you are going to intercept the clients' traffic on, as mentioned before. By the way, you need to note that the word "transparent" in computing means (of a process or interface) functioning without the user being aware of its presence.
Excerpt from the original documentation :
SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit generates and signs forged X509v3 certificates on-the-fly, based on the original server certificate subject DN and subjectAltName extension. SSLsplit 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, SSLsplit supports SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2, and optionally SSL 2.0 as well. SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way. For HTTP and HTTPS connections, SSLsplit removes response headers for HPKP in order to prevent public key pinning, for HSTS to allow the user to accept untrusted certificates, and Alternate Protocols to prevent switching to QUIC/SPDY. As an experimental feature, SSLsplit supports STARTTLS mechanisms in a generic manner.
Redirection
Since the OP needs to know how to redirect requests to SSLsplit but doesn't want to set up a proxy - as mentioned in comments - I am going to give a quick insight into doing this and I hope it will help :
Scenario 1 : If SSLsplit is on the OpenWRT which you are using - i.e. if SSLsplit is set on the GateWay which victims (clients) are connecting to :
|
VICTIMS | ATTACKER
|
+-------~+ | (GATEWAY) If SSLsplit is set on the Gateway users are gonna connect to, you only need to redirect some ports to those SSLsplit is listening on
| | | SSLsplit will be running on two ports: 8080 for non-SSL TCP connections and 8443 for SSL connections.
| | ---> |
| | | sysctl -w net.ipv4.ip_forward=1
+~~~~~~~~+ | iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
| \ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 (HTTPS)
+-------~+ | \ +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 636 -j REDIRECT --to-ports 8443 (LDAPS)
| | | \ | | iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443 (MSA) Encryption = StartTLS
| | ---> | ===➤ | | iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443 (SMTPS) Encryption = SSL
| | | / | | iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443 (IMAPS) Encryption = StartTLS
+~~~~~~~~+ | / +~~~~~~~~+ iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080 (XMPP)
| / ...
+-------~+ |
| | |
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Scenario 2 : AND IF SSLsplit is not set on the GateWay whic clients are connecting to - You will be in need of setting DNAT as the following :
VICTIMS | GATEWAY
|
+-------~+ |
| | |
| | ---> | IPTables will be like this :
| | |
+~~~~~~~~+ | SSLsplit iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 443 -j DNAT --to-destination z.z.z.z:8443
| \ iptables -t nat -A PREROUTING -d x.x.x.x/CIDR -p tcp -m tcp --dport 465 -j DNAT --to-destination z.z.z.z:8443
+-------~+ | \ +~~~~~~~~+ +~~~~~~~~+ ...
| | | \ | | | |
| | ---> | ===➤ | | ---------> | | In this scenario, all packets arriving on the router with a destination of x.x.x.x/CIDR will
| | | / | | | | depart from the router with a destination of z.z.z.z
+~~~~~~~~+ | / +~~~~~~~~+ +~~~~~~~~+
| /
+-------~+ | Redirects desired connection from somewhere
| | | to somewhere else to desired ports.
| | ---> |
| | |
+~~~~~~~~+ |
|
|
Pay attention about setting the value of net.ipv4.ip_forward to 1. The command I used above by using sysctl -w is not permanent. If you want to set it permanently, you should edit the file /etc/sysctl.conf where you can add a line containing net.ipv4.ip_forward = 1.
By default most Linux distributions will have IP Forwarding disabled. And IMHO this is a good idea, as most peoples won't be in need of using it, but since you are setting up a Linux router/gateway - useful for VPN server (pptp or ipsec) either - you need to enable forwarding. This can be done in several ways as I have showed you some.