WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me
Showing posts with label SSL. Show all posts
Showing posts with label SSL. Show all posts

 

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. 

     

Mutual authentication or two-way authentication refers to two parties authenticating each other at the same time. Below is an excerpt from the Wikipedia page, they did a nice job explaining what mutual authentication is.

By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer (for example, username and passwords.) TLS also offers client-to-server authentication using client-side X.509 authentication. As it requires provisioning of the certificates to the clients and involves less user-friendly experience, it's rarely used in end-user applications. But at a small scale or proof of concept this is completely reasonable.

Mutual TLS authentication (mTLS) is much more widespread in business-to-business (B2B) applications, where a limited number of programmatic and homogeneous clients are connecting to specific web services, the operational burden is limited, and security requirements are usually much higher as compared to consumer environments. The factor that impacts scaling of this design is not the technology, devices are built to handle millions of SSL transactions, but the policy and procedures around the certificate management and client on-boarding. 

In this example a client will be connecting to an Apache web server and authenticate using mutual TLS authentication.

First you must build the web server running SSL. You can find a lot of step by step articles online about how to build an Apache web server preferably on Linux. Also take a look at Lets Encrypt, it's a free SSL certificate issuer that is freaking awesome.

Once you have your web server up and running you will want your client to generate a certificate. This can be done using OpenSSL the de facto for everything SSL on the internet. There are some awesome guides on how to build out the mutual SSL authentication and the accompanying Apache config. The best one I found was on stefanocapitanio.com they do a great job of outlining each step that makes up the mutual TLS authentication. In this example I will Jump ahead to the certificate creation,

This will generate your private key and certificate. You will need to answer the following questions when prompted this makes up the attributes of your client certificate.
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem
Here is an example what it will look like.
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:US
State or Province Name (full name) []:State 
Locality Name (eg, city) []:City
Organization Name (eg, company) []:Anything
Organizational Unit Name (eg, section) []:Anything
Common Name (eg, fully qualified host name) []:Username
Email Address []:youremail

Next we will combine the Key and Certificate in PKCS#12 file:
openssl pkcs12 -inkey client-key.pem -in client-certificate.pem -export -out bundle-certificate.p12
This file will be the private key and certificate combined with a secure password. This is what you will install on your OS or browser (such as firefox) to encrypt your data and issue to the server as your identity.

Once you have generated and installed your client certificate you will want to send ONLY THE PUBLIC CERTIFICATE, in this case client-certificate.pem to the server admin. Your public certificate will be what is used to identify your machine when it attempts to connect tot he web server. Read up on the Apache man pages about he SSLVerifyClient options there is quit a but out there. This is a very basic config.

The server admin will place your certificate in their certificate store and configure Apache.
<VirtualHost *:443>
  ServerName secure.example.com
  DocumentRoot "/var/www/html"
  ServerAdmin [email protected]
  SSLEngine on
  SSLCertificateFile /home/sempla1/ssl/server-cert.pem
  SSLCertificateKeyFile /home/sempla1/ssl/private/server-key.pem

  SSLVerifyClient require
  SSLVerifyDepth 10
  SSLCACertificateFile /home/sempla1/ssl/client-certificate.pem
</VirtualHost>

Once the server has been configured you can attempt to connect. Normally you will be prompted to provide your client certificate if it is working. This is apache asking for your public certificate to validate it is the same one that Apache was configured with. In firefox you can go into Preferences then Security and Privacy and tell the browser to automatically issue that certificate if you like.

That's it I had a good time playing with this I hope you do as well.



Most of the people who have found this post on the internet are already familiar with Palo Alto Firewalls and everything they can do. One of the features I really like is the IPS functionality built into the firewall, but - and its a BIG BUT - if you're terminating SSL after the traffic ingresses your untrusted security zone you're loosing a lot of the PAN's IPS functionality because the traffic is encrypted.

Here is a reference diagram of what I am talking about:

So how do we fix it? PAN has a feature called SSL Inbound Inspection. This feature as of 7.1.x code does not terminate the SSL session or work as a proxy, but at a high-level takes a copy of the traffic and uses your imported certificate and key to inspect the traffic against the policies that have been configured. It's really easy to setup, but there are a couple caveats that I wanted to outline in this post.

SSL and Supported Ciphers: As many of you know the SSL negotiation is determined between the client and the server during the SSL handshake.  Because the firewall does not work as a SSL proxy, or "man in the middle", you have to insure that the client and server negotiate a cipher that the firewall is able to decrypt. This is where we ran into a little confusion.  Much of the documentation on the PAN site is focused around outbound SSL decryption.  This gets confusing when PAN doesn't document what feature they are discussing in an article. For example they have an article of supported decryption ciphers and they did not specify on the document if these were the ciphers used in outbound decryption or inbound inspection.  Then, when I asked for documentation of supported inbound SSL inspection ciphers, they could not point me to a document. FYI if you look at an SSL decryption profile there is a disclaimer in small print that only the listed RSA ciphers are supported for inbound inspection. I was told this was going to fixed.


So to help you out here is what is supported for inbound SSL inspection:

