Certificate error: loading src server certificate failed

[jsommer1738]

This is very similar to #246. I'm running Kali 2019.1 with SSLsplit 0.5.4 and see the "loading src server certificate failed" error.. I tested the same commands using SSLsplit 0.5.2 and everything works fine.

Below are the commands that I used to set up the server, client and SSLsplit. The failing output from the server, client and SSLsplit are attached.

Server

The default options were used for the openssl req command.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -in server.csr -signkey server.key -out server_signed_cert.pem
openssl s_server -accept 9999 -key server.key -cert server_signed_cert.pem -debug

SSLsplit

The default options were used for the openssl req command.

openssl genrsa -out fake.key 2048
openssl req -new -key fake.key -out fake.csr
openssl x509 -req -in fake.csr -signkey fake.key -out fake_signed_cert.pem
sslsplit -D -c fake_signed_cert.pem -k fake.key ssl 0.0.0.0 8888 192.168.128.129 9999

Connections

Initial connection directly to server to prove the server/client works fine:
openssl s_client -connect 192.168.128.129:9999

Follow up connection via SSLsplit:
openssl s_client -connect 192.168.128.134:8888

openssl-client-trace.txt
openssl-server-trace.txt
sslsplit-trace.txt

[sonertari]

Thanks for your detailed report. But a request first: Can you try the same with the -r tls12 option and report back please?

I couldn't reproduce the error you have reported using exactly the same commands you have provided (I have copy-pasted from your files). But I only have Kali 2018.1 (not Kali 2019.1), which may explain the different results I have obtained. Kali 2018.1 comes with sslsplit 0.5.0, which does not cause the error you report. So I have compiled the latest develop branch of sslsplit (0.5.4-21-g67b767a), which does not cause that error either, with or without the -r tls12 option.

Please review the debug output below, but pay special attention to the debug line reporting that the client-side is using TLS 1.3: SSL connected from [172.16.205.136]:44390 TLSv1.3 TLS_AES_256_GCM_SHA384, which may or may not explain the error you are seeing on Kali 2019.1.

Currently, sslsplit does not support TLS 1.3, hence my request above to disable TLS 1.3. (Unfortunately, there is currently no way of disabling TLS 1.3 only, such as using a -R tls13 option. Perhaps we should add it soon.)

$ ./sslsplit/sslsplit -D -c fake_signed_cert.pem -k fake.key ssl 0.0.0.0 8888 172.16.205.136 9999
SSLsplit 0.5.4-21-g67b767a (built 2019-03-01)
Copyright (c) 2009-2018, 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.1a  20 Nov 2018 (1010101f)
rtlinked against OpenSSL 1.1.1a  20 Nov 2018 (1010101f)
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.8-stable
rtlinked against libevent 2.1.8-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.8.1
2 CPU cores detected
Generated RSA key for leaf certs.
SSL/TLS protocol: negotiate
proxyspecs:
- [0.0.0.0]:8888 ssl [172.16.205.136]:9999
Loaded CA: '/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd'
Privsep fastpath enabled
Created self-pipe [r=3,w=4]
Created chld-pipe [r=5,w=6]
Created socketpair 0 [p=7,c=8]
Created socketpair 1 [p=9,c=10]
Created socketpair 2 [p=11,c=12]
Created socketpair 3 [p=13,c=14]
Created socketpair 4 [p=15,c=16]
Created socketpair 5 [p=17,c=18]
Privsep parent pid 44503
Privsep child pid 44504
Using libevent backend 'epoll'
Event base supports: edge yes, O(1) yes, anyfd no
Received privsep req type 00 sz 1 on srvsock 7
Dropped privs to user - group - chroot -
Received privsep req type 00 sz 1 on srvsock 9
Received privsep req type 00 sz 1 on srvsock 11
Received privsep req type 00 sz 1 on srvsock 13
Received privsep req type 00 sz 1 on srvsock 15
Received privsep req type 00 sz 1 on srvsock 17
Inserted events:
  0x564330628d88 [fd  4] Read Persist Internal
  0x564330628f60 [fd  6] Read Persist Internal
  0x564330631d28 [fd  7] Read Persist
  0x564330632000 [sig 1] Signal Persist
  0x564330632130 [sig 2] Signal Persist
  0x564330629000 [sig 3] Signal Persist
  0x564330629910 [sig 10] Signal Persist
  0x564330632260 [sig 13] Signal Persist
  0x5643306288c0 [sig 15] Signal Persist
  0x5643306336e0 [fd  -1] Persist Timeout=1551456403.930817
