Support multiple TLS layers

[3hhh]

I noticed that sslsplit autossl currently only removes the topmost TLS layer instead of all.

E.g. when connecting to a https website over a https proxy the proxy layer will be removed, but the website layer will not.

I guess one can currently work around this limitation by chaining multiple sslplit instances.

A great tool in total though, thanks!

[sonertari]

In autossl mode, when we detect a ClientHello on the ingress path, we upgrade that TCP connection to SSL/TLS. Also see the documentation of ssl_tls_clienthello_parse() in ssl.c. So, frankly, I don't understand your comment, granted I use autossl with SMTP only. If you think that we need to do more, can you point me to the relevant documentation or further details?

[3hhh]

Let me rephrase:

user session -- (leading to) --> sslsplit pcap

TLS(proto) -- (leading to) --> proto
TLS(TLS(proto)) -- (leading to) --> TLS(proto) <-- And I'd prefer it to be proto. That's what this is about.

Chaining your sslproxy twice (or one proxy and one sslsplit) to get it done might work for the case above, but one would need to know the number of TLS tunnels beforehand in general.

So in code I'd expect recursion on the outcome of the TLS-decrypted session until sslsplit cannot do anything anymore.

Side note:
The https mode also fails in the above situation IIRC (there's not http inside after all, just another TLS layer). However mitmproxy isn't doing any better. ;-)

[sonertari]

This is not related with autossl. Why did you mention autossl in your first post?

You are asking if we can decrypt multiple encryption layers. To achieve that, you could perhaps use sslproxy as the listening program, but you would need to modify its source code to support the mode of operation required by the original sslproxy.

Do you have a real life use case for this? Other than perhaps to debug your qcrypt project.

[3hhh]

Do you have a real life use case for this?

I was recently debugging https connections of a web scraper framework tunelled via a https proxy.
But I guess these kind of double encryption layers tend to occur with corporate https proxies as well. Probably not so often though as most proxies don't use SSL (yet?).