Archive for the ‘VPN’ category

AES is becoming very close to broken

July 30th, 2009

In earlier posts I discussed what’s wrong with WPA and why its always a bad idea to base a standard around a single method of encryption, even AES. Bruce Schneier posted to his blog today regarding a new attack against AES. In short, the paper he references identifies how to dramatically reduce the number of guesses required to retrieve a key. While its not practical today for a basement hack to perform the attack, its still nasty stuff.

The attack in question is what is referred to as a related key attack. This requires the attacker to have some level of knowledge of the plain text secured by multiple related keys. In other words, we need to already know a bit of what is being protected and where to look for it.

This is a serious problem when you are talking about VPNs or wireless, because we are using it to secure IP traffic. IP uses some pretty consistent values:

  • Byte 0 contains the IP version (usually 4) and the size of the IP header (usually 20 bytes)
  • Byte 1 contains the type of service field (usually not used so set to 0)
  • Bytes 2 & 3 contain the total length field (a consistent value for traffic like ARP packets if you know the OS)
  • Byte 8 contains the TTL (a consistent value on a per OS basis)
  • Bytes 12-15 contain the source IP address (a consistent value for each specific system)

And that’s just the IP header…

So when we protect traffic on the wire, related key attacks can be particularly evil because there are many repetitive values to work with.

So what should you do? I’ll fall back on the same advice I gave in those earlier posts I referenced above. Make sure you have more options than just a single encryption algorithm, just in case things get a whole lot worse.

No comments »

Posted in 1-emerg, VPN, Wireless

Tags:

Eliminating The Need For WPA In The Enterprise – Part 2

July 22nd, 2009

In my last post I discussed the problems with deploying WPA in an enterprise environment. Let’s back up a bit and list why we secure wireless networks:

  • Permitting uncontrolled access can lead to compromise
  • Authentication is required to verify the person connecting in
  • Data can be sniffed so encryption is needed for data privacy

Pretty straight forward reasoning, but now stop and consider why we secure remote users when they connect in from the Internet:

  • Permitting uncontrolled access can lead to compromise
  • Authentication is required to verify the person connecting in
  • Data can be sniffed so encryption is needed for data privacy

Note the reasons are the same. I’m big on root cause analysis, and the reason so many of us jump though hoops with WPA is that we’re trying to fit a square peg into a round hole. In other words, rather than recognize that a wireless signal is a separate uncontrolled entity, we try really hard to slap on a quick fix so it can be trusted at the same level as the wired segments secured behind our office walls. Not a surprise really, given that the first protocol we were given to secure wireless was called the Wired Equivalent Privacy (WEP) protocol. Needless to say the name directly implies that wireless can be made to be as secure as a wired switch port. History has shown, and continues to show otherwise however.

Consider the network drawing in Figure #1. Note that we have reconfigured the network to better address the root cause problems with wireless. Wireless is no longer considered as trustworthy as a wired switch port. Its treated in a similar fashion to its closest matching security zone, the Internet. We simply hang our access points off of another firewall port and apply a similar security posture.

wireless-vpn

So when someone connects to the access point, what happens? The connection is made in the clear with no security enabled. Simply connect to the proper SSID and go. The local DHCP server then hands the system an IP address. At this point our setup acts like any other non-secured network.

Look what a wireless system gets access to however. Through the firewall, the only permitted point of access is the VPN gateway. This is the same as when the user connects in from the Internet. So rather than having to trust a single security implementation (WPA) with its single choice for data privacy (AES), you can deploy what ever you feel is appropriate. The robustness and flexibility of SSH, SSL and IPSec all become possibilities for securing your datastream. While each solution supports AES for data privacy, they open up a plethora of other, some feel better, options like Blowfish and Twofish.

But wait, couldn’t an attacker connect to my access point and go after the laptops that are connecting in? Absolutely. Again, this zone has the same security level as the Internet so the same rules apply. Think about your typical wireless user however. They tend to be road warriors, who also connect in from the Internet. This means their system should already have the required VPN software and a personal firewall system. So if the laptop is configured to connect in from the Internet, its ready to go in this wireless configuration as well.

One of the things I really like about this configuration is that it not only reduces back end administration (no more WPA management), but help desk support time as well. Users just want their laptop to work and are more effective when they can follow a consistent process. When we tell them “Perform steps A, then B, then C to connect in from the Internet, but steps D, then E then F if you are at the office”, some will inevitability become confused. With the setup above they always follow the same connection process, regardless of physical location.

