Capturing TLS1.2 traffic with SSLproxy

[ViAl]

Hello.
I want to analyze android application traffic between client and server. It uses tcp keep-alive connection and tls1.2.
I generated a CA private key ca.key and certificate ca.crt using OpenSSL as described in sslproxy man page.
After that i installed ca.crt in device trusted certs list.
After that i wrote simple echo-server on java, which listens for incoming connections, and returns all data received back to sender, and runned this server on 0.0.0.0:8889
I redirected all traffic from application to sslproxy, runned with following parameters: ./sslproxy ssl 137.74.74.74 8888 up:8889 -k ca.key -c ca.crt -l connect.log -D

But when client trying to connect to server through sslproxy, it fails, and i see this message in sslproxy log:

Peeking did not yield a (truncated) ClientHello message, aborting connection
Peeking did not yield a (truncated) ClientHello message, aborting connection
Peeking did not yield a (truncated) ClientHello message, aborting connection
Peeking did not yield a (truncated) ClientHello message, aborting connection
Peeking did not yield a (truncated) ClientHello message, aborting connection

Am i doing something wrong? Could i analyze my application ssl traffic with SSLproxy?

Here is SSLproxy full output with -D flag: https://pastebin.com/RsERKBLe

[sonertari]

Yes, you could analyze such traffic with a custom program you say you have written in Java.

The first sanity check would be: Are you sure you are using SSL/TLS? Since the logs are saying the proxy couldn't get a ClientHello from the client (the android application), my first guess is that the app is using plain TCP instead. If so, since SSLproxy accepts plain TCP connections too, you can add a tcp proxy spec listening on a different port and diverting to a different port (up:) also, just to test my claim if for nothing else.

I am not sure if there are issues about routing or netfilter rules, which can cause this issue: Are you sure you are redirecting the traffic to the proxy correctly? (Is it possible that the proxy cannot receive any further packets after certain point in the handshake, for some reason?)

The logs imply that the issue is on the client side and at the beginning of the connection. So you need to check the above points first, imo, but there are other things to check too, for a successful interception by sslproxy, for example: Does the Java program parse the SSLproxy line correctly and return the packets back to SSLproxy listening on that port (which is dynamically assigned hence different for each connection)?

Since I think this is happening at the very beginning, I don't think this issue is related to sonertari/UTMFW#4. But beware you may face similar issues later on.

To rule out any possibility that the issue is related with sslproxy, you might want to try sslsplit and see if it works for you instead. (And please report back if sslsplit works for you, but sslproxy doesn't.)

[studio501]

Hi ViAl did you work it out?