Mirror function -I not working anymore.

[Leonschmitt]

SSLProxy seems to stuck/stop when I use the -I option in combination with the -T (target) option.

In addition, only the DNS packets seem to be sent to the interface when I use only the -I (interface) option.

If I use the -I in combination with the -T, sslproxy gets stuck at this point (- Global generated on the fly) and nothing happens anymore.

sudo sslproxy -D4 -k test.key -c test.crt -I lo -T 127.0.0.1 -n https 172.16.37.45 8443

Output

sudo sslproxy -D4 -k test.key -c test.crt  -I lo -T 127.0.0.1 -n  https 172.16.37.45 8443
SSLproxy v0.9.2-1-g7033afc (built 2021-12-20)
Copyright (c) 2017-2021, Soner Tari <sonertari@gmail.com>
https://github.com/sonertari/SSLproxy
Copyright (c) 2009-2019, Daniel Roethlisberger <daniel@roe.ch>
https://www.roe.ch/SSLsplit
Build info: V:GIT
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.1.1f  31 Mar 2020 (1010106f)
rtlinked against OpenSSL 1.1.1f  31 Mar 2020 (1010106f)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12 tls13 
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.11-stable
rtlinked against libevent 2.1.11-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.9.1 (with TPACKET_V3)
compiled against sqlite 3.31.1
rtlinked against sqlite 3.31.1
4 CPU cores detected
Generated 2048 bit RSA key for leaf certs.
Global conn opts: negotiate>=tls10<=tls13|ALL:-aNULL|TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256|no ecdhcurve|no leafcrlurl|remove_http_referer|verify_peer|no user_auth_url|300|8192
proxyspecs:
- listen=[172.16.37.45]:8443 ssl|http netfilter
opts= conn opts: negotiate>=tls10<=tls13|ALL:-aNULL|TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256|no ecdhcurve|no leafcrlurl|remove_http_referer|verify_peer|no user_auth_url|300|8192
split||
Loaded Global CA: '/C=DE/ST=Germany/L=Muc/O=test/OU=testt/CN=test/emailAddress=test@test.de'
Loaded ProxySpec CA: '/C=DE/ST=Germany/L=Muc/O=test/OU=testt/CN=test/emailAddress=test@test.de'
SSL/TLS leaf certificates taken from:
- Global generated on the fly

And the program gets stuck and stops doing anything at that point.

Moreover, if I only use the -I option, only DNS packets seem to be sent to the specific interface

Wireshark records only DNS packets.

In comparison when I use the LP i can capture all TCP, HTTP Packets.

Can you tell what is going wrong here or is it a bug?

Thanks in advance and Kind regards!

[sonertari]

The source and destination addresses on your wireshark screenshot are all 127.0.0.1. The emulated packets in mirror logging should have the correct src and dst addresses in the original packets. Otherwise, they would be useless. Did you anonymize them somehow?

You use the loopback interface for mirror logging. What happens if you use a physical interface like the one with 172.16.37.45?

Those DNS packets could only be DNS over HTTPS, because you use an HTTPS proxyspec (in split style). I don't know if wireshark reports them as DNS.

So the first question that comes to my mind is: Are those DNS packets really the mirroring packets from sslproxy?

Btw, what happens if you use sslsplit instead of sslproxy? (Just to make sure the issue is with sslproxy only or not.)

On the other hand, this may as well be a bug in sslproxy. I am already looking into the source code, but I just wanted to give you a quick reply until I try your setup myself.

[sonertari]

The issue is that you are using the loopback interface and 127.0.0.1 as mirroring target. After looking into the source code, I have recalled that we determine the ethernet address of the mirroring target in logpkt_ether_lookup(). But the loopback interface does not have an ethernet address. That's why sslproxy seems stuck.

Also, accordingly, I don't think those DNS packets are from sslproxy, as I have mentioned before.

In short, you should use a physical network interface, as I have asked you to do in my previous message.

[Leonschmitt]

Thanks for your quick reply and support

You are right, the DNS packets are not from the sslproxy and with the physical network interface the sslproxy does not get stuck anymore, but the mirror function -I does not mirror packets to the specific interface, physical or not, I try with all my available interfaces and I cannot capture anything with Wireshark.

I have tried with the following options but I can't capture any mirrored packets.

sslproxy -D4 -k test.key -I lo  -c test.crt  -n  ssl 10.42.0.1  8443
sslproxy -D4 -k test.key -I wlp5s0  -c test.crt  -n  ssl 10.42.0.1  8443
sslproxy -D4 -k test.key -I enp40s  -c test.crt  -n  ssl 10.42.0.1  8443

sslproxy -D4 -k test.key -I enp4s0  -c test.crt    ssl 10.42.0.1  8443 up:1312
sslproxy -D4 -k test.key -I wlp5s0  -c test.crt    ssl 10.42.0.1  8443 up:1312
sslproxy -D4 -k test.key -I lo  -c test.crt    https 10.42.0.1  8443 up:1312

(I also tried with the -T option, same result).

But when I try it with sslsplit, everything works fine and I can capture all the decrypted traffic (see screenshot).

(Btw, I tried it with all my IFs). e.g

sslsplit -D -k test.key -c test.crt -P -I lo https 10.42.0.1 8443

e.g. with sslsplit on loopback

I think there is something wrong with the mirror option/function in sslproxy

Thanks in advance and Kind regards!

[sonertari]

Thanks a lot @Leonschmitt, you have found yet another bug.

Now I think I have fixed this issue on the develop branch, please see this patch. It seems to fix the issue you have reported. Can you please apply the patch and report back?

The bug was very simple (fortunately), apparently I forgot to update the WANT_CONNECT_LOG WANT_CONTENT_LOG macro with pcap and mirror logging. You can test it without patching the source code too, simply enable text content logging along with mirror (or pcap) logging, and you will see that mirror logging will start working (also for the lo interface with the -I option too, but not for 127.0.0.1 with the -T option as a mirroring target, my previous comments about using physical interfaces for mirroring targets are still valid).

@Leonschmitt, thanks again, please keep reporting any issues you see.