netsekure rng

As part of my testing of how many trusted root certificates I need for my day-to-day activities, I needed to ensure I don’t trust any certificate authorities. There is a great post by Nelson Bolyard to one of the security mailing lists of Mozilla, which explains why one should not delete CA certificates, but rather disable them. The main take away is that there is a big difference between the statements “I don’t know you” (if you remove the certificate) and “I know you and I don’t trust you” (disabling the certificate). Some browsers also handle these errors differently.

The different browsers store certificates differently. IE, Chrome, and I believe Safari as well (haven’t tested it) on Windows use the OS built-in certificate infrastructure, while Firefox uses its own certificate storage. As such, here are the steps you need to take for the two different cases:

IE, Chrome (Safari?)

You need to run the certmgr.msc utility (either through Start->Run/Search or from a command prompt). This will launch the UI used to manage the certificate stores in Windows for the current user.

CertMgr Certificate Stores

The “Third-Party Root Certification Authorities” stores all the trusted 3rd party CAs. You will find either a fairly small set of those if Windows hasn’t downloaded the full list, or quite a bit of them after the full list has arrived. To disable the root certificates, select the ones you want and drag them to the “Untrusted Certificates” store and drop them under the “Certificates” subfolder. This instructs the certificate infrastructure in Windows to not trust these certificates. The result is that even though you have the certificates in other stores, the operations will fail. The “Untrusted Certificates” store trumps all others, so you don’t have to worry about forgetting a certificate somewhere else.

Keep in mind that doing this in Windows will affect all programs that use SSL/TLS and certificates. I’ve broken my twitter client for example by removing all CAs from the trusted list : ).

Firefox

You will need to click on Tools->Options, select the Advanced category, select the Encryption, click View Certificates, and click on the Authorities tab. This will open up a window with all the trusted certificate authorities. For each of those, once you select it, you can click on the “Edit” button and you will see a window that looks like this:

Firefox Trusted CA

This CA is trusted for all 3 types of identification. To disable the certificate, just uncheck all the check boxes and click Ok:

Firefox Disabled CA

The result is that this certificate is no longer trusted to vouch for the identity of anything. You need to repeat the process for all the certificates you want to disable and I don’t know of an easy way to automate this. For the certificates listed as “Builtin Object Token”, Marsh Ray has tried deleting them and claims that this results in disabling them (since they are built-in and cannot be deleted) after restarting Firefox.

After you have disabled the CA certificates, you can expect SSL/TLS connections to fail if the certificate is issued by a disabled CA.
Have fun browsing with minimized attack surface : )

With the press coverage lately about governments being able to subvert SSL/TLS by coercing a certificate authority into issuing rogue certificates, I decided to do some data gathering in order to answer a simple question:

How many trusted roots does the average person need in their browser?

To answer the question, I wrote a small tool to collect the root cert for a list of sites and ran it on a sets of data – a mix of known SSL/TLS sites and hosts on the Alexa Top 1 Million list. So out of 350k hosts queried, I was able to collect 50812 entries. The stats are fairly interesting and somewhat expected. The number of certificate authorities that have issued more than 50 certificates for that set of data is 37.

While I was gathering the data, it became known that even Mozilla includes some root certificates that don’t have complete clarity of ownership.

My plan now is to remove most of the CA root certificates that ship in browsers. It will be informative to see what breaks and how many issues I run into. After a month or so of usage, I will post the details and hopefully it will be an easy guide as to the smallest set of trusted CAs to have and not be impacted in daily business. Granted this will be a US centric list, most international users can probably add one or two trusted roots that are for CAs issuing country specific certificates.

What follows is the list of root certificates (also available as text file) sorted with decreasing popularity. The format is “Number of issued certs | Friendly name | Subject”.

7519 | GeoTrust | OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4277 | USERTrust | CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
4007 | Go Daddy Class 2 Certification Authority | OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
3701 | VeriSign Class 3 Public Primary CA | OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
2948 | USERTrust | CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
2649 | thawte | E=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA
2077 |  | E=info@plesk.com, CN=plesk, OU=Plesk, O=Parallels, L=Herndon, S=Virginia, C=US
1898 | Equifax Secure Global eBusiness CA-1 | CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
1806 | VeriSign | OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
1580 |  | E=webaster@localhost, CN=localhost, OU=none, O=none, L=Sometown, S=Someprovince, C=US
1461 |  | E=root@localhost.localdomain, CN=localhost.localdomain, OU=SomeOrganizationalUnit, O=SomeOrganization, L=SomeCity, S=SomeState, C=--
1378 | thawte | E=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, S=Western Cape, C=ZA
1366 | VeriSign | CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
1189 |  | E=info@plesk.com, CN=plesk, OU=Plesk, O="SWsoft, Inc.", L=Herndon, S=Virginia, C=US
922 | Entrust | CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US
902 | GlobalSign | CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
783 | GTE CyberTrust Global Root | CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US
737 | CúOúMúOúDúO | CN=COMODO Certification Authority, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB
692 |  | E=ca@snakeoil.dom, CN=Snake Oil CA, OU=Certificate Authority, O="Snake Oil, Ltd", L=Snake Town, S=Snake Desert, C=XY
461 | DigiCert | CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US
394 | Starfield Class 2 Certification Authority | OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
264 |  | E=hostmaster@ispgateway.de, CN=webserver.ispgateway.de, O=ispgateway, L=Kempten, S=Bayern, C=DE
257 |  | E=info@parallels.com, CN=plesk, OU=Plesk, O="Parallels, Inc.", L=Herndon, S=Virginia, C=US
208 | Entrust (2048) | CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net
198 | Trustwave | CN=SecureTrust CA, O=SecureTrust Corporation, C=US
168 |  | E=sslsign@lxlabs.com, CN=*.lxlabs.com, OU=web, O=lxlabs, L=WA, S=WA, C=IN
143 | thawte | CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US
101 |  | E=info@confixx.com, CN=confixx, OU=Confixx, O="SWsoft, Inc.", L=Herndon, S=Virginia, C=US
98 | StartCom Certification Authority | CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
92 |  | E=support@cacert.org, CN=CA Cert Signing Authority, OU=http://www.cacert.org, O=Root CA
87 | USERTrust | CN=UTN - DATACorp SGC, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US
71 | VeriSign | OU=Secure Server Certification Authority, O="RSA Data Security, Inc.", C=US
70 | Starfield Technologies | E=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
64 |  | CN=localhost, OU=For testing purposes only, O=Apache HTTP Server
63 |  | E=admin@suresupport.com, CN=suresupport.com, OU=suresupport.com, O=suresupport.com, L=US, S=US, C=US
62 | SECOM Trust Systems CO LTD | OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
61 | Network Solutions | CN=Network Solutions Certificate Authority, O=Network Solutions L.L.C., C=US

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.

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