Active events:
Initialized 4 connection handling threads
Started 4 connection handling threads
Starting main event loop.
SNI peek: [n/a] [complete]
Connecting to [172.16.205.136]:9999
===> Original server certificate:
Subject DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Fingerprint: 13:7E:62:93:7D:EB:84:55:88:94:84:2C:5D:53:0F:8F:A6:AD:4F:44
Certificate cache: MISS
===> Forged server certificate:
Subject DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Fingerprint: 46:AC:BA:A8:38:AC:13:7E:6D:BB:4B:E0:7D:20:5B:3C:77:E5:1A:DE
SSL connected to [172.16.205.136]:9999 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
CLIENT_RANDOM FAF1089043E2D3610B9294603FBF9BC80BFBB01A13B89B64D4A05E98759D793F 179044E435C670348E84BB3B677CFB90BB2963EB14F4CD9CE3D846DBE86886CC3EA7517B60B91EB9D87CF112F1DFE28A
ssl 172.16.205.136 44378 172.16.205.136 9999 sni:- names:- sproto:TLSv1.3:TLS_AES_256_GCM_SHA384 dproto:TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 origcrt:137E62937DEB84558894842C5D530F8FA6AD4F44 usedcrt:46ACBAA838AC137E6DBB4BE07D205B3C77E51ADE
SSL connected from [172.16.205.136]:44378 TLSv1.3 TLS_AES_256_GCM_SHA384
CLIENT_RANDOM FF8A93A5E66AA415480A32499B1AE432AFA46410F759CAFD290BE00D90A98AD9 B3CF44ADBD3BB26739ABCBDAACA5CBB95AC5CB1D56C30D4A3A0D551E5652053D52053782949CAC20C7B6527943D2FF3D
Terminating connection (out of memory)!
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [connect socket]
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [accept socket]
Garbage collecting caches started.
Garbage collecting caches done.
SNI peek: [n/a] [complete]
Attempt reuse dst SSL session
Connecting to [172.16.205.136]:9999
===> Original server certificate:
Subject DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Fingerprint: 13:7E:62:93:7D:EB:84:55:88:94:84:2C:5D:53:0F:8F:A6:AD:4F:44
Certificate cache: HIT
===> Forged server certificate:
Subject DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Fingerprint: 46:AC:BA:A8:38:AC:13:7E:6D:BB:4B:E0:7D:20:5B:3C:77:E5:1A:DE
SSL connected to [172.16.205.136]:9999 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
CLIENT_RANDOM 320EF92D5EFEF91A6355A3E3BFCF2AE3C9BD2BE319549FD50B642A1338198EBF 179044E435C670348E84BB3B677CFB90BB2963EB14F4CD9CE3D846DBE86886CC3EA7517B60B91EB9D87CF112F1DFE28A
ssl 172.16.205.136 44390 172.16.205.136 9999 sni:- names:- sproto:TLSv1.3:TLS_AES_256_GCM_SHA384 dproto:TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 origcrt:137E62937DEB84558894842C5D530F8FA6AD4F44 usedcrt:46ACBAA838AC137E6DBB4BE07D205B3C77E51ADE
SSL connected from [172.16.205.136]:44390 TLSv1.3 TLS_AES_256_GCM_SHA384
CLIENT_RANDOM B87B2BE8AD84BD02CE5E4F62610DD382843CF2B1659B4FD3CD3367E5F5C5B5EA AA07B52DEF634E4BAC188B9608578D8E3754689EFF9A620CE97DC3DFF7F4794231106206BA120A9B78CE8D4BD1F32D82
Garbage collecting caches started.
Garbage collecting caches done.
Terminating connection (out of memory)!
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [connect socket]
SSL_free() in state 00000001 = 0001 = SSLOK  (SSL negotiation finished successfully) [accept socket]
Garbage collecting caches started.

[sonertari]

Btw, another difference to watch out is that I have used the same IP address 172.16.205.136 for all connections. You use separate IP addresses for the server and sslsplit. Note that the OP of #246 reported that the issue was about routing.

[sonertari]

@jsommer1738 Can you please try the latest commit I have just pushed to the develop branch? I think I have found an issue which may be related with what you have reported (but I cannot say I was able to reproduce the error you have reported). 8c7e5b6 solves the Terminating connection (out of memory)! issue in the debug output I have above.

[etrashcan]

@sonertari I've same issue, I tried latest development branch as you suggested and I still see the issue.

Linux kali 4.18.0-kali3-amd64 #1 SMP Debian 4.18.20-2kali2 (2018-11-30) x86_64 GNU/Linux

log.txt

[etrashcan]

@sonertari attaching trace file just in case if it can help debug the issue.

trace.txt

[sonertari]

@etrashcan Thanks for the log files. My current theories are (but I cannot test them as I cannot reproduce the issue here):

