Regular SSL/TLS for user connections to the LTM, with SNI support from LTM to the real webservers?

Martin, can I assume that you're terminating client SSL and re-establishing to the servers? What version are you running?

That's an interesting question. So, in v11 at least, BIG-IP does support server side SNI. If you plug a server name into the server SSL profile's Server Name block, you'll actually see the SNI extension information in the CLIENTHELLO message coming from BIG-IP. That of course implies that you have a different server SSL profile for every back end SNI host and switch profiles in an iRule (see https://devcentral.f5.com/wiki/iRules.SSL__profile.ashx), but that's probably not too tedious.

Interestingly, and I'm frankly not sure why this worked, but I was also able to leave the Server Name field blank and set the HTTP host header in an iRule to get it to switch between SNI servers.

HTTP::header replace Host "sslapp1.alpha.com"

Again, completely counter-intuitive, and didn't see the SNI extension information in the CLIENTHELLO, but was definitely able to switch between the SNI hosts consistently. Anyone know why that works???

We're on LTM 11.2.x.

The above applies to v11+, so 11.2.x supports server side SNI.

 

Hi Kevin,

 

It sounds like you're saying there's no way to set the SNI information on the fly, as the server SSL profile's Server Name block is also not settable on the fly. I'm not sure I want to create hundreds of server SSL profiles for every possible virtual host I want to use. I think, using this stated configuration, I'm already going to be stuck creating tons of client SSL profiles for the SSL offloading from the browser to the F5. So this solution will effectively double the number of profiles.

 

Hmmm. I will bring this back to my team and discuss. If anyone has any other ideas about how to pull something like this off, please keep posting! :)

 

 

Thanks all,

 

 

Martin

 

 

Try the Host header replacement method I described without setting the Server Name field. Still looking into why this works though.

 

 

Have you considered wildcard or SAN certs for the client SSL profile(s)?

 

 

Also curious why you're doing SNI on the back end.

Okay, I figured it out. v11.1 introduces the SERVERSSL_CLIENTHELLO_SEND event and the SSL::extensions command. With these I can arbitrarily add extensions to the SSL negotiation. Here's a rough idea of what it looks like:

when HTTP_REQUEST {
    HTTP::header replace Host "sslapp2.alpha.com"
}
when SERVERSSL_CLIENTHELLO_SEND {
    set hostname "sslapp2.alpha.com"
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]
    SSL::extensions insert $bin
}

For this to work you absolutely have to set the HTTP Host header the same as the server name value you're inserting into the SNI extension. How you derive that server name in the first place is another issue (perhaps an LDAP lookup of the load balanced host or a static datagroup IP->hostname mapping?)

You'll also need to set Strict Resume in your server SSL profile for this to work.

Just to explain the binary portion:

[binary format S1S1S1S1ca* - binary formatting a string that contains 4x16bit values, 1x8bit value, and a text string

0 - static value indicating the extension type (server_name - see http://tools.ietf.org/html/rfc6066)

[expr [string length $hostname] + 5] - a (total) length indicator that is always 5 bytes longer than the text string length

[expr [string length $hostname] + 3] - a (list) length indicator that is always 3 bytes longer than the text string length

0 - static value indicating the server name type (host_name)

[string length $hostname] - the length of the server name text string

$hostname] - the server name text string

Hope this helps.

sorry i might be lost. i understand serverssl profile by default does not verify server's certificate. so, why do you need SNI on server-side connection? and what certificate/key are you going to put in clientssl profile??

 

 

The Trusted Certificate Authorities setting is optional. This setting is used to specify the CAs that the BIG-IP system trusts when verifying a server certificate. The default value is None, which means the BIG-IP system will accept a server certificate signed by any CA.sol11220: Overview of the Server SSL profile

 

http://support.f5.com/kb/en-us/solutions/public/11000/200/sol11220.html

SNI doesn't really have anything to do with certificate verification. It allows you to load multiple SSL sites onto a single IP address and port and is a modern alternative to SAN or wildcard certificates.

Posted By Kevin Stewart on 10/19/2012 12:21 PM

 

Try the Host header replacement method I described without setting the Server Name field. Still looking into why this works though.

 

 

Have you considered wildcard or SAN certs for the client SSL profile(s)?

 

 

Also curious why you're doing SNI on the back end.

 

 

Thanks for the suggestion. We're not considering SAN or wildcard certs as we host hundreds of websites (this isn't just for 3-4 sites). We like the idea of SNI on the backend in order to reduce the need for 1-ip-per-site on the backend. This way, we can do name based Apache virtual hosting with SSL without so many IPs (so our hundreds of sites still get the correct port and url scheme without us having to change anything).

 

 

Do you know of any other way mass-virtual hosting is being done with an F5 and SSL? It's prohibitive for us to ask all of our hosting customers to change code, and we'd love to stop putting 100+ IPs on each web server.