WirelessPhreak.com

 

So the F5 is a tricky beast often refereed to as the swiss army knife of network appliances. The appliances primary role in many networks is to load balance and is a beast negotiating SSL. That being said its not always easy to determine how to configure the clients SSL profiles to be secure and still service the public. F5s documentation is helpful but designed to be vague because cipher suites and browser support is always changing. https://support.f5.com/csp/article/K8802

 

SSL Labs has become the de-facto to use tool that helps the public understand the nuances of SSL by giving an easy to understand letter grade, https://www.ssllabs.com . The website runs a multitude of tests from insuring your certificate is chained correctly to end device OS and browser simulations, to commonly found vulnerability testing. The down fall of having such a sophisticated tool issuing a simple letter score, is not every environment can be configured for an A or B plus.

 

So I wanted to through an F5 Client SSL Profile out there that at the time of testing got a solid A- and still supported a ton of OS and browser combinations. You will mostly want to keep the defaults but I will highlight what changes you will want to make to get an A. You will need to select Advanced to see some of these settings.

• The first step is to add your public certificate and the intermediate certificates if applicable as well as the key.
•  this is what create the certificates chain

• Next you will want to customize the Ciphers that will be used by the F5 to negotiate SSL with the client. This is where 99% of the magic will happen.
• DEFAULT:HIGH: (are pre canned cipher settings created by F5, the additional settings are additional customization.
  
• !RSA: Do not use RSA ciphers
  
• !SSLV3: Do not use SSL version 3
  
• !RC4: Do not use RC4 ciphers
  
• !EXP: Do not use Cipher length of 40 or 56 bits export strength
• !DES: Do not use Des or triple Des ciphers
  
• !TLSv1_1: Do not use TLS version 1.1
  
• !TLSv1: Do not use TlS version 1.0
  
• !ADH: Do not use ADH ciphers
• !EXPORT: Do not use EXPORT grade (weak) ciphers
• !SHA: Do not use Message Authentication Code SHA 128
  

• The complete string looks like this:
• DEFAULT:HIGH:!RSA:!SSLV3:!RC4:!EXP:!DES:!TLSv1_1:!TLSv1:!ADH:!EXPORT:!SHA

• Lastly you will want to set up strict SSL renegotiation:
• Check the  Renegotiation box
• Next set Secure Renegotiation to "Require Strict"

 

From here save your SSL client profile, apply it to a public accessible virtual server, and run SSL labs against your server. Its kind of fun testing and playing around to see what modifying the cipher settings.

 

Enjoy. 

Captive portals have become synonymous with guest Wi-Fi in enterprise environments. From Starbucks to your doctor's office people expect free and easy to use Wi-Fi,  but what was once easy to do is getting more difficult. Browser security is always improving which has made the goal of HTTPS redirects even more difficult. Captive portal redirection for users going to HTTPS websites has always created SSL related errors -- this has helped create a cry wolf scenario when it comes to HTTPS redirection errors. This error rich environment has helped HSTS errors fly under the radar.

At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks, and cookie hijacking. Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security).  Along with the pre-configured list built into browsers, developers can take it upon themselves to enable this policy on their sites. Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL “Strict-Transport-Security: max-age=31536000”. The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and,  if the certificate does not match, the browser will not allow the connection to site to be established.

For a more in depth HSTS description check out Troy Hunt's post Understanding HSTS.

So how does HSTS break captive portals?  HSTS enforces the use of HTTPS. It enforces this using two methods that where mentioned earlier the HSTS header or STS preload lists in the browser. When a user connects to a captive portal and launches their browser, normally the wireless controller would intercept their Internet request and a redirect is sent back to the client. This redirect to the captive portal will obviously be a different CN than their original request so, many times, this creates an SSL error. Many users have become numb; accepting the error and continuing to the portal. But HSTS is a little different.