sslproxy threw some errors in dmesg in linux

[janusloo]

Hi,

After setting up port forwarding to sslproxy's listening port connection to sslproxy got stuck and in dmesg the following erros appeared:
[283850.712141] INFO: task sslproxy:27726 blocked for more than 120 seconds.
[283850.712150] Not tainted 4.14.22-v7+ #1096
[283850.712153] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[283850.712157] sslproxy D 0 27726 27725 0x00000001
[283850.712183] [<80776e60>] (__schedule) from [<807774d8>] (schedule+0x50/0xa8)
[283850.712194] [<807774d8>] (schedule) from [<8064e91c>] (__lock_sock+0x74/0x9c)
[283850.712203] [<8064e91c>] (__lock_sock) from [<8064e9ac>] (lock_sock_nested+0x68/0x70)
[283850.712218] [<8064e9ac>] (lock_sock_nested) from [<7f1785d4>] (getorigdst+0x3c/0x19c [nf_conntrack_ipv4])
[283850.712237] [<7f1785d4>] (getorigdst [nf_conntrack_ipv4]) from [<806ad578>] (nf_getsockopt+0x4c/0x64)
[283850.712246] [<806ad578>] (nf_getsockopt) from [<806baea4>] (ip_getsockopt+0xb0/0xec)
[283850.712256] [<806baea4>] (ip_getsockopt) from [<806c3378>] (tcp_getsockopt+0x34/0x50)
[283850.712265] [<806c3378>] (tcp_getsockopt) from [<8064cbf0>] (sock_common_getsockopt+0x30/0x38)
[283850.712273] [<8064cbf0>] (sock_common_getsockopt) from [<8064c1bc>] (SyS_getsockopt+0x68/0xac)
[283850.712282] [<8064c1bc>] (SyS_getsockopt) from [<80108080>] (ret_fast_syscall+0x0/0x28)

This is the netfilter port forwarding rule I used:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3443

The same firewall rules were used on Dietpi Jessie and it was working. So don't really know what went wrong here. I used the stock sslproxy.conf. Only changed the listening ports. And process cannot be killed anymore!

Please advise. Thanks!

[sonertari]

When something goes wrong with sslproxy, I recompile it with DEBUG_PROXY enabled in GNUmakefile, and start it with -D4 option to see (and save) the debug logs at the finest level. They usually tell me what it was doing when it crashed (if it crashed), but I can also observe what it is doing live (I track file descriptor numbers reported to tell connections from each other). Beware though that those debug logs are quite verbose. Also, I enable core dumps and use gdb sometimes. I usually run sslproxy on a VM for such flexibility. So I don't know if any of these is possible in your case.

On the other hand, before even enabling debug logs, if sslproxy was really running fine on Dietpi Jessie and you did not change anything else other than the OS, then I would be suspicious of the new OS first.

[janusloo]

Thanks @sonertari. I will try that and report back.

[janusloo]

Hi @sonertari I think I found an issue but not sure. In the previous issue I submitted, I think I was wrong about the openssl version I was using to compile with sslproxy, 1.1.1pre1. I compiled and installed it and later removed it all together I guessed. Not sure anymore ;-( My bad.

I reinstalled the OS in Debian Stretch, version 1.1.0f of openssl (libssl) is being used and when I tried to compile i got the following errors:

opts.c: In function ‘opts_proto_force’: opts.c:184:3: warning: ‘TLSv1_method’ is deprecated [-Wdeprecated-declarations] opts->sslmethod = TLSv1_method; ^~~~ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1612:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_method(void)) /* TLSv1.0 */ ^ opts.c:189:3: warning: ‘TLSv1_1_method’ is deprecated [-Wdeprecated-declarations] opts->sslmethod = TLSv1_1_method; ^~~~ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1618:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_method(void)) /* TLSv1.1 */ ^ opts.c:194:3: warning: ‘TLSv1_2_method’ is deprecated [-Wdeprecated-declarations] opts->sslmethod = TLSv1_2_method; ^~~~ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1624:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_method(void)) /* TLSv1.2 */ ^ opts.c: In function ‘opts_proto_dbg_dump’: opts.c:257:17: warning: ‘TLSv1_method’ is deprecated [-Wdeprecated-declarations] (opts->sslmethod == TLSv1_method) ? "tls10" : ^ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1612:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_method(void)) /* TLSv1.0 */ ^ opts.c:260:17: warning: ‘TLSv1_1_method’ is deprecated [-Wdeprecated-declarations] (opts->sslmethod == TLSv1_1_method) ? "tls11" : ^ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1618:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_method(void)) /* TLSv1.1 */ ^ opts.c:263:17: warning: ‘TLSv1_2_method’ is deprecated [-Wdeprecated-declarations] (opts->sslmethod == TLSv1_2_method) ? "tls12" : ^ In file included from /usr/include/openssl/ct.h:13:0, from /usr/include/openssl/ssl.h:61, from ssl.h:35, from opts.h:34, from opts.c:29: /usr/include/openssl/ssl.h:1624:1: note: declared here DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_method(void)) /* TLSv1.2 */ ^