To ensure your firewall can decrypt all inbound SSL traffic it is important you configure your servers or load balancers to only offer ciphers supported by your firewall. If you're using an F5 to terminate SSL here is the string you can define in the cipher list within your SSL client profile.

!DES:!3DES:!SSLv3:!RC4:!EXP:RSA

APP-ID and Application Default Services: Many of you out here have enabled APP-ID on your firewalls and probably leveraged the application default service setting to let the firewall determine the port to allow traffic on.  I have been told application default setting in the services section of a security policy is best practice and, to be honest, I actually like it and use it; but it can break SSL Inbound Inspection. To understand where it breaks we first need to understand how a firewall processes a packet when you have enabled inbound SSL Inspection:

  1. The firewall looks to see if the packet is allowed by the security policy.
  2. The firewall identifies the traffic as SSL
  3. The firewall looks to see if the destination is configured with a SSL decryption policy
  4. If the destination address matches a protected IP address, it is decrypted and processed through the security policies once again as web-browsing still on port 443. 
  5. Bang! Connection is broken.

When you have application default set it is expecting specific ports based on the application that has been identified by APP-ID.  So if you have SSL and web-browsing configured in the APP-ID portion and application default configured in the services portion of your security policy...once the firewall decrypts the packets and runs it back through the security polices as web-browsing traffic on port 443 the firewall drops or resets the connection.

To resolve this issue you can still use APP-ID but you will need to explicitly list the ports the firewall will allow traffic on. This will allow any application, in this case web-browsing traffic on TCP port 443, to be allowed on any of the listed ports.

Configure SSL Inbound Inspection: You can click here to go to the Palo Alto Networks website and they will walk you though the SSL Inbound Inspection configuration.








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.


Because HSTS already knows the website should be using HTTPS the browser issues an internal HTTP 307 redirect redirecting the traffic to HTTPS even before it attempts to connect to the server. Once it connects to the server it attempts to validate the HSTS valid certificate. In the case of a redirection the captive portal would not be insuring the same HTTPS HSTS validated certificates. When this happens the browser will assume something nefarious is going on and not allow the redirection to occur. I know one vendor has a bug report filed for this issue - even though its not really a bug - and I don't know if its a fix the wireless vendors can provide.

Bottom line for users connected to a captive portal today:
  • If the user visits an HTTP site, they are immediately redirected to the captive portal. This works regardless of what browser they are using
  • If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click "Continue" they are redirected to the captive portal. This works regardless of browser
  • If the user visits an HTTPS site that does use HSTS and they are using the browser that supports HSTS they are dead-ended. The only way to get redirected to the captive portal is to visit a different site. Many people have https://www.google.com or Facebook set as their homepage. Both of these sites use HSTS so this might confuse some users.

This issue of not being redirected to a captive portal affects every wireless vendor. As more and more sites use HSTS, getting a proper redirect becomes harder. Hopefully the wireless vendors are sitting on the working group for this new standard and are pushing hard to get it ratified. 

In the long run, if something is not done, enterprises will quit using captive portals if it becomes really tough to get a proper redirect. But for now, being forced to use captive portals, I have not seen a sure fire technical way of getting around the issue.  But you can get around the HSTS errors through communication and policy. 

For example:
I am considering turning off HTTPS redirection all together. What this does is create a predictable environment for the users and the system admins. By not redirecting HTTPS you take the confusion of redirection issues based on SSL certificates, HSTS, or any new security the browsers builds in and level the playing field. Then in the case of using a sponsored portal, the email notification that is sent to visitor and/or person being visited can include the verbiage, "If you are not redirected to the guest portal please type a non secured HTTP website into your browser".  




Since Google's announcement that SSL affects your page ranking encrypting your blog has become even more important. This post goes through the steps for securing your google blog using SSL and CloudFlare, These steps can be applied to other sites and services, but I use Google's Blogger platform because its easy,  That being said the Blogger platform does limit your ability to perform lower level modification like securing your site using SSL and I will go over a few issues I ran into.

After playing around with CloudFlare for a couple weeks it's obvious their primary focus is caching and DDOS prevention, but they offer much more. CloudFlare's free offering is very robust and gives you a lot to experiment with. I used it to front my entire blog since my requirements were very minimal.

So what you need to get started:
  • Your own domain
  • Set up your blogger page to use the custom domain. They have really good directions that walk you through the process.
  • Create a free CloudFlare account.
  • Import your DNS
  • Login into your DNS hosting company and change the DNS servers to the servers CloudFlare has identified
  • Then wait up to 24hr mine was pretty instantaneous since the TTLs were set pretty low.
  • Your site is now on CloudFlare  
