No, what's going on here is that you're negotiating an export cipher
suite that uses an ephemeral 512 bit RSA key. Most servers have 1024
bit RSA keys but it used to be forbidden to export programs which
could encrypt with keys > 512 bits, so you'd use a temporary 512 bit
key and sign it with your 1024 bit key.

Newer export clients were allowed to use 1024 bit keys so you
wouldn't see this and now the export rules have been (more or less)
repealed so newer clients should just do the normal handshake.

For more details, see section 7.4.3 of the TLS standard.

-Ekr

[Eric Rescorla                                   ekr@rtfm.com]
author of "SSL and TLS: Designing and Building Secure Systems"
Addison-Wesley 2000          http//www.rtfm.com/sslbook

Thus the answer is to use better testing tools.

The following tools use this 'ephemeral' key...(bad thing):

• Web Bench 3.0
• Web Bench 4.0 (however we are ordering a non-export strong key version which should arrive on 11/11/00)
• Rainbow's Rainmeter benchmark program

The following tools don't use this 'ephemeral' key...

• Microsoft Web Application Stress Tool: (however, it has other problems. It's performance degrades the longer the test runs, and on some machines [which turned out to all be non-win2000] it re-uses the RSA-exchanged key even when we tell it not to)
• OpenSSL.exe with s_client parameter: however, this isn't a very good stress tool because it doesn't report results (yet, at least - we could modify the source)

The command line to run the server like this is...

openssl s_server -key privkey.pem -cert newcert.pem -state -accept 443

...where 'privkey.pem' came from as described under "Build a 1024bit SSL SelfSignedCertificate" on the ApacheSSLNotesShared page. (TODO: explain in better detail how I had to also sign the cert generated)

Note: for some reason, if you use the handy -www or -WWW parameters with s_server (which make it respond like a web server) openSSL won't echo out the cybersuite ( i.e the shared ciphers shown below)

The cryptographic parameters of the session state are produced by the SSL Handshake Protocol, which operates on top of the SSL Record Layer. When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets. These processes are performed in the handshake protocol, which can be summarized as follows:

The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello establish the following attributes: protocol version, session ID, cipher suite, and compression method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.

Following the hello messages, the server will send its certificate, if it is to be authenticated. Additionally, a server key exchange message may be sent, if it is required (e.g. if their server has no certificate, or if its certificate is for signing only). If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected.

Now the server will send the server hello done message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response.

If the server has sent a certificate request message, the client must send either the certificate message or a no certificate alert. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.

At this point, a change cipher spec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own change cipher spec message, transfer the pending to the current Cipher Spec, and send its Finished message under the new Cipher Spec. At this point, the handshake is complete and the client and server may begin to exchange application layer data. (See flow chart below.)

Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent SSL Protocol content type, and is not actually an SSL handshake message.

When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters) the message flow is as follows:

The client sends a client hello using the Session ID of the session to be resumed. The Server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a server hello with the same Session ID value. At this point, both client and server must send change cipher spec messages and proceed directly to finished messages. Once the re-establishment is complete, the client and server may begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID and the SSL client and server perform a full handshake.

-- MattWalsh - 02 Nov 2000