[stunnel-users] Trouble after disabling SSLv3 (another one)

[Dion Kant]

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