netsekure rng

Windows 7 includes support for TLS 1.1 and TLS 1.2. I’ve been running with enabled 1.2 support for a while now and no problems at all, so I figured I’d share how to enable it. You need to import these 4 reg keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000

This will allow Win7 to use TLS 1.1 and 1.2, but that will work for apps that don’t explicitly ask for the TLS version they want to use. IE is one of those that want to be in control, so you need to tell it explicitly that you want it to use the new versions of TLS. To do that, you need to check the 1.1 and 1.2 checkboxes under Tools->Internet Options->Advanced->Security.

After you’ve done that, one may wonder how to check if this actually works. You can go to one of the few TLS interop servers available on the net. Here are a few that I know of which support TLS 1.2:

• https://www.mikestoolbox.org/. This server will display the TLS version your browser uses right on the page
• https://tls.woodgrovebank.com/ – Microsoft’s TLS interop server
• http://tls.secg.org/ – Certicom’s interop server which shows you details about the entire handshake.

In general, you can check the page’s properties for the connection info. Going to Mike’s toolbox site IE shows “TLS 1.2, AES with 128 bit encryption (High); RSA with 1024 bit exchange”.

Hopefully enough people will support TLS1.2 soon enough so the world can move on : )

I recently installed a plugin for my blog to help with one of the daily tasks I do, only to find out that it is improperly coded, such that it requests resources using HTTP, even though I access my admin section through HTTPS. With all the latest findings on how insecure the web is and the CookieMonster tool by Mike Perry in the wild, this is not a risk I’m willing to accept. The developers of the plugin are completely unresponsive, so I figured I’ll just block my browser from loading mixed mode content (HTTP and HTTPS).

Here comes the fun part. I am a heavy Firefox user and use IE only occasionally. The problem is that Firefox doesn’t have such a feature. It has a dialog box warning you about mixed mode content, but it doesn’t prevent downloading plaintext content. It is rarely that I feel IE is doing much better than Firefox*, but in this case I have to give it the thumbs up, since it actually has a setting to disallow loading of insecure content.

