Re: Off-Topic - Encryption and Credit Card Processing (resent) (fwd)

---------- Forwarded message ----------
From: Kevin Steves
Subject: Re: Off-Topic - Encryption and Credit Card Processing (resent)
Cc: 'Marc E. Mandel' , firewalls@lists.gnac.net,
kevin@atomicgears.com
Date: Sun, 26 May 2002 16:23:00 -0700

On Sat, May 25, 2002 at 11:07:11AM +0200, Ben Nagy wrote:
> Netscape and MS appear to support "step-up" or "server gated"
> cryptography. Presumably any browser could (or they could have just not
> export crippled themselves in the first place). MS tries to take credit
> for it, but the history is unclear in the quick search I performed.

Netscape was the first to announce, as I recall. MS SGC, initially
at least, did not conform to SSLv3, as they decided for performance
reasons to short-circuit the renegotiation protocol.

This is the Netscape press release:
http://wp.netscape.com/flash2/newsref/pr/newsrelease428.html

This is really all moot at this point, with the wide-spread
availability of non-crippled browsers. I don't know why some
are still purchasing "128-bit SSL certificates".

Finally, this is dated (written shortly after the Netscape
announcement in 1997) but may be useful. I think there are more
technical details (OIDs etc.) in a document in the mod_ssl
distribution.

Netscape Exportable 128-bit SSL Software

Kevin Steves
Hewlett-Packard

Summary

Netscape recently received federal approval to export Netscape
Communicator with 128-bit encryption to customers worldwide, and
to export Netscape servers featuring 128-bit encryption to
certified banks worldwide. There has been confusion regarding the
technical details of this exportable 128-bit encryption method,
due largely to the lack of published technical information from
Netscape. This brief paper will describe the technical
implementation details of the Netscape method for establishing a
128-bit Secure Sockets Layer (SSL) session using an exportable
Netscape client. This method has been referred to by Netscape
personnel as step-up encryption. These details have been derived
from public mailing lists and private e-mail with Netscape and HP
employees.

SSL Handshake Protocol

SSL utilizes a handshake protocol to perform authentication and negotiate
cryptographic parameters. During the SSL handshake, the client and server
agree on a single cipher suite, which includes a key exchange algorithm, an
encryption algorithm (bulk cipher), a message digest for data integrity, and
a boolean identifying exportability. For example, the
SSL_RSA_EXPORT_WITH_RC4_40_MD5 cipher suite is exportable and specifies that
RSA is used for key exchange, 40-bit RC4 for bulk encryption, and MD5 for
data integrity.

The SSL client initiates the handshake by transmitting a hello message to
the server with a preference ordered list of cipher suites supported by the
client. The server will select one cipher suite from the client's list and
respond with its own hello message. Following is an abbreviated handshake
example in which an exportable SSL client transmits both a 40-bit RC4 and
40-bit RC2 cipher suite; the server selects the RC4 cipher suite.

C->S: ClientHello(SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5)
S->C: ServerHello(SSL_RSA_EXPORT_WITH_RC4_40_MD5)
S->C: Certificate(server_certificate)
S->C: ServerHelloDone
C->S: ClientKeyExchange
C->S: Finished
S->C: Finished

server_certificate is verified by the client via some local trust policy
(e.g. the certificate is signed by a trusted certifying authority).

SSL Session Renegotiation

SSL version 3 added the capability for a client or server to renegotiate, or
redo, the security parameters of an existing SSL session. This is typically
used during client authentication, where a client establishes a secure
connection to a server (with server authentication only), then requests a
document which requires client authentication, which is followed by a server
request to renegotiate the session and require the client to present a valid
certificate before the request is returned.

Step-up Encryption

Netscape's step-up encryption method utilizes special X.509 version 3
extensions agreed upon by Netscape and Verisign, a special Verisign global
certifying authority that is hardcoded into the Netscape executable, and SSL
session redo.

To utilize set-up encryption with an international browser, a company must
obtain an SSL version 3 compliant server than supports 128-bit encryption
(for Netscape servers this currently requires Netscape Enterprise Server
version 3.0; the reason is explained below), a Verisign global ID, and
Netscape Communicator version 4.0 or greater.

