An error was encountered while using HTTPS spec: peeking did not yield a (truncated) clienthello message, aborting connection about sslsplit HOT 5 OPEN

I guess you are trying to redirect the HTTP traffic to sslsplit using an HTTPS_PROXY configuration on the curl command line. That's not how you should redirect to sslsplit. The CONNECT method is not supported by sslsplit. You should run the curl without a proxy configuration. Please see the sslsplit man page on how to redirect traffic to sslsplit, especially the DESCRIPTION section.

from sslsplit.

Yes, you basically understand what I think. I used HTTPS_PROXY configuration for curl command , the proxy server is 192.168.66.52. On this machine, I configured the NAT rules of iptables. These rules have been described in detail in the problem, the main function of these rules is to redirect traffic to the port monitored by sslsplit(https 9443 and tcp 8080). On this machine, I run sslsplit and use the parameters HTTPS 9443 and TCP 8080. Moreover, I found in the manual of sslsplit that Netfilter (iptables) is allowed to redirect traffic to sslsplit.

I need to emphasize that the curl command is only used to send HTTPS requests to the proxy server. In fact, the iptables rule on the proxy server redirects the traffic to sslsplit. I think this approach is feasible...... The sslsplit manual only describes various NAT engines, of which iptables is supported. I don't know what the problem is? Maybe there's another key point I didn't find......

In your answer, I didn't understand this sentence: the CONNECT method is not supported by sslsplit. Can you explain in detail how I should configure it? Or how to build an environment that can act as an SSL broker?

Thank you very much for your help!

from sslsplit.

When I look at the error message and the wireshark screenshot, I see that sslsplit is searching clienthello in the CONNECT packet sent by curl. Sslsplit is trying to SSL handshake with curl, but it sends a connect message. So you see, the problem is not with your other setup (netfilter rules or sslsplit config).

Please see the man page of sslsplit, it lists possible ways of redirecting traffic to sslsplit at the end of DESCRIPTION:

   Your options include running
   sslsplit on a legitimate router, ARP spoofing, ND spoofing, DNS poisoning, deploying  a  rogue  access
   point (e.g. using hostap mode), physical recabling, malicious VLAN reconfiguration or route injection,
   /etc/hosts modification and so on.

I don't think your setup will work, i.e. redirecting packets from the proxy server to sslsplit will not work, because curl will always send that connect message with the -x option. You should implement another setup where you will not need the -x option with curl.

from sslsplit.

Thank you for pointing out this key step. I saw the correct phenomenon by modifying the victim's default gateway to the machine deploying sslsplit.
But what I can't understand is, why? The traffic is also redirected to the port monitored by sslsplit. Why are the two methods so different? I want to know where this function is implemented at the code level?

from sslsplit.

Perhaps you can try autossl instead of https proxyspec, autossl may be able to skip the connect packet and keep searching for clienthello to upgrade the connection to ssl. But that's just a guess.

If you want to modify the code, you can look into the readcb function for the src side, and the clienthello parser for ssl. Your modification should be peeking and searching for a connect message in the src event buffer, similar to clienthello search. Note that your code should behave differently for http and https.

from sslsplit.