After hunting around the web for a way to disable mixed mode content from loading in Firefox, the only thing I could find is an extension developed by Standford people – ForceHTTPS. Their paper is an informative read if you are not familiar with the problems with mixing content, but alas their extension does not work with the latest version of Firefox : (. I tried contacting them, but so far I haven’t gotten any response. I wish Firefox will include such a setting in the core browser, but if not, I might be forced to write a similar extension myself. If someone knows of other extensions that do this, let me know.

* After this year’s DefCon, I must say that IE has gained some points on its scoreboard when it comes to security.

In case you haven’t seen it yet, zf0 summer of hax was released in the last few days. While scanning through the content, I read a paragraph in the “Industry Check” section that perfectly sums up the state of computer security these days:

Are you professional types really this out of touch? I see all these papers
about how to protect yourself from these super-fucking-advanced techniques and
exploits that very few people can actually develop, and most hackers will NEVER
USE. It's the simple stuff that works now, and will continue to work years into
the future. Not only is it way easier to dev for simple mistakes, but they are
easier to find and are more plentiful.

It is indeed much easier to look for a misconfiguration in the web app than to hack the actual web server software (be it apache, IIS or some other). It is much easier to guess the secret questions of a person and gain access to their account than it is to hack the actual service (be it web mail or something else). At the end of the day, people should be looking at security as an end-to-end picture, not just focus on parts of it. The tried and true “a chain is as strong as its weakest link” is in full force here.

I recently read a paper on the topic of strong passwords. While going through it, it hit me that very often people will discuss a way of solving some problem (phishing for example), but they fail to enumerate what the attack vectors are and subsequently how the solution addresses these attack vectors. I like how the paper actually lists the threats at the very beginning and discusses them throughout. When solving a problem or coming up with a security product, one should be very clear as to what it is protecting against. It is not often that you see this clearly addressed.

I don’t quite agree with all the views presented in this paper, but it was overall a very interesting read. The idea of brute-forcing not only a single account but all accounts based on statistics was an approach I had not seen before.

The recent story on the twitter breach of company information reminded me of an interesting research I recently saw. A few researchers have worked with real people to gather data how well security questions used by online apps work. Their paper has all the glory details,but there are two things that stood out to me:

• secret questions are statistically easy to guess with just a bit of information about a person
• putting bogus data as the answers is doomed to fail

If one looks back in time, most (highly visible) account compromises happen through the password reset/recovery mechanisms, not through a vulnerability in the web application itself.
It is common for people to focus on the wrong thing to improve on. In addition to ensuring the security of the site, more research needs to be done in improving the authentication and recovery/revocation. With the growing popularity of social networks, finding information about people is trivial, so I think unless some changes are made, we will see more and more of these compromises.

I recently spent some time looking at a very interesting issue, so I wanted to share it and save people some time troubleshooting similar issues. The problem was that a site requiring TLS client authentication was loading very slowly – about 30 seconds page loading time for the index page, which to say the least on today’s fast networks is incredibly slow. The setup was as follows:

Client Browser <—> ISA <—> Web Server

Naturally the first step was to look at what was happening on the wire. Firing off a sniffer and capturing the traffic, the strange thing was that there were multiple Change Cipher Spec (CCS) TLS messages. In general, when you negotiate a SSL/TLS session, you do Change Cipher Spec once and from there on the traffic is encrypted and flows between the client and the server. After spending some time looking at different traces one thing came out as a pattern – the number of encrypted CCS messages was roughly equal to the number of HTTP requests made from the client minus the number of TCP/IP connections used by the browser. So I fired up the debugger to help us confirm that this was indeed the case. Debugging the Microsoft SSL/TLS implementation is a bit tricky, since the handshake processing happens in the lsass.exe process (which hosts all security protocol providers) and the actual encryption/decryption of data happens in the process using TLS (the browser in this case). Some debugger tricks and a few sweat spots later, it was confirmed that for each HTTP request the server will send a HelloRequest message back to the client, which is the protocol message used by servers to force clients to reauthenticate. It was very strange that for each resource the brower fetches from the server a new renegotiation is required, since this is not the normal mode of operation.

What’s next in the network path after the browser – the ISA server. After digging around all the settings, what picked the attention was the setting below:

In the case of the slow config, the checkbox was unchecked and the timeout value was greyed out, though still showing 300. What the admin assumed is that 300 is the default value, so the unchecked box didn’t matter much. Well, what it really means is that the ISA server will *not* cache the client certificate at all, which in turn causes the client to authenticate for each request it sends to the ISA server. Needless to say, once the checkbox was checked, there were no extreneous CCS messages exchanged and the page was loading much much faster.

I never suspected that such an innocent looking checkbox can cause so much trouble : ).

One of the hard things to troubleshoot in Windows domains is NTLM authentication and the interesting MaxConcurrentAPI setting. When user account to be authenticated on the server does not belong to the local account database, the server must forward the authentication to a domain controller. It does so over the Netlogon secure channel. As such, it is governed by the MaxConcurrentApi setting as to how many outgoing authentication requests are allowed at a time. When you have a loaded server, this can create a problem, an example of which is described in an ISA server configuration article. Finding the root cause is very laborious process, so we’ve added performance counters to Netlogon to allow troubleshooting this issue. For Windows 2003, a hotfix is required, but for Windows 2008 and later it is present in the core install.
I was thinking of writing a very thorough guide on how authentication works in this type of scenario, but found out that the ISA documentation team has beaten me to it. Their description is targeted to ISA server, but you can replace it with any other application server doing user authentication using NTLM.

There are also another two articles (1, 2) that are useful and helpful material to read related to the throughput of Netlogon secure channel traffic. If you still think there is more that can be done to describe this setting and issues surrounding authentication, feel free to drop me a line or leave a comment.

P.S. If you are hitting this issue, you should seriously audit your network and applications as to why they are not using Kerberos for authentication. There are a few common pitfals as to why NTLM ends up being the auth protocol, but that might go in another post of its own.

It is interesting to see how the attack methodologies change with time. As security protocols become more mature and secure, people have moved up the stack. Case in point is the Defating SSL presentation which outlines how an attacker can take advantage of MiTM techniques to bypass SSL. The attack is against the end-to-end scenario, not the protocol itself, even though the protocols themselves sometimes have (implementation) issues too. As time has proven already, the weakest link in most software systems is the user when it comes to security and we all know that the system is as secure as its weakest link. It is/will be interesting to watch the evolution of the Internet and tools in the future to account for the weakest link. Relying on just presentation is not enough as proved by the above presentation. We need to solve the problem in an end-to-end manner while minimizing the interaction with the user. By reducing user input, we reduce the attack surface against the weakest link and achieving a more robust system.