SSL client profile based on hostname

Well, you have a bit of a "Which came first, the chicken or the egg?" problem here.

 

 

How can you unencrypt the data to see the hostname if you don't have the right certificate to begin with.

 

 

Anotherwards, you can't change the client profile after the client SSL session has started.

 

There actually is a way though, but it involves thinking a little unconventionally.

 

 

If you allow someone to hit an HTTP page first (on an unencrypted or known-SSL channel prior to redirecting them), and set up a session entry for them based on their source IP address in an iRule, you could retrieve this session entry later at the beginning of an SSL session and use the SSL::profile command to choose the ssl profile you're going to use.

 

 

Note that it's far from foolproof, and may not work for megaproxies and NATs, but it does sorta work.

thanks for the help. I figured as much.

Has anyone tackled this and made it work? If anyone has a sample configuration that would be great.

This really isn't an issue with iRules or the BIG-IP. This is a protocol issue. There really is no "good" way to make this work, as you have to decrypt the traffic to have the HTTP data available, and by that time you can't choose which SSL profile to use, unless you re-encrypt.

 

 

Colin

 

RE: SSL client profile based on hostname by hamish@ba.com

 

 

Posted By Colin on 05/30/2008 4:44 PM

 

 

This really isn't an issue with iRules or the BIG-IP. This is a protocol issue. There really is no "good" way to make this work, as you have to decrypt the traffic to have the HTTP data available, and by that time you can't choose which SSL profile to use, unless you re-encrypt.

 

 

Colin

 

 

RFC4366 allows this (TLS Extensions) with the Server Name Indication. Apache 2.x does it, so until F5 supports it, you could offload to separate apache instances instead (But you lose the HW assist of the F5 though).

 

 

Hopefully the hw on the F5's is flexible enough to allow the extensions... (It requires a new extended client & server hello message during negotiation)

 

 

H

 

 

 

 

Very interesting... this shows a lot of promise. I couldn't find too much detail on browser support for the TLS extension though. There is a PDF presentation (Click here) which indicates that the only IE version which supports the extension is IE7 on Vista or later. Of course most recent open source browsers seem to support it.

 

 

I'm guessing it won't be a practical solution until there is better IE support. That said, it would still be nice to get F5 to support this. Do you know if there is already a CR noting the request? If so, can you provide it so others can attach cases to it?

 

 

Thanks,

 

Aaron

The RFE CR to support the "server_name" extension from RFC3546 and RFC4366 is 94903. I would echo your request to have customers contact support in this matter.

 

 

So with all of that said would a wild card cert be a possible solution?

If you can get a single cert which is valid for all hostnames that resolve to the VIP address, then yes, you can decrypt all requests. This could be a wildcard cert or a cert which uses Subject Alternate Names (SANs).

 

 

Aaron

any perference from an LTM standpoint?