Segfault with OpenSSL version mismatch

[droe]

Comment by @exvance moved from #10 to new issue:

I don't know if my issue is the same as this one. It doesn't seem to matter whether or not I use the -j option.

sslsplit -D -l connections.log -k ca.key -c ca.crt ssl 0.0.0.0 8443

Generated RSA key for leaf certs.
SSLsplit (built 2013-11-29)
Copyright (c) 2009-2013, Daniel Roethlisberger daniel@roe.ch
http://www.roe.ch/SSLsplit
Features: -DDISABLE_SSLV2_SESSION_CACHE -DHAVE_NETFILTER
NAT engines: netfilter*
netfilter: !IP_TRANSPARENT SOL_IPV6 !IPV6_ORIGINAL_DST
compiled against OpenSSL 1.0.1e 11 Feb 2013 (1000105f)
rtlinked against OpenSSL 1.0.1c 10 May 2012 (1000103f)
TLS Server Name Indication (SNI) supported
OpenSSL is not thread-safe
Using direct access workaround when loading certs
SSL/TLS algorithm availability: 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.19-stable
rtlinked against libevent 2.0.19-stable
1 CPU cores detected
proxyspecs:

[0.0.0.0]:8443 ssl plain netfilter Loaded CA: '/C=US/ST=aa/L=aa/O=aa/OU=ssl/CN=aaaaa.com/emailAddress=aaaa' Using libevent backend 'epoll' Event base supports: edge yes, O(1) yes, anyfd no Inserted events: 0x888e48 [fd 7] Read Persist 0x887a34 [fd 8] Read Persist 0x888d38 [fd 6] Read Persist 0x889a30 [fd 3] Signal Persist 0x889b50 [fd 1] Signal Persist 0x889be0 [fd 2] Signal Persist 0x889c70 [fd 13] Signal Persist Failed to start thread manager

But then if I go back to version 0.4.6-1 it starts fine....but then I get the segmentation fault when I try to connect to port 8443 with telnet.

[droe]

This is most likely connected to sslsplit being built against OpenSSL 1.0.1e but run with 1.0.1c. There is a bug in 1.0.1e which requires sslsplit to use a workaround hack in order to load certificates. The use of the hack is indicated by the notice "Using direct access workaround when loading certs". Running with a different version of OpenSSL than building against may or may not work, depending on how much OpenSSL has changed between versions. Try to run sslsplit with the same version of OpenSSL it was built against. I will close this ticket since there is nothing I can do about it; if you have the same problem also when running under the same version of OpenSSL as built against then please reopen and attach a stack trace.

[exvance]

Is there something I need to do in order to use the "direct access workaround"? I'm now both compiling and running using 1.0.1e....

sslsplit -D -l connections.log -k ca.key -c ca.crt ssl 0.0.0.0 8443
Generated RSA key for leaf certs.
SSLsplit (built 2013-11-29)
Copyright (c) 2009-2013, Daniel Roethlisberger daniel@roe.ch
http://www.roe.ch/SSLsplit
Features: -DDISABLE_SSLV2_SESSION_CACHE -DHAVE_NETFILTER
NAT engines: netfilter*
netfilter: !IP_TRANSPARENT SOL_IPV6 !IPV6_ORIGINAL_DST
compiled against OpenSSL 1.0.1e 11 Feb 2013 (1000105f)
rtlinked against OpenSSL 1.0.1e 11 Feb 2013 (1000105f)
TLS Server Name Indication (SNI) supported
OpenSSL is not thread-safe
Using direct access workaround when loading certs
SSL/TLS algorithm availability: 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.19-stable
rtlinked against libevent 2.0.19-stable
1 CPU cores detected
proxyspecs:

• [0.0.0.0]:8443 ssl plain netfilter
  Loaded CA: '/C=US/ST=/L=/O=PH/OU=ssl/CN=/emailAddress='
  Using libevent backend 'epoll'
  Event base supports: edge yes, O(1) yes, anyfd no
  Inserted events:
  0xa60e48 [fd 7] Read Persist
  0xa5f5f4 [fd 8] Read Persist
  0xa60d38 [fd 6] Read Persist
  0xa61a30 [fd 3] Signal Persist
  0xa61b50 [fd 1] Signal Persist
  0xa61be0 [fd 2] Signal Persist
  0xa61c70 [fd 13] Signal Persist
  Failed to start thread manager

[exvance]

I think this issue needs to be re-opened. The recommended solution of using the same version of openssl didn't work.

[droe]

I agree, it is due to lack of time that I did not reopen yet, not due to disagreement :)

[fluxlabs]

I can second this issue. Running Debian 7/Wheezy.

root@p:/# openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Mar 18 20:41:20 CET 2013
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

root@p:/# sslsplit -V
SSLsplit 0.4.7 (built 2013-12-23)
Copyright (c) 2009-2013, Daniel Roethlisberger daniel@roe.ch
http://www.roe.ch/SSLsplit
Features: -DDISABLE_SSLV2_SESSION_CACHE -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT SOL_IPV6 !IPV6_ORIGINAL_DST
compiled against OpenSSL 1.0.1e 11 Feb 2013 (1000105f)
rtlinked against OpenSSL 1.0.1e 11 Feb 2013 (1000105f)
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
Using direct access workaround when loading certs
SSL/TLS algorithm availability: 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.19-stable
rtlinked against libevent 2.0.19-stable
2 CPU cores detected

[droe]

I'm closing this issue again since it is a (originally deliberate) duplicate of #10. Please add any new information about a failing thread manager initialisation to issue #10.