Since no security solution is ever perfect, there has to be some down sides, right? First, we are putting a slightly higher load on the firewall. Internal communications between a wireless system and a server would normally not involve the firewall, but now it does. This problem could easily be resolved with a second firewall however.

The second issue is security related but is dependent on how we deploy the above configuration. In an ideal world all access points would be connected to a single isolated switch. Reality in a large environment however might necessitate the use of VLANs because the access points are geographically dispersed from each other. The use of VLANs opens up the possibility of VLAN hopping. While this author does not think an attacker could mess with DTP through an access point in order to gain access to the trunk, its certainly possible from a directly connected system so eventually someone smarter than I may figure it out. In short, remember that this security zone has the same trust level as the Internet and handle it accordingly. Shut off DTP or any other auto VLAN negotiation capability the vendor has turned on by default.

Finally, rogue access points are still an issue. This solution does nothing to stop an end user from bringing in an access point from home and plugging it in. You still need to keep a watchful eye for this activity. About the only thing this solution does for you is now you know any access point plugged into the wired network is rogue and needs to be addressed.

Hope this is helpful!

C

2 comments »

Posted in 3-err, VPN, Wireless

Tags:

Eliminating The Need For WPA In The Enterprise – Part 1

July 21st, 2009

Many of us who leverage wireless in an enterprise environment dutifully deploy wireless encryption (WEP or WPA) as well. This is not trivial, as it requires a continual commitment of time and resources in order to maintain the system’s integrity. But is this expenditure really necessary, or is there a more effective solution available that most of us simply overlook?

The need to properly secure wireless

Most of us recognize why wireless connections need to be properly secured. Running a wide open access point is just begging to have your network broken into. Wireless is trivial to sniff and there are a tons of tools available to help you crack it. A good wireless hack knows that proximity affords little protection. I’ve personally been able to get 802.11 working over 5 miles. With the right antennas, others have pushed this as far as 35 miles.

What’s wrong with WEP and WPA?

Most of us understand why WEP is completely broken. If not, Google is your friend. If you don’t understand why WEP is bad its worth the time to do the research. Its a great example of how to do everything wrong.

So the accepted protocol today for wireless security is WPA. At the time of this writing, WPA is faltering but not completely broken. Researches have figured out how to perform key recovery in small packets. Vendors have figured out how to speed up the process of brute forcing keys. The recommended WPA key size today is 48 characters or larger. This is far too big for end users to remember so inevitably the value is written down, in clear text, probably in multiple locations.

There are resource issues here as well. Wireless security is an entire infrastructure system that needs to be managed. Keys and credentials need to be maintained. Even if we take the easy way out and deploy EAP-TTLS we still have a healthy number of components to keep in sync. When things go wrong, troubleshooting can also be a pain as it can sometimes be difficult to determine if the problem is the wireless signal, credentials or even DHCP.

Limiting your data privacy options

When you use WPA, your only data privacy option is AES. AES is a NIST standard that is widely deployed. While it has survived the last eight years without a major vulnerability, timing attacks have been discovered along with a few dents in AES’s armor. Its never a good idea to put all of your eggs in one basket. This is why we backup mission critical data or transmit it over redundant routes. If the worst occurs and AES is found to be broken, you are completely hosed until a new protocol is chosen and incorporated by vendors. The solution will most certainly include replacing all of your access points, as it did when we moved with RC4 under WEP to AES under WPA.

Exec Summary

So we absolutely need to secure wireless connections but the current options available are either slightly better than useless (WEP) or very cumbersome (WPA). Clearly we need additional possibilities that will reduce administration as well as increase the number of choices for data privacy. In my next post I will propose one possibility that is immediately viable for deployment in today’s enterprise environment.

No comments »

Posted in 3-err, VPN, Wireless

Tags:

What does the little lock icon mean in my browser? – Part 3

July 17th, 2009

In the first two parts of this post, I described what goes on when creating an HTTPS connection to a Web server. In this third and final part I’ll get into what can go wrong.

What can go wrong if I trust the rabbit hole?

For the sake of argument let’s assume we “feel” the HTTPS process is trustworthy all the way down to the bottom of the rabbit hole. Our first problem is we never actually go there. Check out Figure #1. This shows some of the configurable options for Internet Explorer 8. Note the two circled lines.

ie-cert-options

The first one, “Check for Publisher’s certificate revocation” attempts to validate the locally stored digital certificate. Its on by default, but all its really doing is checking to see if the trusted third party has identified their signing server as being compromised. If they have not figured it out yet, or if an attacker is able to compromise this session, all bets are off. In other words, in part 2 I described a path all the way down the rabbit hole to a self signed digital certificate. What this option is tells us is that we are never going to check down that far. We’ll do a quick check one level deep and stop there.

