Chris Baily and I wrote this paper back in 2004 and for various reasons we never got around to publishing it, while looking through my un-published articles I saw this and though that it might still have some value so I am publishing it here.

Introduction
If you have ever looked into purchasing a certificate to secure your Web site, you’ve probably heard of Server Gated Cryptography (SGC). If you have ever wondered what it is and how it affects your Web site, this is the article for you.

Let’s begin with why we even bother with SSL and TLS. Now, most people know that SSL and TLS are the technologies that enable the “lock” icon in browsers. This icon signifies that the session is “secure” to users, but what does this really mean?

Name Authenticity – The client can rely on the fact that it is communicating with the server represented in the host name in the Web address.

Confidentiality – The information being sent from both the client and your SSL and TLS enabled server has been encrypted. These are all great characteristics, but there’s more to them than may be apparent on the surface.

Let’s explore each of them what makes them factual.

Name Authenticity
The SSL and TLS protocols are based on the premise that each server or cluster of servers that represent a particular host name has a secret called a private key. The operative word here is private. If the secrecy of this key is compromised, an attacker could spoof the server’s identity or even decrypt the data being sent to the server.

Having a private key isn’t enough—you also need the corresponding public key. That key, along with the name of the server, is wrapped up or bound together into a certificate. A certificate asserts the name of the server in a way that is provable. Why is having a certificate important?

Consider the HTTP protocol and the use of the Domain Name System (DNS) resolution protocol to resolve the IP address of the server being communicated with. Because DNS is a protocol that was designed without a security subsystem, DNS can suffer from a number of network-based attacks. For example, in DNS there is simple man-in-the-middle attack where an attacker intercepts a request for the IP address that is associated with a server. The attacker then returns the IP address for their server instead of the one originally requested. When that server hosts a web site the attacker can then duplicates the look and feel of the Web site in question and leverages the user’s trust of that Web site to gather confidential information from that user.

Without the SSL and TLS, protocols, the user wouldn’t have known that this attack had taken place. By using SSL and TLS in the HTTP protocol, however, we can detect these types of attacks and prevent connections to fraudulent servers. SSL and TLS use certificates to enable this. The client and the server use a negotiation process to prove that the server has the private key associated with the certificate presented by the server, that the server certificate was issued by a certificate authority trusted by the client, and that the server certificate is associated with the same server that they are communicating with.

What is a certificate authority? A certificate authority is a third party that verifies the identities of individuals and their affiliations with the organizations that they claim to represent. They do this by having strong authentication and operational practices for themselves and their subscribers.

Confidentiality
The confidentiality offered by SSL and TLS are primarily the result of two assumptions in the protocol—the secrecy of the private key possessed by the Web server, and the strength of the cryptographic algorithms and keys that are used to protect data as it passes between the client and the server.
Although the identity of the server is authenticated using its private key and associated certificate, the data that is passed between the client and the server are encrypted using secret keys (symmetric keys) that are exchanged as part of the SSL and TLS protocol.
A number of cryptographic algorithms are based on secret keys. The strength of these types of algorithms is measured in part by the length of the secret keys that they can use to encrypt data. These algorithms provide varying levels of security. The accepted standard is that algorithms that can encrypt data with keys that are 128-bit or longer are strong while anything protected with keys of lengths less than that are considered weak. This is where SGC has an important role.

What is Server Gated Cryptography?

SGC is a (software) technology from Microsoft that allows U.S. vendors to ship software outside of the U.S. to companies that need strong cryptography for session protection—not for the encryption of the data to be persisted. This technology requires digital certificates.

The U.S. government at one time restricted U.S. vendors from offering strong cryptography to countries outside North America. In fact, strong cryptography was considered to be munitions by what is now known as the Bureau of Industry and Security (Department of Commerce, U.S. Government). Despite this, we still had in a global economy. The need for secure communications with parties outside the U.S. still existed. This is why SGC was developed.

To satisfy the requirement for security, the software vendors who supported cryptography had to ship two different versions of their software—export and nonexport.

To get permission to export this software outside of the U.S., these vendors had to implement constraints to prevent entities considered to be hostile from getting these more secure sessions. In the case of SSL/TLS, this was done by requiring that the authorities that issued certificates signed contracts agreeing to issue only certificates capable of SGC to authorized users such as financial institutions. Without a certificate from one of these SGC-enabled certificate authorities, clients without direct support for strong cryptography were only protected by 40- or 56-bit security, which during software export restrictions was considered weak.

Microsoft and other software vendors stopped shipping nonexport or weak encryption versions of their software shortly after the U.S. lifted its export restrictions in early 2000.

The Waning Need for Server Gated Cryptography

Today, almost all Web software by default supports strong (128-bit or greater) SSL without the use of SGC. The primary value of SGC–to ensure a strong encryption SSL session to clients supporting only weak cryptography–has waned. The importance of having a strongly encrypted SSL session has not. Advances in computing power along with more sophisticated attacks have made the adoption of 128-bit security more important than ever. RSA Laboratories estimates that an arbitrary 56-bit symmetric key can be broken by an attacker in less than 5 minutes. Additionally, the recent improvements in specialized factoring hardware has changed the landscape when it comes to the security offered by small RSA keys as well.

As of January 2004, an estimated 85% of browsers in use were shipped with strong encryption by default [IE 5.5, IE 6.0, Mozilla 1, Opera 7.0, and Safari]. Additionally, conservative figures would suggest that 10% of the platforms that didn’t support strong cryptography have been upgraded, and the remaining 5% are rapidly being upgraded as well.

This data shows that only the browsers released before the export restrictions were lifted (2000) don’t support strong cryptography out of the box. These browsers also have known security issues. For example, Internet Explorer 5.01, released in 1998, was the last browser released by Microsoft that didn’t by default support strong cryptography. This version of the browser had sixteen critical updates and each one of these updates may have fixed several issues. Security issues are not limited to Internet Explorer. For example Netscape Navigator also has had numerous critical issues fixed since it was originally released. These older browsers don’t support the newer revisions of the SSL and TLS protocol that were developed to address security vulnerabilities in these protocols. This alone may be adequate justification for requiring older clients update their browsers.

Although clients play a significant role in the establishment of secure communications with servers, administrators can take small steps to help enable secure communications with their customers. Specifically, to significantly reduce the risks of downgrade attacks, their can configure their servers to use only strong cryptographic suites and the latest versions of SSL (TLS).

SGC can help strengthen the security of the SSL session. SGC does this by increasing the strength of the encryption used for clients running on old browsers. This object is defeated if a potential attacker can exploit a security weakness in the browser or the protocol that is not related to encryption strength. Users who want stronger security must keep their software up to date, and if possible, upgrade to the latest browser versions (see sidebar) so as to benefit from the security improvements offered in these more recent versions.

Summary
Encouraging clients to migrate to more recent browsers that are capable of supporting the more modern security protocols and strong cryptography will also address known security vulnerabilities in these clients. As a result, users will have a more secure and reliable Web experience. Continuing to depend solely on SGC provides only a feeling of security rather than a more secure environment if these other issues are not also addressed.