netsekure rng

Every so often I get the question – “What is the overhead incurred by using TLS?”. Strangely enough, I couldn’t find a straight answer by doing some searching on the web, so let’s explore the answer. The TLS handshake has multiple variations, but let’s pick the most common one – anonymous client and authenticated server (the connections browsers use most of the time). As per the TLS standard the handshake looks as follows:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                      Certificate
                                   <--------      ServerHelloDone
      ClientKeyExchange
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

One thing to keep in mind that will influence the calculation is the variable size of most of the messages. The variable nature will not allow to calculate a precise value, but taking some reasonable average values for the variable fields, one can get a good approximation of the overhead. Now, let’s go through each of the messages and consider their sizes.

• ClientHello – the average size of initial client hello is about 160 to 170 bytes. It will vary based on the number of ciphersuites sent by the client as well as how many TLS ClientHello extensions are present. If session resumption is used, another 32 bytes need to be added for the Session ID field.
• ServerHello – this message is a bit more static than the ClientHello, but still variable size due to TLS extensions. The average size is 70 to 75 bytes.
• Certificate – this message is the one that varies the most in size between different servers. The message carries the certificate of the server, as well as all intermediate issuer certificates in the certificate chain (minus the root cert). Since certificate sizes vary quite a bit based on the parameters and keys used, I would use an average of 1500 bytes per certificate (self-signed certificates can be as small as 800 bytes). The other varying factor is the length of the certificate chain up to the root certificate. To be on the more conservative side of what is on the web, let’s assume 4 certificates in the chain. Overall this gives us about 6k for this message.
• ClientKeyExchange – let’s assume again the most widely used case – RSA server certificate. This corresponds to size of 130 bytes for this message.
• ChangeCipherSpec – fixed size of 1 (technically not a handshake message)
• Finished – depending whether SSLv3 is used or TLS, the size varies quite a bit – 36 and 12 bytes respectively. Most implementations these days support TLSv1.0 at least, so let’s assume TLS will be used and therefore the size will be 12 bytes.

Now that we have an average size of each message exchanged, we can calculate the average handshake size. One has to keep in mind that messages exchanged have TLS Record header for each record sent (5 bytes), as well as TLS Handshake header (4 bytes). The most common case can be simplified such that each arrow in the handshake diagram is a TLS Record, so we have 4 Records exchanged for total of 20 bytes. Each message has the handshake header (except the ChangeCipherSpec one), so we have 7 times the Handshake header for total of 28 bytes.

The total overhead to establish a new TLS session comes to about 6.5k bytes on average (20 + 28 + 170 + 75 + 6000 + 130 + 2*1 + 2*12 = 6449).

TLS sessions once established can also be resumed. In the session resumption, some of the messages are omitted and the handshake looks as follows:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                               [ChangeCipherSpec]
                                   <--------             Finished
      [ChangeCipherSpec]
      Finished                     -------->
      Application Data             <------->     Application Data

The main difference here is that the ClientHello message will contain extra 32 bytes for the session ID it wants to resume.

The total overhead to resume an existing TLS session comes to about 330 bytes on average (15 + 16 + 202 + 75 + 2*1 + 2*12 =332 ).

Now let’s look at the overhead on the wire for the encrypted application data. The data is carried in TLS Records over the wire, so there are 5 bytes of header. Since data is encrypted and integrity protected, there is additional overhead that is incurred. Let’s assume that the ciphersuite negotiated between the client and the server is TLS_RSA_WITH_AES_128_CBC_SHA, which is mandatory for TLS1.2 and hopefully will be commonly negotiated going forward. Since AES is a block cipher, it requires the data to be sized in multiple of the block size. TLS 1.0 defines the encrypted data with block cipher as:

    block-ciphered struct {
        opaque content[TLSCompressed.length];
        opaque MAC[CipherSpec.hash_size];
        uint8 padding[GenericBlockCipher.padding_length];
        uint8 padding_length;
    } GenericBlockCipher;

Since most implementations don’t use compression, we can assume the data is the same size. The MAC in this case is computed using SHA1, so the size will be 20 bytes. AES128 has a block size of 16 bytes, so the maximum padding we can add to the data will be 15 bytes.

The total overhead of the encrypted data is about 40 bytes (20 + 15 + 5).

It is easy to modify the above calculations to reflect more precisely the specifics of an environment, so this should be considered a basis for TLS overhead and not the authoritative answer to the question posed.

As of Feb 12th, the solution for the TLS renegotiation man-in-the-middle attack is an official IETF standard:

http://tools.ietf.org/html/rfc5746

I’m super happy and excited as this is the first RFC I am a co-author of and it fixes a major problem with one of the most widely used security protocols. Now let’s hope it will get quickly implemented, deployed, and eventually enforced.

It’s been a while since I last checked any news or used a computer. I was away for more than a month spending time with our new baby daughter and almost completely disconnected from the tubes of the net.

Now that I’m back, I wanted to point to a patch from Microsoft that allows admins to disable TLS renegotiation on both the client and the server side. The security advisory is 977377 and MSRC has published a blog post with a bit more details.

The new RFC that will outline the changes needed to the TLS protocol to fix the problem is almost there and should be out “real soon now”.

The new TLS/SSL man-in-the-middle (MiTM) attack targets the renegotiation part of the protocol. There are two variations of the renegotiation – client initiated and server initiated. This tool allows you to test any web server (input as server:port) for client initiated renegotiation support, as server initiated renegotiation depends on specific server configuration. As currently there is no fix other than disabling renegotiation, this will pretty much tell you whether the server is vulnerable or not to this type of renegotiation attack

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 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 : ).