Now, look at the second line which is circled, “Check for server certificate revocation”. Note this option is turned off by default. So while you could be checking to see if the Web server your talking to had it’s digital certificate revoked, you don’t bother because of an options setting. The concept is “Hey you can trust Verisign because they never mess up”. In part 2 we also discussed how this is not always the case.

Does SSL and TLS always encrypt my data?

As mentioned in part 1 of this post, SSL and TLS are a framework. They pull together a lot of possibilities for securing your data but leave the particulars to the negotiation between the client and the server. Consider the picture shown in Figure #2. These are the SSL and TLS options for a Firefox Web browser. Note the lines within the red box.

Firefox let's you select which privacy options to support

Firefox let's you select which privacy options to support

The first option says “Use RSA for initial authentication and HMAC-MD5 to authenticate each packet”. The second option says the same thing, but to use HMAC-SHA for packet level authentication. Notice anything missing? Like… how should we be encrypting the data? Both of these options specify authentication without any kind of encryption.

Why is this even a possibility? Because sometimes its enough to know your datastream can not be changed in transit. You might not be worried about people seeing the data or it may be possible that you are located in a country which does not let you encrypt your information. If either is the case, SSL and TLS can still help you out.

Now, remember back to part 1 of this post I said that in an SSL/TLS handshake we go with the highest level of data privacy supported by both ends of the connection. With this in mind, you hopefully will never see “no encryption” negotiated in the wild. If however this is all the remote server wants to support we may be in trouble. Luckily Firefox has both of these options disabled by default. But what about other browsers? That’s the kicker. Most browsers will let you select the version of SSL and/or TLS you want to support. They will not let you drill down to specific protocols. So this could be on and you would never even know it.

And now back to that little lock icon

I have a love/hate relationship with the little lock icon. I like the idea of making it simple for users to figure out when their data is being secured. I hate the idea that the accepted implementation is a little graphic that it very easy to duplicate. For example, have a look at Figure #3. Note the bank has placed a copy of the lock icon right on the logon page. Does this really tell us the data is being secured? Absolutely not! It could just as easily be a picture of a cute kitty cat. In this context the lock icon is nothing more than a display graphic.

Note the lock icon within the HTML page

Note the lock icon within the HTML page

OK, so let’s look around our browser window a bit. In older browsers I got used to seeing the lock icon at the bottom right of the screen. Hey look at figure 3 again, there’s a lock icon at the bottom right of the window! So that tells us our data is secure, right? Nope. In IE8 Microsoft changed the browser layout. That specific lock icon will tell me if the browser is filtering content coming from the Web site. So a user who does not do their homework will probably think every site on the Internet has been secured. Why didn’t they use another graphic to avoid this confusion???

Look to the right of the URL. Hey, there’s the lock icon! Yup, so this is where the user is suppose to look. There is just one problem however. If you are reading this post directly from my site you will notice you also have a lock icon to the left of the URL. All I did was mess with favicon. So by drawing the users eye to the URL to look for the lock icon we just made it easier to fool people into thinking their data is secure when its really not. Will the typical end user notice/care that the lock icon is before or after the URL? Yuck.

So where are we at

To summarize what has been discussed so far:

  • Liberal use of the lock icon can fool users into thinking their data is secure
  • Our security protocols support transmission of data without encryption
  • Digital certificates have a server at the bottom of the rabbit hole saying “trust me because I say its OK. Here, have some candy little geek” (OK, the candy bit is not part of the spec ;) )
  • The rabbit hole really is not a problem because we never look all the way down it anyway
  • We have security checks we choose not to use
  • We produce error screens that end users have become accustom to ignoring
  • If an attacker can break initial authentication, the integrity of the whole session falls apart
  • Security experts keep figuring out how to forge certificates and are finding new exploits all the time

Sanity check time

OK, so its easy to feel like the whole thing is insecure and we should run away to Vermont and build a moat around our house (inside joke, I know someone who has done this). Here’s some simple advice for the non-cipher- wienies that will help keep you relatively secure on the Internet. If you want full protection, disconnect now and build your own moat.

1) Look for HTTPS in the URL

Forget about lock icons and other fancy stuff. If you see “HTTPS” instead of “HTTP” then you know you are using SSL or TLS to secure the datastream. Remember this does not guarantee data privacy, so we still have more to do.

2) When in doubt, check the connection

