One of the challenges facing ssl implementations, and indeed, secu- rity products in general, is complying with various laws and regula- tions that restrict the use of cryptography. The United States, for example, currently treats cryptography like weapons and limits the ability of u.s. companies to export cryptographic products. In princi- ple, the goal of this policy is to avoid letting cryptographic products fall into the hands of terrorists and other criminals, thereby hamper- ing the ability of intelligence agencies to combat such criminals.1 The problem is particularly acute for companies such as Netscape and Microsoft. Those companies would like to make their Web browsers as widely available as possible, including making them downloadable from the Internet. Browser developers would also like to include the strongest possible cryptography in their products, however, and those two goals are in direct conflict with each other. Laws and regulations prevent browser developers from exporting software with strong cryptography, including distributing software using the Internet.
Such laws, while perhaps hindering the ability of criminals to com- mit crimes, certainly interfere with legitimate commerce. A bank, for example, might like to offer banking services over the Internet, even to customers outside the United States. Potential customers might balk, however, if they knew that their Web transactions were secured only by the deliberately weakened cryptography required to satisfy u.s. export laws.
_________________ 1
During the writing of this book, the u.s. government announced its intention to revise its export policy so as to eliminate these restrictions in many, but not all, cases.
Both Netscape and Microsoft have worked with the u.s. government to develop a compromise approach. The Netscape approach is known as International Step-Up, and it is the subject of this section. (Micro- soft’s very similar Server Gated Cryptography is the topic of the next section.)
5.2.1 Server Components
International Step-Up requires no changes at all to an ssl server im- plementation. The server simply responds normally to all ssl version 3.0 messages. The server does supply a critical element in the Inter- national Step-Up process, though—a special International Step-Up certificate. Note that the ssl protocol itself does not address the con- tents of public key certificates. It simply carries them (whatever their contents) in Certificate messages.
International Step-Up server certificates are special in two important ways. First, they contain a special attribute in the extended key usage (extKeyUsage) field. Appendix a discusses this field (and certificates in general) in more detail, but the special attribute for Netscape’s In- ternational Step-Up includes the object identifier value of 2.16.840 .1.113730.4.1. The second important characteristic of International Step-Up server certificates is the certificate authority that issues them. All such certificates must be issued under the VeriSign Class 3 authority. (In theory, it would be possible for any authority to issue International Step-Up certificates; however, as of this writing, Net- scape’s web browser clients are pre-configured to only recognize VeriSign as a legitimate International Step-Up certificate authority.)
5.2.2 Client Components
Most of the action with International Step-Up happens in the client. Clients that wish to use International Step-Up are generally those that have been licensed for export (otherwise, they would not be sub- ject to export laws restricting the strength of their cryptography). Such clients are not free to use strong cryptography in all cases. If they support International Step-Up, however, the client has a latent capability to support strong cryptography. The client is designed to
keep this capability hidden from normal servers (thus it conforms to u.s. export regulations), but when it recognizes a server’s Interna- tional Step-Up certificate, it reveals its hidden capability and negoti- ates strong cryptography.
Figure 5-5 shows the complete message exchange. Note that in mes- sage 1, the client only proposes to support export strength encryption. The client does this even though it is actually capable of stronger en- cryption; clients must do this to obtain the necessary u.s. export li- censes. The server has no choice but to select a cipher suite from among those proposed by the client, so the ServerHello message will indicate export-strength encryption. (At this point, the server does not know that the client supports International Step-Up.)
Once the client receives message 3, however, it knows that the server is capable of supporting International Step-Up. It continues with the regular handshake negotiation (messages 4 through 9), but instead of beginning the exchange of application data, it starts a new negotia- tion with a second ClientHello message (message 10). This message proposes full-strength cipher suites. The server responds to this ap- propriately, and at the end of the second handshake with message 18, both parties have negotiated a full-strength cipher suite.
5.2.3 Controlling Full-Strength Encryption
International Step-Up is a compromise between the needs of the u.s. government to limit the use of full-strength cryptography abroad and the desire of browser manufactures to offer the strongest possible product to the widest possible audience. Because the u.s. government has verified that Netscape’s Web browser only renegotiates full- strength cryptography after the server has produced a special Interna- tional Step-Up certificate, Netscape is free to distribute its browser worldwide, even by Internet download. Controlling the use of full- strength encryption becomes a matter of controlling the issuance of International Step-Up certificates. Currently, only one certificate au- thority (VeriSign) is able to issue International Step-Up certificates, and the u.s. government controls which companies are allowed to purchase those certificates.
Server ClientHello (export cipher suites)
ServerHello (export cipher suite) Certificate (International Step-Up) ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished 1 2 3 4 5 6 7 8 9 Client
ClientHello (full-strength ciphers) ServerHello (full-strength cipher)
Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished 10 14 15 16 11 12 13 17 18 secured with export cipher suite secured with export cipher suite not secured secured with full- strength cipher suite not secured full- strength