I want to share a story that had me completely puzzled and frustrated. I had to install PGP Desktop for something I’m playing with. I was amazed by PGP (the company) because I thought those guys understand security, the concept of digital signatures, and the crypto area in general. Well, believe it or not I had changed my opinion. After receiving the PGP Desktop zip file, I cracked it open to install the software. What do I find? Another zip file inside it along with a PGP signature file.

This is all good and the idea is that you should verify the signature of the installer to ensure it comes from the actual author. But this is a chicken/egg problem. I need to PGP to verify the installer, but I cannot since I’m trying to *install* PGP. I moved on, since there was no way (without using some other PGP package) to verify the installer zip file. So I fire up the installer on a test machine to see how it will go. To my surprise the installer comes from “Unknown Publisher”.

Hmm, I would think PGP being a security company selling encryption/signing software would definitely sign their code, but I guess I assumed too much. Since this was on a test machine, I decided to go through the entire process and see what happens. Maybe they launch another installer from inside it that is signed. They do have a MSI package inside it that gets installed, but it is still not signed :(

Total failure in my book for PGP. After I installed the software, I decided to verify the signature on the zip, since I now had PGP Desktop installed : ). Here comes the next surprise. PGP automatically looks up the key that has signed the package (cool), downloads it (cool), and verifies the package (cool). But what do I see in the log?

The key is invalid?!? Turns out that I have to explicitly download the PGP Release Key into my keyring for it to verify properly and say the key is valid. I wouldn’t mind doing this step (even though some of the PGP keys should be really shipping with the product), but if you are going to do the download for me, please do it properly. It only worked after I had manually copied the key ID from the invalid key, downloaded it to my keyring, and tried verifying the file again. (Nevermind that the log doesn’t have timestamp associated with it).

My usual approach is to always double check things that seem as weird as this. I thought I might have missed some support article or some other resource outlining the proper way to verify and install PGP. So I hop on support chat with PGP. I would leave it up to you to interpret the chat log yourself:

SupportTech: Hi, my name is SupportTech. How may I help you?
Nasko: Hello
Nasko: I wanted to ask a question about the installation of PGP Desktop
Nasko: I got the zip file that contains another zip file and a .sig file (the signature)
Nasko: How do I verify the signature ?
Nasko: It seems it is PGP signature, but me trying to install PGP, it seems like the chicken/egg problem
SupportTech: Unfortunately the only way to verify the signature is by having a previous version of PGP Desktop installed or after installing the software.
Nasko: Well, if I’m first time customer, there is no way for me to verify the zip file
Nasko: And what bothers me even more
Nasko: your installer is not signed, so it comes from “Untrusted” source
Nasko: How do I know what I am installing is indeed PGP Desktop from PGP?
SupportTech: For one, you need to login to LEMS in order to receive the download link. Since this is a secure site you can verify from the certificates that you are indeed downloading from PGP Corporation.
Nasko: is the actual download performed over https?
Nasko: Even if it is, I would feel a lot more comfortable if the installer is a signed binary
Nasko: such that Windows actually recognizes the author
Nasko: PGP is a security company after all
Nasko: and, no, the download link is not HTTPS
Nasko:  http://download.pgp.com/{random_url_part}/PGPDesktop9.12.0_Windows.zip
Nasko: what prevents a man-in-the-middle to replace the file on the wire ?
SupportTech: I understand that concern but it is currently not available in the installer. I do not have any information on if our development team plan to incorporate it.
SupportTech: Correct, it is not an HTTPS download.
Nasko: Is there any way customers can file issues or requests for the product?
SupportTech: Yes, there is this form:  http://www.pgp.com/products/feature_request_form.html Which goes directly to our developers.
Nasko: Thanks

I would give them props for at least having a way to relay feedback to the developers. This was the only ray of light in this whole mess.

In conclusion, I wouldn’t be bothered as much by all of this if the product was free. But for the steep price I expect polished product, not something I have to wrestle with for a day just to get up and going. So if you are security conscious and don’t have existing PGP software, you just don’t have any way to trust the product!

P.S. I am skipping the whole problem of PGP Desktop messing up my networking stack. You can get the idea from this  KB article, though the installer failed to create the rollback file, so I had to do all this by hand : (.

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.