Take a look at Figure #4. When I connected to this site and saw “HTTPS” I double clicked on the lock icon. That produced this dialog box. There is some real useful information here, like what level of encryption is being used to provide data privacy. This will tell me if my data is “safe” (encrypted).

Double click the lock icon during an HTTPS session to produce this screen

Double click the lock icon during an HTTPS session to produce this screen

This will also identify who issued the digital certificate. Remember the bottom of the rabbit hole is warm fuzzy. This means you really have to ask yourself if you think the issuing company has a clue about security, because you have little ability to check for yourself. Personally I never trust a server or company that signs their own certificates (this means you American Express!) because your options for verification are even more limited. They are just begging to get their client’s data compromised in order to save a few $$$ by not purchasing a certificate from a well known authority (note: Its OK to sign your own certs if you manage both ends of the connection, but this is not the case when we visit an e-commerce site).

3) Tweak your browser options

Finally, leverage what ever options your browser gives you to lock down your HTTPS sessions. I mentioned initial authentication comes down to a subjective judgment call, and the security of the rest of the session teeters on this point. If you sleep better verifying all certificates, go for it. If you feel comfortable just verifying with local info, that’s fine too (its your data after all). Yes SSL and TLS have some issues, but its the only game in town so do the best that you can with it.

4) Leverage your common sense

Last December I logged on to my bank site to pay some bills. When I was redirected to the payment server, I was presented with a self signed certificate. I’ve used this bank for years and know they use Verisign to sign their certificates. I immediately told my browser “no thank you”, and found out a day later the site had been hijacked.

The best way to keep your data safe is to use your head. If things do not look right, there is probably a reason why. While it can sometimes be hard to wrap your brain around the intricacies of technology, good old fashion street smarts can go a long way towards keeping you out of trouble.

That’s about it. Hope you found this info useful and don’t forget to tip your waiter!

C

No comments »

Posted in 2-alert, VPN

Tags:

What does the little lock icon mean in my browser? – Part 2

July 16th, 2009

In my last post I started talking about why your data might not be as secure as you think during an HTTPS session. We made it as far as the mandatory handshake requirements with SSL and TLS. In this post I’ll get into the optional features which is the start of where things can go wrong.

Optional portions of the SSL/TLS handshake

After the initial client/server exchange, the two end points are free to choose which options they feel are appropriate, depending on how the administrator has configured them. Next we could:

  1. Client can check the authenticity of the server using local info
  2. Client can go back to the trusted authority and check the certificates authenticity
  3. Client can check the authenticity of the trusted authority’s issuing server
  4. Client can send a copy of its digital certificate to the server
  5. Server can validate the client’s digital certificate if it has one
  6. Server can require the client to have a valid digital certificate

Wow! Lots of possibilities. We typically don’t implement the last three unless we have control of both ends of the connection (like with a VPN). For a secure connection to a Web server, we’re typically looking at just the first three possibilities.

How digital certificates work

First, let’s talk about those digital certificates. A digital certificate contains the public key for the entity described within the certificate. So the server is basically saying “This is who I am and here is my public key for asymmetrically encrypted communications”. The way you know you can trust this certificate is that it has been digitally signed by a mutually trusted third party, like Verisign. Specifically, its been signed using the private key of a certain server under Verisign’s control. The concept is you can use the public key of the Verisign server to check the signature created by its private key. If the hash validates, you know the digital certificate has not been messed with.

OK, here’s our first problem. The information we use to validate the web server’s certificate is actually a copy of the Verisign server’s digital certificate stored on the local system. Hummm. So if the client becomes compromised, we can fool it into thinking a bogus digital certificate is actually legitimate, right? Absolutely. However this would only be useful in specific situations. If I can compromise the client there are probably easier ways to get access to the information I’m looking for.

If we want to ensure we’re safe however, we can go with option #3 above and check the validity of the locally stored Verisign certificate. This would send us out to Verisign server #2 to get its digital certificate. If we want to insure that our copy of Verisign server #1′s digital certificate is OK, we can use Verisign server #2′s public key to check the hash. If the hash validates, we know the digital certificate for Verisign server #1 is valid.

Hummm. So how do I know an attacker didn’t mess with the transfer of Verisign server #2′s digital certificate? Because that has been digitally signed by Verisign server #3. Go get that server’s public key and check the hash. How do I know Verisign server #3′s cert has not been messed with? You guessed it. Go get the digital certificate from Verisign server #4. While this sounds pretty complex (and it is!) this gives us sound math we can work with. In other words, smart crypto people can look at this math and predict how safe it is to use. Cool. I’m a geek so trusting math is a natural. The problem however occurs at the bottom of the rabbit hole.

