Forum Discussion
Matt_Breedlove_
Nimbostratus
NimbostratusHow to terminate and pass through SSL via HTTP:Host on single VS
Have a single VS that is currently listening on 443 and passing ssl through to the servers on 443 using domain name 'a' on the ssl cert. The ssl cert lives on the internal servers for domain name 'a', server does the decryption. I would like to setup a new ssl cert on domain name 'b' as a client cert on the same VS. If any requests come into the VS using HTTP:Host equal to domain name 'b' then the VS should terminate SSL and pass the connection unencrypted into the internal server on port 80. However, if not (the HTTP:Host equals domain name 'a', or is not readable because it is encrypted with a different cert) then just pass the connection through to the internal server on port 443.
This is to facilitate a parallel migration to ssl terminated connection, while keeping both working at same time on same server and VS. The reason we cannot just use a new VS is because we are stuck with the IP and port 443 on the VS due to firewall restrictions with the partner who is using this.
I have read the post about people wanting to use a single VS to head multiple SSL sites, but this is a little different as either the connection is decryptable with the bigip clientssl cert or its not. If its not, instead of hard failing, catch the exception and continue the connection and assume the server can decrypt it and pass through.
Appreciate any clever ideas/solutions
hoolioCirrostratus
Hi Matt,
In current implementations of SSL/TLS, you can't see the requested host unless you decrypt the traffic. So what you're trying to implement isn't really possible. You could decrypt all of the traffic and then re-encrypt specific traffic. If that sounds like a possible solution for your scenario, let us know and we can provide some examples on how to do it.
Aaron
Matt_Breedlove_Hi Aaron,
Would it be possible to have the VS always initially attempt to decrypt with the VS's client ssl cert and if it cant, through an irule event catch/trap, then stop trying and pass/node/pool the connection still encrypted to the member on port 443 for server based SSL handling?
This would not require that the requested host be seeable, but rather a binary process of elimination.
Does that make sense? Not sure if I made that clear in the last post as it is really what sets this apart.- hoolioHi Matt,
I think having a more detailed understanding of the SSL handshake process would help you see why this isn't possible. Here is a page from IBM that describes in text and a nice diagram the SSL handshake process:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzas.doc/sy10660_.htm
The server sends its cert in the server hello message. The client's user agent checks the subject of the cert against the hostname that the user made a request to. If they don't match, the user agent typically generates a warning to the user stating that the cert cert doesn't match (or isn't correctly recognized for chaining issues) before the SSL handshake is complete. If the user doesn't opt to proceed, the user agent closes the connection. Only after the SSL handshake is complete does the client send the HTTP headers which tell the server what HTTP host the client has requested.
So there isn't a way for the server to attempt decryption, check if it fails and force the client to retry. If you need to decrypt only selective traffic by host name, you could change the DNS records so that each hostname you want to pass through encrypted points to a different IP address than the hostname(s) you want to decrypt the traffic for. Or you could decrypt all of the traffic and re-encrypt the traffic that requires serverside SSL.
Aaron