Hi,
Last week I disabled SSLv3 on my stunnel-server. I thought I tested it, but this morning I had to use it and I couldn't get access. Now at the office I tried again, with the same result. After enabling SSLv3 again I could get access. So my configuration seems wrong. My server runs Ubuntu 12.04 LTS, stunnel is 4.42-1ubuntu (stock ubuntu). This is my stunnel.conf (tunnels removed/edited) : client = no setuid = stunnel4 setgid = stunnel4 pid = /var/run/stunnel4/stunnel4.pid debug = debug output = /var/log/stunnel4/stunnel.log
options = NO_SSLv2 options = NO_SSLv3
socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 3 CApath = /etc/stunnel-certs CAfile = /etc/stunnel/cacert.pem cert = /etc/stunnel/lace3.keycrt
[tunnel vnc] accept = 12345 connect = remotehost:5901
The log on the server : 2014.10.21 08:32:15 LOG7[28587:140281088546560]: Service tunnel vnc accepted FD=0 from 192.168.1.14:55708 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Service tunnel vnc started 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Option TCP_NODELAY set on local socket 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Waiting for a libwrap process 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Acquired libwrap process #0 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Releasing libwrap process #0 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Released libwrap process #0 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Service tunnel vnc permitted by libwrap from 192.168.1.14:55708 2014.10.21 08:32:15 LOG5[28587:140281088538368]: Service tunnel vnc accepted connection from 192.168.1.14:55708 2014.10.21 08:32:15 LOG7[28587:140281088538368]: SSL state (accept): before/accept initialization 2014.10.21 08:32:15 LOG7[28587:140281088538368]: SSL alert (write): fatal: handshake failure 2014.10.21 08:32:15 LOG3[28587:140281088538368]: SSL_accept: 1408A10B: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version number 2014.10.21 08:32:15 LOG5[28587:140281088538368]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2014.10.21 08:32:15 LOG7[28587:140281088538368]: Service tunnel vnc finished (0 left) 2014.10.21 08:32:15 LOG7[28587:140281088538368]: str_stats: 0 block(s), 0 byte(s)
The log on the client (opensuse 13.1) : 2014.10.21 08:47:47 LOG7[978:140089725433664]: local socket: FD=0 allocated (non-blocking mode) 2014.10.21 08:47:47 LOG7[978:140089725433664]: Service tunnel vnc accepted FD=0 from 127.0.0.1:39609 2014.10.21 08:47:47 LOG7[978:140089725630208]: Service tunnel vnc started 2014.10.21 08:47:47 LOG7[978:140089725630208]: Option TCP_NODELAY set on local socket 2014.10.21 08:47:47 LOG7[978:140089725630208]: Waiting for a libwrap process 2014.10.21 08:47:47 LOG7[978:140089725630208]: Acquired libwrap process #0 2014.10.21 08:47:47 LOG7[978:140089725630208]: Releasing libwrap process #0 2014.10.21 08:47:47 LOG7[978:140089725630208]: Released libwrap process #0 2014.10.21 08:47:47 LOG7[978:140089725630208]: Service tunnel vnc permitted by libwrap from 127.0.0.1:39609 2014.10.21 08:47:47 LOG5[978:140089725630208]: Service tunnel vnc accepted connection from 127.0.0.1:39609 2014.10.21 08:47:47 LOG7[978:140089725630208]: remote socket: FD=1 allocated (non-blocking mode) 2014.10.21 08:47:47 LOG6[978:140089725630208]: connect_blocking: connecting 192.168.0.30:12345 2014.10.21 08:47:47 LOG7[978:140089725630208]: connect_blocking: s_poll_wait 192.168.0.30:13001: waiting 10 seconds 2014.10.21 08:47:47 LOG5[978:140089725630208]: connect_blocking: connected 192.168.0.30:12345 2014.10.21 08:47:47 LOG5[978:140089725630208]: Service tunnel vnc connected remote server from 192.168.1.14:55770 2014.10.21 08:47:47 LOG7[978:140089725630208]: Remote FD=1 initialized 2014.10.21 08:47:47 LOG7[978:140089725630208]: Option TCP_NODELAY set on remote socket 2014.10.21 08:47:47 LOG7[978:140089725630208]: SSL state (connect): before/connect initialization 2014.10.21 08:47:47 LOG7[978:140089725630208]: SSL state (connect): SSLv3 write client hello A 2014.10.21 08:47:47 LOG7[978:140089725630208]: SSL alert (read): fatal: handshake failure 2014.10.21 08:47:47 LOG3[978:140089725630208]: SSL_connect: 14094410: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure 2014.10.21 08:47:47 LOG5[978:140089725630208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket 2014.10.21 08:47:47 LOG7[978:140089725630208]: Service tunnel vnc finished (0 left) 2014.10.21 08:47:47 LOG7[978:140089725630208]: str_stats: 0 blocks, 0 bytes
Am I missing something ? I would like to stay with Ubuntu's standard packages.
Thanks for any advice.
Koenraad Lelong.
Op 21-10-14 om 09:13 schreef Koenraad Lelong:
Hi,
...
This is my stunnel.conf (tunnels removed/edited) : client = no setuid = stunnel4 setgid = stunnel4 pid = /var/run/stunnel4/stunnel4.pid debug = debug output = /var/log/stunnel4/stunnel.log
I just added sslVersion = all
options = NO_SSLv2 options = NO_SSLv3
socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 verify = 3 CApath = /etc/stunnel-certs CAfile = /etc/stunnel/cacert.pem cert = /etc/stunnel/lace3.keycrt
[tunnel vnc] accept = 12345 connect = remotehost:5901
No solution.
Koenraad
Op 21-10-14 om 09:35 schreef Koenraad Lelong:
Op 21-10-14 om 09:13 schreef Koenraad Lelong:
Hi,
...
This is my stunnel.conf (tunnels removed/edited) : client = no setuid = stunnel4 setgid = stunnel4 pid = /var/run/stunnel4/stunnel4.pid debug = debug output = /var/log/stunnel4/stunnel.log
I just changed this : sslVersion = TLSv1
options = NO_SSLv2 options = NO_SSLv3
On client side I did the same. Now it's working. I'll have to verify on other PC's.
Koenraad.
On 10/21/2014 03:40 PM, Koenraad Lelong wrote:
Op 21-10-14 om 09:35 schreef Koenraad Lelong:
Op 21-10-14 om 09:13 schreef Koenraad Lelong:
On client side I did the same. Now it's working. I'll have to verify on other PC's.
Koenraad.
From your description I conclude that you use stunnel to make tunnels between an stunnel server and stunnel clients. So if both ends agree on the SSL/TLS protocol it should do the job.
However, my question is:
Is it possible to configure an stunnel HTTPS client mode service in a way that stunnel changes the Host request field it receives in the HTTP headers to make it equal to the left hand side of the connect = statement?
I think I could get away without it until the time SSLv3 was disabled on the Apache web server (Poodle). It does not work without it using TSL1 or higher.
Read on for more details of my analysis.
In my setup, I use an stunnel server with the following configuration:
; The following options are set by default as from stunnel version 5.06 ; Disable support for insecure SSLv2 protocol ;options = NO_SSLv2 ; Disable support for insecure SSLv3 protocol ;options = NO_SSLv3
sslVersion = all
[ws-production] client = yes accept = 4433 cert = /etc/stunnel/clientcert.pem key = /etc/stunnel/clientcert.key connect = 10.10.10.10:443 TIMEOUTclose = 0
Stunnel runs on host stunnel-host and listens to port 4433 for an incoming connection, providing an SSL client mode service.
Clients are connecting to stunnel-host:4433 using HTTP and stunnel sets up the connection to an Apache web server, negotiating a secured TLS (HTTPS) connection and using the client certificate (clientcert.{pem,key}) for client authentication.
This way I can manage the client certs at a central place and the clients can simply connect using HTTP over the internal network (where no security is required).
So in my case the other end of the connection which is initiated by stunnel, is the Apache web server. Stunnel opens the socket to 10.10.10.10:443, but it forwards the HTTP request header as is.
In the HTTP request there is the info
Host: stunnel-host:4433
and Apache webserver notices that the socket is opened to 10.10.10.10:443, whereas the Host request field says stunnel-host:4433 and it logs the following in the error log:
[Tue Oct 21 20:01:11 2014] [error] Hostname 10.10.10.10 provided via SNI and hostname stunnel-host provided via HTTP are different
and it returns HTTP/1.1 400 Bad Request.
I can modify my config and add
sni = stunnel-host
to the config but the webserver does not like that either, since it does not like "Hostname stunnel-host provided via SNI and hostname stunnel-host provided via HTTP" either. Note that the configuration without sni = stunnel-host did work using protocol SSLv3.
So it looks like that from TLS1 and higher it is required that the Host request field matches with the CN (=10.10.10.10) from the server certificate, whereas with SSLv3 I could get away without it.
Setting up a connection using
curl -X POST -H 'Host: 10.10.10.10' -H 'Content-Type:text/xml' -d '<soapenv:Envelope ... </soapenv:Envelope>' http://stunnel-host:4433/webservice
does make it work. So, I think I now what the problem is. I understand that from my stunnel SSL client mode service configuration, stunnel cannot figure out that I want stunnel to change the Host request field in the HTTP request header received from the client.
Cheerz, Dion
On 10/21/2014 08:44 PM, Dion Kant wrote:
Is it possible to configure an stunnel HTTPS client mode service in a way that stunnel changes the Host request field it receives in the HTTP headers to make it equal to the left hand side of the connect = statement?
Ahumm, right hand side it is:
Is it possible to configure an stunnel HTTPS client mode service in a way that stunnel changes the Host request field it receives in the HTTP headers to make it equal to the right hand side of the connect = statement?
-
Dion Kant -
Koenraad Lelong