Government websites play a critical role in the transfer of information to citizens, visitors, businessmen and others throughout their lives. Most importantly many people trust government websites implicitly. By virtue of this immense trust placed in websites which are relied on for information dissemination and collection by the government, one would expect that something as basic as SSL authentication (via certificates) would be in use by these websites to prove unambiguously to visitors that they are really connecting to the website they expect.

Consider the fact that malicious individuals and organizations have already targeted government organizations including the FDIC, IRS, FBI and many more with success. The government response trying to educate the masses can be found in many places. [1] [2] [3]

The goal of this experiment:

• To determine whether government sites provide authentication information using HTTPS.
• To identify characteristics of government websites using or not using HTTPS.

Experiment methodology:

An initial corpus of 150 government websites was mined (via USA.gov). Each website was tested for three signs that indicate whether they employ any authentication mechanism to prove their identity to a visitor.

This experiment was conducted between February 24th and February 25th, 2010.

The three points are listed below:

1. Does the website offer a SSL connection secured by a certificate?
   • If it does, we identify the issuer and the expiration date.
2. Does the website respond to the HTTPS request within 60 seconds?
   • If it does not, we identify the server as mis-configured.
3. Does the website seem to have pages, which have an “https://” in the URL?
   • We find these pages as indexed by Google (e.g. https://secure.site.gov/login.asp).

We present the most interesting results here:

• Only 53% of government sites offer an SSL certificate to prove their identity.
  Note: The certificates for these sites will not expire in less than 30 days.
• Approximately 6% of government sites have self-signed SSL certificates or certificates signed by authorities which are not widely recognized.
  Note: Accessing these websites via a modern browser will cause a warning message to be displayed.
• Approximately 13% of government sites use expired SSL certificates to prove their identity.
• Approximately 1% of government sites have credentials which will expire in less than 30 days.
• A whopping 33% of government sites with HTTPS are mis-configured. However, they work fine with HTTP.

Significant numbers of government websites are not using authentication mechanisms effectively.

Conclusion:

This limited experiment shows that websites operated by the government have a long way to go in terms of proving their identity to end users. These issues should not be treated lightly as they provide impetus to malicious individuals to develop phishing scams targeting government owned infrastructure.

Note: Due to the sensitive nature of this information we will not disclose specific government sites with security issues.

News, Report, Security .gov, https, SSL

You might remember the article I wrote a couple of weeks back regarding the then recently found vulnerabilities of SSL 3.0 (TLS 1.0). Well, things just got real.

• New Security Issues come to light with SSL 3.0

At the time, some researchers even went so far as to say that the vulnerability was only theoretical! Too theoretical to even worry about. The attack is described in detail:

• TLS renegotiation vulnerability (CVE-2009-3555)

It appears that the popular micro-blogging site Twitter first fell victim to the attack. The Register has the full story:

• Researcher busts into Twitter via SSL reneg hole

Now that the attack is in the wild, where are the patches?
Read more…

News, Security CSRF, https, malicious websites, man in the middle, MITM, SSL, TLS

New SSL Security Issues: A vulnerability allowing hijacking of an already connected SSL 3.0 (TLS 1.0) sessions has been disclosed.

SSL technology provides an end-to-end secure communications tunnel used most commonly by the HTTPS protocol. This, most recent, vulnerability allows an attacker to insert text of their choice into the data-stream, even after the secure handshake has occurred. This is another security gap created by the standard’s renegotiation process that is intended to allow a new SSL connection to be established over an already connected SSL session.

SSL renegotiation is most useful in the following situations: when client authentication is required, to use a different set of encryption and decryption keys, or when the server wants to switch encryption or hashing algorithms. For now, some patches have been made available that disable this functionality completely in order to avoid the vulnerability.

It will probably be a few weeks until patches including a reworked renegotiation mechanism appear. Most importantly, a fix has been in the works (by most browser vendors) but it won’t be out until the respective vendors finish their work. So, don’t depend on SSL until your browser is patched.

More Information:

• Another Protocol Bites The Dust
• Renegotiating TLS
• MITM attack on delayed TLS-client auth through renegotiation

News, Security https, malicious websites, man in the middle, SSL, TLS