TLS Server Name Indication iRule

Holy "Moses" just awesome :)

Thanks, guys!

 

 

jquimby: Well, "binary scan" and its bitwise jump functions are pretty capable of replicating most of what pcap packet slicing can do; they just do it in a different syntax. For example a pcap "[13:2]" is pretty much equivalent to "binary scan [TCP::payload] @13S output". But I agree that it's not as easy to navigate for network folks who have had the pcap syntax firmly mashed into their brains through years of experience.

 

 

It'd be cool to have, say, a "TCP::payload match (pcap-style 'expr relop expr')" that would do the same thing as a binary scan but return just the bytes referenced -- that way you could take an existing pcap match rule and convert it.

 

 

I had to do this in CLIENT_DATA because it's pretty much the only place I can jump in before SSL/TLS negotiation. Really, though, I think it would be useful to create another iRules event: CLIENTSSL_HANDSHAKE_INIT. In the processing flow, this would happen after CLIENT_ACCEPTED and CLIENT_DATA, but just prior to CLIENTSSL_HANDSHAKE. It would essentially fire after the first ClientHello is collected but before it begins the handshake process. This would be a good place to grab and process TLS extensions, read the requested Cipherlist, and set variables to affect later script operation.

 

 

Some new commands would be needed: something like "SSL::extension" (giving access to TLS extension package data -- SNI included), "SSL::handshake cipherlist", and "SSL::handshake compressionlist". In addition to giving access to the ServerName extension early, this could also allow you to select the "strongest" ClientSSL profile _manually_ based on what the client's proposed cipherlist. Other extensions would be useful to obtain early on: max_fragment_length, trusted_ca_keys, and ocsp_status_request.

 

 

There are always ways to make things easier for the administrator, but to F5's credit, I've run into very little that I can't accomplish using an iRule or two... Kudos, guys!

Piling on here: Wicked cool stuff. Keep up the good work.

 

 

Colin

Posted By Joel Moses on 03/30/2011 03:37 PM

 

Thanks, guys!

 

 

jquimby: Well, "binary scan" and its bitwise jump functions are pretty capable of replicating most of what pcap packet slicing can do; they just do it in a different syntax. For example a pcap "[13:2]" is pretty much equivalent to "binary scan [TCP::payload] @13S output". But I agree that it's not as easy to navigate for network folks who have had the pcap syntax firmly mashed into their brains through years of experience.

 

 

It'd be cool to have, say, a "TCP::payload match (pcap-style 'expr relop expr')" that would do the same thing as a binary scan but return just the bytes referenced -- that way you could take an existing pcap match rule and convert it.

 

 

I had to do this in CLIENT_DATA because it's pretty much the only place I can jump in before SSL/TLS negotiation. Really, though, I think it would be useful to create another iRules event: CLIENTSSL_HANDSHAKE_INIT. In the processing flow, this would happen after CLIENT_ACCEPTED and CLIENT_DATA, but just prior to CLIENTSSL_HANDSHAKE. It would essentially fire after the first ClientHello is collected but before it begins the handshake process. This would be a good place to grab and process TLS extensions, read the requested Cipherlist, and set variables to affect later script operation.

 

 

Some new commands would be needed: something like "SSL::extension" (giving access to TLS extension package data -- SNI included), "SSL::handshake cipherlist", and "SSL::handshake compressionlist". In addition to giving access to the ServerName extension early, this could also allow you to select the "strongest" ClientSSL profile _manually_ based on what the client's proposed cipherlist. Other extensions would be useful to obtain early on: max_fragment_length, trusted_ca_keys, and ocsp_status_request.

 

 

There are always ways to make things easier for the administrator, but to F5's credit, I've run into very little that I can't accomplish using an iRule or two... Kudos, guys! Some of your ideas here are already under consideration in development. The pcap idea is a good one, and has a couple of developers asking questions. Nice work.

 

 

That's great! Let me know if you guys need a sounding board for this.

 

 

It occurred to me in the Advanced Design forum where I saw someone asking about a layer 2 forwarding virtual server and SSL offload -- a CLIENT_HANDSHAKE_INIT event would be an interesting place to switch clientSSL profiles _and_ pool assignments on the fly based on either SNI _or_ the destination IP address; letting you switch the SSL cert _and pool_ presented based on either item. That could be useful when inserting ASM in the route path in front of an _existing_ secure web server network.

We'll definitely let you know if any specific questions bubble up. We try and ping the community whenever we can to get opinions on that kind of stuff when we get the chance.

 

 

Thanks again for the input/work so far.

 

 

Colin

I realise that this is 4 months down the track but would an RFE on SNI/SSL profile selection go astray? This will become very common in the future.

 

 

FYI: The original article in the first post seems to have gone astray.

 

 

Kevin (Jarvil)

 

Hi Kevin,

 

 

I think we have an existing RFE for native TLS SNI support. I don't have it handy, but Support could find it for you. Another case would always be good.

 

 

If you get the RFE ID could you reply back here?

 

 

Thanks, Aaron

I have a server with 1024-bit certificate and i need to migrate to 2048 bit certificate. Can i use the TLS SNI feature in version 11.2 to help in this migration?

 

 

I am wondering if I put my 2048 bit certificate (with TLS SNI ) as the first SSL profile in my VS, and have the 1024-bit in the failback ssl profile.

 

 

Can I use the same DNS name for both certificates?

 

 

Even if it works, I am worried that some of the clients may not like the extra SSL SNI negotiation going on the LTM. Has anyone come across failures where some clients could not connect, especially that I am using some dumb terminals as clients ?

 

 

thanks

The TLS Server Name extension allows the client to specify the server name in the CLIENTHELLO message, so SNI wouldn't work for you if both server certs had the same name. If both server certs are signed by the same issuer, or rather if both certs are signed by CAs that the clients explicitly trust, then you shouldn't have to do anything other than just replace the server cert.