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

[mythosking]

It should be noted that I captured packets through tcpdump on the server running sslsplit and found no client Hello message.
All message information is as follows:

[root@localhost mythos]# curl -x HTTPS_PROXY://192.168.66.52:443 https://www.baidu.com -k
curl: (56) Recv failure: Connection reset by peer

Info:

[root@localhost sslsplit-0.5.5]# ./sslsplit -D -l connections.log -j /tmp/sslsplit/ -S /tmp/sslsplit/logdir/ -k /home/mythos/tmp/sslsplit-keys/ca.key -c /home/mythos/tmp/sslsplit-keys/ca.crt https 0.0.0.0 9443 tcp 0.0.0.0 8080
ConnectLog: /home/mythos/open/sslsplit-0.5.5/connections.log
Chroot: /tmp/sslsplit
ContentLogDir: /tmp/sslsplit/logdir
CAKey: /home/mythos/tmp/sslsplit-keys/ca.key
CACert: /home/mythos/tmp/sslsplit-keys/ca.crt
| Warning: -F requires a privileged operation for each connection!
| Privileged operations require communication between parent and child process
| and will negatively impact latency and performance on each connection.
SSLsplit 0.5.5 (built 2021-09-16)
Copyright (c) 2009-2019, Daniel Roethlisberger [email protected]
https://www.roe.ch/SSLsplit
Build info: V:DIR N:83c4edf
Features: -DDEBUG_CLIENTHELLO_PARSER -DDEBUG_OPTS -DDEBUG_PRIVSEP_SERVER -DDEBUG_PROXY -DDEBUG_THREAD -DHAVE_NETFILTER -DWITH_SSLV2
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.0.2k 26 Jan 2017 (100020bf)
rtlinked against OpenSSL 1.0.2k-fips 26 Jan 2017 (100020bf)
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: ssl3 tls10 tls11 tls12
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.0.21-stable
rtlinked against libevent 2.0.21-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.5.3
4 CPU cores detected
Generated 2048 bit RSA key for leaf certs.
SSL/TLS protocol: negotiate
proxyspecs:

• [0.0.0.0]:8080 tcp netfilter
• [0.0.0.0]:9443 ssl|http netfilter
  Loaded CA: '/C=XX/L=Default City/O=Default Company Ltd'
  SSL/TLS leaf certificates taken from:
• Generated on the fly
  Privsep fastpath disabled
  Created self-pipe [r=4,w=5]
  Created chld-pipe [r=6,w=7]
  Created socketpair 0 [p=8,c=9]
  Created socketpair 1 [p=10,c=11]
  Created socketpair 2 [p=12,c=13]
  Created socketpair 3 [p=14,c=15]
  Created socketpair 4 [p=16,c=17]
  Created socketpair 5 [p=18,c=19]
  Privsep parent pid 3852
  privsep_server select()
  Privsep child pid 3854
  Using libevent backend 'epoll'
  Event base supports: edge yes, O(1) yes, anyfd no
  privsep_server woke up (1)
  privsep_server woke up (2)
  Received privsep req type 03 sz 9 on srvsock 8
  privsep_server select()
  privsep_server woke up (1)
  privsep_server woke up (2)
  Received privsep req type 03 sz 9 on srvsock 8
  privsep_server select()
  privsep_server woke up (1)
  privsep_server woke up (2)
  Received privsep req type 00 sz 1 on srvsock 8
  srveof[0]=1
  privsep_server select()
  Dropped privs to user nobody group - chroot /tmp/sslsplit
  privsep_server woke up (1)
  privsep_server woke up (2)
  Received privsep req type 00 sz 1 on srvsock 10
  srveof[1]=1
  privsep_server select()
  privsep_server woke up (1)
  Inserted events:
  privsep_server woke up (2)
  0x149c470 [fd 7] Read Persist
  Received privsep req type 00 sz 1 on srvsock 16
  0x149d1c0 [fd 8] Read Persist
  srveof[4]=1
  0x149ce00 [fd 10] Read Persist
  0x149c2a8 [fd 6] Read Persist
  privsep_server select()
  0x149c510 [fd 15] Signal Persist
  0x149d4b0 [fd 3] Signal Persist
  privsep_server woke up (1)
  0x149d620 [fd 1] Signal Persist
  privsep_server woke up (2)
  0x149d790 [fd 2] Signal Persist
  0x149d900 [fd 13] Signal Persist
  Received privsep req type 00 sz 1 on srvsock 18
  0x149da70 [fd 10] Signal Persist
  srveof[5]=1
  privsep_server select()
  Initialized 8 connection handling threads
  Started 8 connection handling threads
  Starting main event loop.
  Garbage collecting caches started.
  Garbage collecting caches done.

[root@localhost sslsplit-0.5.5]# ./sslsplit -V
SSLsplit 0.5.5 (built 2021-09-16)
Copyright (c) 2009-2019, Daniel Roethlisberger [email protected]
https://www.roe.ch/SSLsplit
Build info: V:DIR N:83c4edf
Features: -DDEBUG_CLIENTHELLO_PARSER -DDEBUG_OPTS -DDEBUG_PRIVSEP_SERVER -DDEBUG_PROXY -DDEBUG_THREAD -DHAVE_NETFILTER -DWITH_SSLV2
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.0.2k 26 Jan 2017 (100020bf)
rtlinked against OpenSSL 1.0.2k-fips 26 Jan 2017 (100020bf)
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: ssl3 tls10 tls11 tls12
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.0.21-stable
rtlinked against libevent 2.0.21-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.5.3
4 CPU cores detected
[root@localhost sslsplit-0.5.5]#

[root@localhost sslsplit-0.5.5]# uname -a
Linux localhost 4.9.188-35.el7.x86_64 #1 SMP Wed Aug 7 11:27:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

error:

===> Proxy connection handler thread status:
thr[0]: 0
thr[1]: 0
thr[2]: 0
thr[3]: 0
thr[4]: 0
thr[5]: 0
thr[6]: 0
thr[7]: 0
thridx: 0
0x14aa0e0 pxy_conn_ctx_new
ClientHello parser: parsing buffer of sz 118
ClientHello parser: candidate at offset 0
ClientHello parser: byte 0: 43
ClientHello parser: ===> No match: rv 1, *clienthello NULL
Peeking did not yield a (truncated) ClientHello message, aborting connection
0x14aa0e0 pxy_conn_ctx_free

[sonertari]

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.

[mythosking]

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!

[sonertari]

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.

[mythosking]

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?

[sonertari]

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.