1. When we generate a test CA cert/key pair, we tend to leave certain fields blank. For example, @jsommer1738 and I have left some fields blank and the rest with default values (I have just hit enter all the way). And you have left the emailAddress blank at least, right? So, perhaps we should fill in all the fields (to see if it's going to make any difference at all).
2. I cannot tell from your log files if you have disabled TLS 1.3. So, perhaps we should disable it (to see if it's going to make any difference at all).

Can you test my theories for me please? Btw, enabling DEBUG_CERTIFICATE in GNUmakefile may provide further info, not sure DEBUG_PROXY and DEBUG_SESSION_CACHE would help but wouldn't hurt. (I wish I had access to a Kali 2019.1 to do it myself. Perhaps in a few weeks.)

[etrashcan]

@sonertari I've disabled TLS1.3 in client chrome browser, generated new certs and rebuilt the binary with debug flags.
log_03032019.txt

kali_sslsplit.pcapng.txt

[sonertari]

@etrashcan Thanks for the files and testing my theories. Unfortunately, I couldn't come up with an explanation even with the new information you have provided. I think I really need a Kali 2019.1 to reproduce the issue myself.

[jsommer1738]

@sonertari , I tried using the -r tls12 flag and it did not resolve the issue. I did see that on the openssl client and on the client facing side of sslsplit that TLS v1.2 was being used, i.e. the flag was honored.

Regarding the routing topic in #246 I'm really don't this particular issue is a routing issue. Honestly, I'm not sure how #246 could have been anything different than what we're seeing in this issue. Maybe for #246 they switched something about the client configuration and falsely attributed it to routing?

The reason I'm convinced this issue is not routing is that I can watch the network traffic with Wireshark and I see that all parties are talking correctly until the sslsplit upstream link (openssl server facing) send an Encrypted Alert. You can see this in frame 9 of the attached server_side.pcapgn file. These captures, were taken with the -r tls12 flag set on the openssl client. I had to zip the files due to a restriction GitHub imposes.

captures.zip

[sonertari]

Thanks for reporting back. I agree with your comments. I hope to work on this issue as soon as I can setup a Kali 2019.1 test system.

[sonertari]

Btw, I have tried (and failed) to reproduce this issue on the following platforms: OpenBSD 6.4, Linux Mint 19 Tara, Kali 2018.1, and Ubuntu 18.10. If you (anyone) have access to such systems, we can test if this issue happens only on Kali 2019.1.

[jsommer1738]

I'll see what I can do.

[sonertari]

I was able to reproduce this issue on Kali 2019.1a, and I think I have fixed it on the new rsa-key-size branch. Can you (anyone) try the rsa-key-size branch and report back please? (It works here.)

The issue was that OpenSSL 1.1.1b does not accept 1024 bit RSA keys anymore, giving an error like SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310. So, I have increased the key size of forged certificates to 2048 for OpenSSL 1.1.1 and up. (I haven't checked exactly which openssl version adds this security feature, so perhaps we can be more specific about it later on.)

[etrashcan]

@sonertari I just tried it out and it's working.

SSLsplit 0.5.4-23-g8ac2134 (built 2019-03-26)
Copyright (c) 2009-2018, 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.1a 20 Nov 2018 (1010101f)
rtlinked against OpenSSL 1.1.1a 20 Nov 2018 (1010101f)
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.8-stable
rtlinked against libevent 2.1.8-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.8.1
2 CPU cores detected
Generated RSA key for leaf certs.
SSL/TLS protocol: tls10

[sonertari]

Great, thanks for reporting back.

[sonertari]

It turns out that this issue is not related to OpenSSL, but Debian! Please read the explanation of Debian Security Level Update here. So, as explained there, you can fix this issue by changing the last section in /etc/ssl/openssl.cnf to something like (which drops the security level from 2 to 1):

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

So I should modify the rsa-key-size branch based on this finding.

[sonertari]

I think it is a better idea to set the security level of SSL ctx of connections to 1, instead of increasing the default RSA key size. So, I have reverted my last commit, and now I call SSL_CTX_set_security_level() before loading forged certificates (this function is available with OPENSSL_VERSION_NUMBER >= 0x10100000L only).

[sonertari]

Merged rsa-key-size to develop. We can add a LeafKeyRSABits option in the future too.

[Numlk12]

Hi, i met the same problem again, and my Kali version is 2019.2 in VmwareWorkstation, but the version of sslspilt is below:
SSLsplit 0.5.4 (built 2018-11-27)
Copyright (c) 2009-2018, Daniel Roethlisberger daniel@roe.ch
https://www.roe.ch/SSLsplit
Build info: V:FILE HDIFF:0 N:06fdafa
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.1.1a 20 Nov 2018 (1010101f)
rtlinked against OpenSSL 1.1.1b 26 Feb 2019 (1010102f)
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.8-stable
rtlinked against libevent 2.1.8-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.8.1
4 CPU cores detected

[sonertari]

Can you try the develop branch and report back?

[droe]

@sonertari - I think in order to maximize interoperability in default configuration, we need to bump the default leaf key size to 2k in addition to setting the security level to 1 on our end. We do not necessarily need to make the bits configurable; users who want to use a small leaf key for extra performance can already do so by using the -K option to specify a smaller leaf key they generated manually.

[sonertari]

Done.

[droe]

I've made the comments and manual page reflect the current situation regarding leaf key sizes. Also I lowered the security level to 0 in order to not impose any restrictions on our end (maximum interop by default). We may want to make the security level to use configurable, but the default should be 0.

Closing this issue - if this does not fix the issue for anyone using the latest develop branch, please comment here and we'll reopen.