libssl-dev was installed (default package in debian Stretch).

Found some info on the net: [https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Downloads]

Strange that I never saw this error before. Thought to let you know. Thank you!

[sonertari]

Can you try my last commit 5bba07b? (They are warnings, but should be fixed of course.)

Actually I was waiting for @droe's test results to commit the same patch to SSLproxy as the one I submitted to SSLsplit, but I guess you need it now and can test it too. See droe/sslsplit#183 and then droe/sslsplit#186. Please report back if it works for you.

[janusloo]

Yes the new commit works and the compilation was successful. Here is the version result of sslproxy:

SSLproxy v0.5.4-7-g5bba07b (built 2018-03-16)
Copyright (c) 2017-2018, Soner Tari sonertari@gmail.com
https://github.com/sonertari/SSLproxy
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.0f 25 May 2017 (1010006f)
rtlinked against OpenSSL 1.1.0f 25 May 2017 (1010006f)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
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.2.0-alpha-dev
rtlinked against libevent 2.2.0-alpha-dev
4 CPU cores detected

I wonder what the line Local process info support: no means?

Thank you again for your help. I ended up reinstalling Stretch. Will test run sslproxy plus e2guardian and squid (with your patches) setup in the coming days to see if it's stable.

[sonertari]

Great, thanks for the report. I'd like to hear the results of your tests with e2guardian and squid as well. I hope you can also try with OpenSSL 1.1.1pre1 which you mentioned before, because the last commit is supposed to work with it too.

See the README file for local process info, which is not available on Linux (or OpenBSD).

[janusloo]

Hi @sonertari I have also successfully compiled SSLproxy with OpenSSL 1.1.1pre3-dev. However I got warning of a mismatch with OpenSSL:

SSLproxy v0.5.4-11-ge577747 (built 2018-03-20)
Copyright (c) 2017-2018, Soner Tari <sonertari@gmail.com>
https://github.com/sonertari/SSLproxy
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.1-pre3-dev  xx XXX xxxx (10101003)
rtlinked against OpenSSL 1.1.0f  25 May 2017 (1010006f)
------------------------------------------------------------------------------
WARNING: OpenSSL version mismatch may lead to crashes or other problems!
If there are multiple versions of OpenSSL available, make sure to use
the same version of the library at runtime as well as for compiling against.
------------------------------------------------------------------------------
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
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.2.0-alpha-dev
rtlinked against libevent 2.2.0-alpha-dev
4 CPU cores detected

But no warnings while compiling. And it works perfect too! The combi of patched e2guardian + squid works beautifully. So MITM works as expected. I didn't test it extensibly though.

For the test I didn't completely remove openssl 1.1.0f as it has a lot of dependencies. I only removed the development files of OpenSSL 1.1.0f.

Thank you again for the great work!!

[sonertari]

That's good news. The warning is saying that sslproxy and libevent are compiled using different OpenSSL versions, and that's important. Thanks for trying with 1.1.1-pre3 too, but I guess you should switch back to 1.1.0f, unless there is something you really want in 1.1.1-pre3. All related programs should use the same (compatible) OpenSSL versions of course.

So I assume that this issue is fixed and I'll close it now, along with the issue #4. Thanks @janusloo again for your reports.