With these conditions satisfied, a sample handshake will proceed as follows:

C->S: ClientHello(SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5)
S->C: ServerHello(SSL_RSA_EXPORT_WITH_RC4_40_MD5)
S->C: Certificate(global_server_certificate)
S->C: ServerHelloDone
C->S: ClientKeyExchange
C->S: Finished
S->C: Finished

C->S: ClientHello(SSL_RSA_WITH_RC4_128_MD5)
S->C: ServerHello(SSL_RSA_WITH_RC4_128_MD5)
S->C: Certificate(global_server_certificate)
S->C: ServerHelloDone
C->S: ClientKeyExchange
C->S: Finished
S->C: Finished

There are two complete SSL handshakes, one with an exportable cipher suite,
followed immediately by another with a 128-bit cipher suite. There are two
full handshakes because the SSL protocol requires that an in-progress
handshake be completed before a session can be renegotiated.

global_server_certificate is a certificate that contains the special X.509
v3 extensions and that has been signed by the Verisign global certifying
authority that is hardcoded into the Netscape executable. When a certificate
is received with the special extensions, it is handled specially by the
Netscape certificate verification code. Currently, in order for other CAs to
be added, a patch release of the client is required. If
global_server_certificate is verified properly, a second handshake with a
128-bit cipher suite will be initiated by the client (it transmits a second
ClientHello message).

Cipher Suite Selection

SSL_RSA_WITH_RC4_128_MD5 is not the only cipher suite that can be used to
established a non-weak SSL session using the step-up method. The freely
available Netscape Communicator 4.X products implement two strong cipher
suites: 128-bit RC4 (SSL_RSA_WITH_RC4_128_MD5) and triple DES
(SSL_RSA_WITH_3DES_EDE_CBC_SHA). The triple DES cipher suite uses 3
independent keys in encrypt-decrypt-encrypt mode for an effective key size
of 168-bits. SSL_RSA_WITH_IDEA_CBC_SHA is not currently implemented in
Communicator (IDEA is a 128-bit block cipher).

In the free exportable versions of Netscape Communicator 4.X, 128-bit RC4
and and triple DES are available, but may only be used when a global
certificate is presented by the server. In Communicator, if you select
Security->Navigator->Configure SSL v3 you will see that 128-bit RC4 and
triple DES are labeled When permitted, indicating they are not available for
use at all times. The second sample SSL handshake presented earlier could
proceed as follows if both of these cipher suites were configured:

C->S: ClientHello(SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_3DES_EDE_CBC_SHA)
S->C: ServerHello(SSL_RSA_WITH_3DES_EDE_CBC_SHA)
S->C: Certificate(global_server_certificate)
S->C: ServerHelloDone
C->S: ClientKeyExchange
C->S: Finished
S->C: Finished

In this example, triple DES is used to establish the session in the second,
step-up handshake. Notice that SSL_RSA_WITH_RC4_128_MD5 is preferred by the
client over SSL_RSA_WITH_3DES_EDE_CBC_SHA (recall that the list or cipher
suites in the client hello is ordered according to preference). However the
server selected SSL_RSA_WITH_3DES_EDE_CBC_SHA for its server hello. This is
permitted by the protocol, and might be caused by a server that prefers the
triple DES cipher suite over 128-bit RC4, or by a server that does not
support RC4.

Netscape Communicator will order cipher suites according to the order they
are presented in the cipher suite selection dialog box. Netscape prefers RC4
over triple DES because of its speed, and they feel it's unlikely to be less
secure than 3DES (note that the work factor required to brute force a 3-key
DES key can be approximately equal to 112-bits of keyspace, due to a
meet-in-the-middle attack).

Netscape Enterprise Server 2.X Defect

No modifications to the SSL version 3 protocol are required for the step-up
encryption method to operate. However, a defect in the Netscape Enterprise
version 2.X servers prevents it from working. The 2.X servers will not
respond properly to a ClientHello message unless the server has sent a prior
HelloRequest message. HelloRequest is used by the server to initiate session
redo.
_______________________________________________
Firewalls mailing list
Firewalls@lists.gnac.net
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org