Now for the fun tweaks: 

  Felixiable SSL was on by default.  This is the setting you will need for your Blogger or Wordpress sites since those services do not allow you to implement your own SSL. Basically CloudFlare sets up SSL offload using a SAN certificate that includes your domain. Once CloudFlare decrypts the traffic it is sent to your site non encrypted.  This is an awesome service but it did cause me some issues, and at least with blogger it will pose some ongoing issues.

  • The first issue I experienced was intermittent interruption with the CloudFlare SSL service. I opened a ticket with them and they identified the template I was using was calling insecure pages.  There systems identified this and would temporarily disable Flexible SSL.  They pointed out the offending files and I was able to modify the template I was using to fix the issue.  The CloudFlare tech also pointed me to a useful article outlining how to enable SSL for a Wordpress site, here is the article https://support.cloudflare.com/hc/requests/558717. 
  •  The second issue is related to the first but was not actually causing any service interruptions. As you have probably seen the lock for my site is not green or has an "!" next to it.  This is because the images that where originally used in my blog were absolute http links.  This forces the browser who knows it has a secure connection to my website, to display non secure content, images that are not hosted on Google and are not SSL. This causes the mixed content error in the browser. I will be working on cleaning this up moving forward. 

 Page Rules was one of the more exciting and powerful surprises offered by CloudFlare. They allow 3 page rules with your free account.  I work with load balancers everyday and this single page of rules really ads flexibility that companies pay a lot of money for. So for my SSL rule I wanted my page to always be redirected to SSL so I created one page rule "http://*.wirelessphreak.com/* HTTPS always redirect" that forces all traffic to my site over SSL. It worked great and was super easy to set up.

The last pleasant surprise was the analytics. I have google analytics and it has become the defacto standard on the internet.  But what CloudFlare bring in addition to google analytics is their breakdown of not only unique visitors but the ratio of cached content and served content. It also does a nice job of showing you what percentage of your traffic served was encrypted and not encrypted.

All and All it seems to be a cool service. I and I look forward to playing with it some more.





If online security is complicated, then online privacy is imposible. The public is slowly learning the difference between these two topics. Unfortunate situations such as the infamous fappening has brought both of these topics to the attention of the cyber muggles.

Online security can be reduced to 1s and 0s algorithms and ciphers, there is a finite outcome when you are looking at crypto.  Math dose not lie, and we have the ability to create a secure cyber world.  Where security breaks down is the implementation.  Complicated software (open and proprietary), lack of proper vetting, and some times just laziness are a  few of the causes.

Online privacy on the other hand is much darker and deeper then anyone wants to admit.  From the government to politicians to the telco companies to advertisers, your privacy is a commodity that is sold, stolen, and bartered for.  Free google email is a perfect example.  If you sign up for email (which I have) you should understand that your email will probably be secure, but you are giving up privacy through google targeted marketing bots that crawl every email you get.

But there are groups looking out for the publics interests even if they didn't now they needed it.

  • The Electronic Frontier Foundation (EFF) is an international non-profit digital rights group based in the United States.
  • The American Civil Liberties Union (ACLU) is a nonpartisan non-profit organization whose stated mission is "to defend and preserve the individual rights and liberties guaranteed to every person in this country by the Constitution and laws of the United States."
Below I have listed some links to privacy and security audits that have been performed for many of the services we use today.  I though they where interesting and wanted to gather what I could find in one place.

Well they have used up all the awesome vulnerability names, hence the POODLE Attack (Padding Oracle In Downgraded Legacy Encryption). Twitter security chatter has increased around the POODLE Attack and there has been a CVE number assigned CVE20143566.  

Links to both the google paper and the CVE.
High Level Explanation:
The quick and dirty is even if a client and server both support a version of TLS, the security level offered by SSL 3.0 is still relevant since many clients implement a protocol downgrade dance to work around server side interoperability bugs. In the google security advisory, they discuss how attackers can exploit the downgrade dance and break the cryptographic security of SSL 3.0.

The only real work around is to disable SSL 3.0 but for many web admins supporting legacy clients, Window XP running i.e.6 for example, disabling SSL 3.0 is not an option. 

If you end up enabling SSL3.0 you can enable TLS_FALLBACK_SCSV. This forces a more controlled negations of ssl between the client and the server limiting the possibility of clients and servers skipping protocols during the SSL negotion.

I will add more specifics to the F5 and how you would enable the TLS_Fallback command, as well as how to order your SSL protocol and cypher strengths.

 ***UPDATE***
According to F5 they do not currently support the TLS_FALLBACK_SCSV cipher. There is talk about an engineering hot fix that may include support but there is no solid ETA.  F5 is recommending you disable SSL 3.0 where you can.
OpenSSL command to test if a webserver supports SSL3.0:

 
openssl s_client -connect target:443 -ssl3
If the command makes you enter more information, then you just made an SSLv3 connection. If the command returns you to a prompt right away, then SSLv3 is disabled on that target host.
*Update* Cisco has posted their Security Advisory for the Heartbeat vulnerability http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

It is curious to see how different company choose to incorporate and document opensource software in their products. But that is a different rant for a different time.

Today is the day engineers around the world hit the internet looking through pages and pages of documentation.  I have done some research and wanted to add what I found to hopefully shorten someones search.

Cisco ASA 8.4 code is running openssl 0.9.8f Safe
F5 LTM 11.3, and 11.4 are running openssl 0.9.8y Safe
  • To view for your self SSH to your LTM log in as root and run "openssl version"
F5 LTM 11.5 is running openssl 1.0.1e-fips Vulnerable

Here are some more links about the Vulnerability