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