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.

• 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?

At the time of publishing, here is where everyone is:

Open SSL

• Workaround – Removes Renegotiation (OpenSSL 0.9.8l): Limited Public Availability
• Fix (OpenSSL 0.9.8m): Code Undergoing Initial Testing

Microsoft

• IIS, SChannel, Internet Explorer: Interoperability Testing in Progress
• IIS6 and 7: Not Vulnerable to Client-Initiated Renegotiation

Cisco

• Vulnerable Products: Code Undergoing Initial Testing

F5

• Workaround – Disables Renegotiation: Limited Public Availability
• Fix: Code Undergoing Initial Testing

NSS (Mozilla/Firefox)

• TLS protocol fix: Interoperability Testing in Progress

Sun

• Vulnerable Products: Code Undergoing Initial Testing

GNU TLS

• Fix: Code Undergoing Initial Testing
• Most Applications Are Not Affected

RSA

• Vulnerable Products: Interoperability Testing in Progress/Limited Public Availability

Opera

• Fix: Code Undergoing Initial Testing

For more information and updates:

• SSL/TLS Authentication Gap – Status of Patches

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