Hello,
Till some recent time, I was using "socat" (http://www.dest-unreach.org/socat/) to create a SSL-wrapper (in a way similar to what "stunnel" does). I was using: === socat -ly -d -d openssl-listen:443,bind=X.X.X.X,fork,reuseaddr,cipher=HIGH:3DES:MD5,cert=server-cert.pem,key=server-key.pem,verify=0 tcp4:Y.Y.Y.Y:P ===
It was working pretty well, without interruptions, although it got some estability problems when passing 1-2 months (server apparently get stuck). So I decided to give a try to "stunnel".
I switched to "stunnel" and problems arise... I'm experimenting *very* frequent connection cuts. If I examine daemon.log (I'm using Debian 5), I have:
Oct 20 12:06:36 hetzner stunnel: LOG3[3677:3083029392]: SSL_read: 140EC071: error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac decode Oct 20 12:06:36 hetzner stunnel: LOG5[3677:3083029392]: Connection reset: 315484 bytes sent to SSL, 50471 bytes sent to socket
So it seems stunnel is closing the connection due to a "bad mac decode" error. My environment (client and server) have not changed, I only switched "the transport" (socat -> stunnel). Any idea why is it failing now? Moreover, if I switch back to socat, cuts disappear. Is stunnel buggy? Am I missing some config/tunning at the SSL/socket level?
My current config is:
roman@hetzner:~$ stunnel4 -sockets Socket option defaults: Option Accept Local Remote OS default SO_DEBUG -- -- -- 0 SO_DONTROUTE -- -- -- 0 SO_KEEPALIVE -- -- -- 0 SO_LINGER -- -- -- 0:0 SO_OOBINLINE -- -- -- 0 SO_RCVBUF -- -- -- 87380 SO_SNDBUF -- -- -- 16384 SO_RCVLOWAT -- -- -- 1 SO_SNDLOWAT -- -- -- 1 SO_RCVTIMEO -- -- -- 0:0 SO_SNDTIMEO -- -- -- 0:0 SO_REUSEADDR 1 -- -- 0 SO_BINDTODEVICE -- -- -- -- IP_TOS -- -- -- 0 IP_TTL -- -- -- 64 TCP_NODELAY -- -- -- 0
root@hetzner:~# stunnel4 -version stunnel 4.22 on i486-pc-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007 Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP
Global options debug = 5 pid = /var/run/stunnel4.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes
Service-level options cert = /etc/stunnel/stunnel.pem ciphers = AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH key = /etc/stunnel/stunnel.pem session = 300 seconds stack = 65536 bytes sslVersion = SSLv3 for client, all for server TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none
My stunnel.conf is very simple. Apart from cert setup, the tunnel is something like: === [tunelserv] accept = X.X.X:X:443 connect = X.X.X.X:P ===
Any idea? Thank you in advance.
Cheers, -Roman
Please, Ludolf, any idea about my question?
Thank you.
Cheers, -Román
Roman Medina-Heigl Hernandez escribió:
Hello,
Till some recent time, I was using "socat" (http://www.dest-unreach.org/socat/) to create a SSL-wrapper (in a way similar to what "stunnel" does). I was using: === socat -ly -d -d openssl-listen:443,bind=X.X.X.X,fork,reuseaddr,cipher=HIGH:3DES:MD5,cert=server-cert.pem,key=server-key.pem,verify=0 tcp4:Y.Y.Y.Y:P ===
It was working pretty well, without interruptions, although it got some estability problems when passing 1-2 months (server apparently get stuck). So I decided to give a try to "stunnel".
I switched to "stunnel" and problems arise... I'm experimenting *very* frequent connection cuts. If I examine daemon.log (I'm using Debian 5), I have:
Oct 20 12:06:36 hetzner stunnel: LOG3[3677:3083029392]: SSL_read: 140EC071: error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac decode Oct 20 12:06:36 hetzner stunnel: LOG5[3677:3083029392]: Connection reset: 315484 bytes sent to SSL, 50471 bytes sent to socket
So it seems stunnel is closing the connection due to a "bad mac decode" error. My environment (client and server) have not changed, I only switched "the transport" (socat -> stunnel). Any idea why is it failing now? Moreover, if I switch back to socat, cuts disappear. Is stunnel buggy? Am I missing some config/tunning at the SSL/socket level?
My current config is:
roman@hetzner:~$ stunnel4 -sockets Socket option defaults: Option Accept Local Remote OS default SO_DEBUG -- -- -- 0 SO_DONTROUTE -- -- -- 0 SO_KEEPALIVE -- -- -- 0 SO_LINGER -- -- -- 0:0 SO_OOBINLINE -- -- -- 0 SO_RCVBUF -- -- -- 87380 SO_SNDBUF -- -- -- 16384 SO_RCVLOWAT -- -- -- 1 SO_SNDLOWAT -- -- -- 1 SO_RCVTIMEO -- -- -- 0:0 SO_SNDTIMEO -- -- -- 0:0 SO_REUSEADDR 1 -- -- 0 SO_BINDTODEVICE -- -- -- -- IP_TOS -- -- -- 0 IP_TTL -- -- -- 64 TCP_NODELAY -- -- -- 0
root@hetzner:~# stunnel4 -version stunnel 4.22 on i486-pc-linux-gnu with OpenSSL 0.9.8g 19 Oct 2007 Threading:PTHREAD SSL:ENGINE Sockets:POLL,IPv6 Auth:LIBWRAP
Global options debug = 5 pid = /var/run/stunnel4.pid RNDbytes = 64 RNDfile = /dev/urandom RNDoverwrite = yes
Service-level options cert = /etc/stunnel/stunnel.pem ciphers = AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH key = /etc/stunnel/stunnel.pem session = 300 seconds stack = 65536 bytes sslVersion = SSLv3 for client, all for server TIMEOUTbusy = 300 seconds TIMEOUTclose = 60 seconds TIMEOUTconnect = 10 seconds TIMEOUTidle = 43200 seconds verify = none
My stunnel.conf is very simple. Apart from cert setup, the tunnel is something like: === [tunelserv] accept = X.X.X:X:443 connect = X.X.X.X:P ===
Any idea? Thank you in advance.
Cheers, -Roman _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
On Fri, 2009-10-23 22:06:54 +0200, Roman Medina-Heigl Hernandez wrote:
Please, Ludolf, any idea about my question?
Not really, sorry.
"bad mac decode" is a error generated by libssl. Maybe narrowing down the list of permitted ciphers helps, but that's a wild guess ...
Ludolf
Roman Medina-Heigl Hernandez escribió:
[..]
So it seems stunnel is closing the connection due to a "bad mac decode" error. My environment (client and server) have not changed, I only switched "the transport" (socat -> stunnel). Any idea why is it failing now? Moreover, if I switch back to socat, cuts disappear. Is stunnel buggy? Am I missing some config/tunning at the SSL/socket level?
-
Ludolf Holzheid -
Roman Medina-Heigl Hernandez