Repository navigation
Error from src bufferevent #299
Description
Activity
Note first that your compiled and rtlinked OpenSSL versions do not match. You should have the same version for both.
I think the error says that the client and sslsplit could not agree on a cipher. sslsplit does not write an "SSL connected from" log for the client.
But, I wonder what the client application is here, which web browser?
I've installed it via "brew install sslsplit"
Client is embedded on ARM M3Server side is free to test
Can it be related to wrong CA cert ?
OpenSSL 1.1.0+ versions have removed weak (e.g. export grade) ciphers. See this link and search for the word
removed. I think the ciphers on OpenSSL 1.1.1h/j are stronger than the ones the embedded device supports, hence they cannot agree on it.I doubt you can upgrade the ssl engine on the embedded device (now I wonder what its ssl engine is). Can you downgrade the OpenSSL on your mac? (I don't think weak ciphers can be enabled on OpenSSL 1.1.0+.)
Btw, it always amazes me to hear compiled and rtlinked version issues with openssl on osx.
Perhaps you can rebuild OpenSSL 1.1.1 with the enable-weak-ssl-ciphers option.
Great Idea. I will try and let you know. Maybe sslsplit can improve warning messages in such cases.
I sniffed working communication and negotiated params was
TLS 1.2
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)/usr/local/Cellar/openssl@1.1/1.1.1j/bin/openssl ciphers -V |grep 0xC0.0x23 0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
So I believe it is quite decentHow sslsplit will behave when client do not accept CA ?
The openssl alert must be something like "bad certificate", "unknown CA", or "certificate unknown", if the client complains about the CA cert used for forging by sslsplit. See the OpenSSL docs.
Hi, I am facing the exact same issue, here's the log:
SSLsplit 0.5.5-42-g8fb9345 (built 2025-09-16) 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.1w 11 Sep 2023 (1010117f) rtlinked against OpenSSL 1.1.1w 11 Sep 2023 (1010117f) 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 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.12-stable rtlinked against libevent 2.1.12-stable compiled against libnet 1.3 rtlinked against libnet 1.3 compiled against libpcap n/a rtlinked against libpcap 1.10.5 (with TPACKET_V3) 16 CPU cores detected Generated 2048 bit RSA key for leaf certs. SSL/TLS protocol: tls12 proxyspecs: - [0.0.0.0]:8443 ssl netfilter Loaded CA: '/O=SSLsplit Root CA/CN=SSLsplit Root CA' 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 31828 Privsep child pid 31829 Using libevent backend 'epoll' Event base supports: edge yes, O(1) yes, anyfd no Received privsep req type 03 sz 9 on srvsock 8 Received privsep req type 00 sz 1 on srvsock 8 Dropped privs to user sslsplit group - chroot - Received privsep req type 00 sz 1 on srvsock 10 Received privsep req type 00 sz 1 on srvsock 16 Received privsep req type 00 sz 1 on srvsock 18 Inserted events: 0x5e9158d6c738 [fd 5] Read Persist Internal 0x5e9158d6c910 [fd 7] Read Persist Internal 0x5e9158d6cd28 [fd 8] Read Persist 0x5e9158d6da40 [sig 1] Signal Persist 0x5e9158d423d0 [sig 2] Signal Persist 0x5e9158d6ddf0 [sig 3] Signal Persist 0x5e9158d6db50 [sig 10] Signal Persist 0x5e9158d6dd60 [sig 13] Signal Persist 0x5e9158d6d3c0 [sig 15] Signal Persist 0x5e9158d6d770 [fd -1] Persist Timeout=1758022427.571399 Active events: Initialized 32 connection handling threads Started 32 connection handling threads Starting main event loop. SNI peek: [n/a] [complete] Connecting to [47.103.85.2]:443 ===> Original server certificate: Subject DN: /C=CN/ST=xxx Common Names: [xxx] Fingerprint: 62:9F:08:58:11:53:CB:10:28:97:27:2B:C1:CD:9E:D3:05:7C:CA:4C Certificate cache: MISS ===> Forged server certificate: Subject DN: /C=CN/ST=xxx Common Names: [xxx] Fingerprint: 65:6F:62:A6:20:83:53:1A:D8:48:98:7B:29:5A:69:5F:75:2B:59:A9 SSL connected to [ip]:443 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 CLIENT_RANDOM 2DF56F73C1F759EF53B8BEEE44EA28725E5DAFFCD32AB2170B27390CF37FD856 97ABC2136E4EEB825B3D846A2D0B7E2532CC36211E2FE06C79B23DF95A88DEECF01228557C7F5C8E5173D86485035DD1 Received privsep req type 01 sz 72 on srvsock 14 Error from src bufferevent: 0:- 337092801:193:no shared cipher:20:SSL routines:378:tls_post_process_client_hello Additional SSL error: 1:1:(null):0:(null):0:(null) SSL_free() in state 00000001 = 0001 = SSLOK (SSL negotiation finished successfully) [connect socket] SSL disconnected to [47.103.85.2]:443 SSL disconnected from [10.42.0.119]:51212 SSL_free() in state 00000014 = 0014 = SSLERR (error) [accept socket] SNI peek: [n/a] [complete]The original connection (without sslsplit) is using TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384, which should be supported. And the connection can be splitted if I am testing on the local computer, but not on the device (also an embedded device using wolfssl). What might be the issue？
The wolfSSL device is the client, isn't it? The error clearly says that the wolfSSL on that device does not have a common cipher with the OpenSSL 1.1.1w that sslsplit is using. I recommend you compare the cipher lists. You can obtain the cipher list on OpenSSL by
openssl ciphers -V, but I don't have any experience with wolfSSL.Thank you for the quick response.
If I turn off sslsplit and just check the cipher suite used by the wolfSSL client in wireshark, it is using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (shown in the figure below):
on the other hand, openssl 1.1.1 also supports this cipher suite according to documentation, so I am confused what is preventing sslsplit and the client agree on a cipher suite.
A side issue is that with openssl 3.0 I cannot get the
tls_post_process_client_hellolog (it just prints null) so I have to downgrade to 1.1.1Thank you for response. I have figured out that the issue is not cipher suite, but the fact that the client explicitly uses x25519 for ec curve, which sslsplit by default does not use. I wonder whether it is possible to automatically pick up this since it is present in the client hello or indicate this error in logs.
Glad you have figured it out. Unfortunately, we obtain error strings like
no shared cipherfrom error numbers directly callingERR_reason_error_string(sslerr)in this case. And we cannot get any further info inAdditional SSL error: 1:1:(null):0:(null):0:(null)either. But, thanks for reporting.So, were you able to fix the issue by using x25519 with the ECDHCurve option?
No, I am unable to specify x25519 in sslsplit. Instead, I have to use sslproxy and set it to split mode, and it workss as expected.
sslsplit simply gives me
sslsplit: unknown curve 'x25519'Some search shows that x25519 cannot be used with
EC_KEY_new_by_curve_name: libressl/portable#114 (comment)SSLProxy works since I am using openssl 3 and therefore sslproxy is using this new api https://github.com/sonertari/SSLproxy/blob/bd43af7a1017fb9ba509e339003c39106cd14004/src/protossl.c#L429C7-L429C26
I guess at this point sslproxy is has superceded sslsplit.
It's good to hear that you have already tried SSLproxy (which I was going to suggest next), and it works. Yes, SSLproxy has extra new features, and it can act like SSLsplit via split mode, as you know.
I found such error
Is this a bug ? or I just not configured something right?
Full log