Why should I trust you?

Eventually we will run into what is called a self signed digital certificate. This is basically a server’s way of saying “trust me because I say so”. In other words, there is no math to calculate if we should trust this server or not. All we have is “warm and fuzzy”. In other words, we need to sit in a Buda pose, sign Kum Ba Yah, get in touch with our inner child, pointy up our ears, and ask ourselves “How do we feel?”. Really, that’s all we’ve got, and there is no wrong answer because its subjective. If we “feel” that final system is secure, then it is. If we “feel” it is insecure than it is. There is no math to help point us in one direction or the other.

What if the trusted third party messes up?

So you may be asking yourself “All that sounds great, but what if the trusted third party makes a mistake and gives a digital certificate to the wrong party?”. First of all, that could NEVER happen. Oh wait, it has happened. ;) Seriously, this is a valid concern as the chances of catching this after the fact are minimal.

Its possible to “revoke” a digital certificate. This is a trusted third party’s way of saying “Oops, we screwed up. You really should not trust that digital certificate we said is trustworthy”. So the concept is, when you get the Web server’s digital certificate you can go back to the issuing server to see if its been revoked.

OK, that’s set the groundwork for our HTTP session. In the next installment we’ll talk about what can specifically go wrong if we trust the security of the rabbit hole.

1 comment »

Posted in 2-alert, VPN

Tags:

What does the little lock icon mean in my browser? – Part 1

July 15th, 2009

You’ve been lied to, or at the very least mislead. Most sources will tell you:

  1. If you see the little lock icon in your browser
  2. If you see “HTTPS” instead of “HTTP” in the URL
  3. If you see the URL background change from white to yellow (depends on the browser)

Then your data is secured. By “secured”, most of us assume this means “The session is authenticated, encrypted and the authenticity of the server has been verified”. Unfortunately, this is not always the case. All the little lock icon tells you is that SSL and TLS is in use. Depending on where you actually see the little lock icon, even that much may not be true.

What is SSL and TLS?

Normally communications on the Internet take place in clear text. This means that anyone looking at your traffic can read it, and just as importantly, change it in transit. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are attempts to provide some level of protection for TCP based communications. When you see “HTTPS” in your URL, what that really means is you are running an HTTP session secured by either the SSL or TLS protocol.

We started off using SSLv1. Today we are up to SSLv3 and moving towards TLSv1. What’s the difference between SSL and TLS? For the most part, SSLv3 and TLSv1 are pretty much the same thing. The big difference is that Netscape created and owns the rights to SSL. TLS is an open specification. On the Internet we like to use open standards as often as possible.

Both specifications can be considered “sticky frameworks”. By that I mean the real job of SSL and TLS is to meld together a bunch of other specifications for the purpose of securing a datastream. For example neither defines specifically how to authenticate each packet, they simply point to HMAC-MD5 and HMAC-SHA and say “use that”. Neither specifically tells you how to encrypt the data, they just point to other specifications like RC4, DES and AES and say “use that”. This modular structure is pretty cool as it makes the specifications very flexible. It also ensures that these specifications will not easily be outdated. For example most of us know that DES uses far too small a key size to withstand a modern day brute force attack. No problem for SSL or TLS, just change to another encryption algorithm.

How SSL and TLS work

Both SSL and TLS are pretty lose frameworks. By that I mean that while some things are mandatory, a lot of what goes on in the communication session is optional. Let’s look at a typical session to see what we mean:

The client initiates communications with the server and starts the negotiation. The conversation goes something like this:

Client to server:

“Hi, I can fall back as far as using SSLv2 but would really prefer to use TLSv1. Here are the methods of securing the datastream I support …”

Server to client:

“No problem, I can support TLSv1. Out of the data protection methods you support, here’s the highest one we have in common…”

Server to client:

“Here’s a copy of my digital certificate.”

A couple of things to pull out of this exchange. The client identifies which security protocol it wants to use, but gives the server the option of falling back if required. This help with backwards compatibility, but its key to understanding why your session can end up being less secure than you thought it would be. The same thing happens with the methods or authentication and data privacy. The client identifies what it wants to use, but gives the server less secure options in case they are needed. Finally, the server sends the client a copy of its digital certificate for initial authentication purposes.

All of the above negotiations are required under the SSL and TLS protocol. What happens next however is optional. This is where our problems begin, and I’ll discuss that more in part 2 of this post.

No comments »

Posted in 3-err, VPN

Tags: