A Netscape Server implementation error

[Andrew Roos <AndrewR@beetle.vironix.co.za>]

Hi Sameer

Thanks in advance for the T-shirt, and I like the Web site. On the   
subject of Netscape implementation errors, I note that the SSL protocol   
specification states in section 5.6.1 (CLIENT-MASTER-KEY) that "It is   
also an error if CLEAR-KEY-LENGTH is non-zero and the the CIPHER-KIND is   
not an export cipher".

However, I note that Netscape Commerce Server 1.1 will happily accept a   
"secure" connection using the non-export cipher SSL_CK_RC4_128_WITH_MD5,   
even if the CLEAR-KEY-LENGTH is set to 16 and the *entire* master key is   
sent unencrypted.

Here is an extract from an SSL session with www.netscape.com which   
illustrates the oversight:

 ------------------------------- Start of Session   
 ---------------------------

(1) The session was initialised as normal, and the following values were   
exchanged in the SERVER-HELLO and CLIENT-HELLO:

Challenge:
a2 ff 2e 94 8d f9 f4 e2 2c f6 bd ae 7f 47 db 6c

Connection id:
ef 47 3b 44 db d9 8d 1a f0 da 3e 14 73 97 a3 1f

(2) I then sent the following CLIENT-MASTER-KEY message, which is   
reproduced in full:

SSL Record Header:
80 9a

Message type: SSL_MT_CLIENT_MASTER_KEY
02

Cipher kind: SSL_CK_RC4_128_WITH_MD5
01 00 80

Clear key length: 16
00 10

Encypted key length: 128 bytes
00 80

Key arg length: 0
00 00

Clear key data: the *entire* master key sent in the clear
af 24 2e e8 2b b1 75 d1 27 a2 b8 76 8b 49 c3 f3

Encrypted key: this is a zero-length block formatted using PKCS#1 block   
type 2 and encrypted under Netscape's public key. Since it contains no   
data, an eavesdropper would not need to decrypt it in order to decrypt   
the rest of the session.

af 24 2e e8 2b b1 75 d1 27 a2 b8 76 8b 49 c3 f3
9b 9b 0b ff cd e8 2f 2c 0d 16 4e 90 73 26 4e e7
e0 3f 45 8a ce 9a 21 d6 2a 6b b8 9a 20 4e bc cf
d0 01 36 86 1c db e0 8b a8 e3 4c 9b 15 11 ea 95
b1 50 3f c9 42 9a 97 77 0f 9d 29 97 7e 87 1b 8f
77 b6 c9 c6 53 90 5b 74 4c 92 99 62 ad 8b bf 4c
28 ac 1b 11 32 64 56 c9 f0 d5 6f c9 89 6b 55 3f
b9 42 aa 7b 7c f0 a1 89 93 22 13 46 e2 58 63 23
b2 51 83 92 76 46 05 65 87 86 5b 52 5a d1 02 ee

(3) I calculated the session keys in the normal manner, using the master   
key which was sent entirely in the clear. The result was:

Client read key:
14 3e 84 a6 54 57 d6 51 94 cf 54 f5 5a 29 4a ef

Client write key:
9d e1 16 77 92 ee 89 f2 2d 30 c2 a2 e1 77 9f 5d

(4) Instead of disconnecting, the Netscape server sent the following   
reply (the header has been removed):

28 40 00 75 b8 d6 60 68 f5 cf ba 65 78 49 35 83
d3 3a b5 d3 81 23 2d f8 7d c6 f8 47 4d 0c 62 c3
b4

This was decrypted using the client read key to give the following   
SERVER_VERIFY message:

Message Authentication Code:
7b 95 2a 84 a1 55 fc 59 32 6b 53 ec e0 1d 80 4a

Message type: SSL_MT_SERVER_VERIFY
05

Challenge data (which agrees with the challenge sent in the   
CLIENT-HELLO):
a2 ff 2e 94 8d f9 f4 e2 2c f6 bd ae 7f 47 db 6c

(5) The negotiation phase of the protocol was concluded with encrypted   
CLIENT-FINISHED and SERVER_FINISHED messages as per normal.

(6) I sent the encrypted HTTP command "GET / HTTP/1.0" and received the   
following text (after decryption, stripping MAC and header, etc:

HTTP/1.0 200 OK
Server: Netscape-Commerce/1.1
Date: Tuesday, 19-Sep-95 21:15:23 GMT
Last-modified: Tuesday, 19-Sep-95 21:14:09 GMT
Content-length: 5278
Content-type: text/html

Followed by the Netscape home page, which included the following   
statement:

<A HREF="/newsref/std/random_seed_security.html">Find out</A> how   
Netscape is responding immediately to upgrade customers and minimize risk   
of future threats.

(7) Having obtained the warm, fuzzy feeling I so desired, I closed the   
connection secure in the knowledge that my secrets were safe with   
Netscape.

 -------------------------------- End of Session   
 -----------------------------

This shows that Commerce Server 1.1 is prepared to accept a "secure"   
connection which is completely insecure as the entire master key has been   
sent in the clear and an eavesdropper could decrypt the session without   
any cryptanalysis.

This does not mean that sessions between "well-behaved" browsers and   
Netscape servers are insecure, since the browser will send all 16 bytes   
of the key encrypted. Neither could it be used for an active attack,   
since if a new master was substituted for the one sent by the client,   
this would be detected during authentication of the SERVER-VERIFY   
message.

However, it would provide an opportunity for a malicious browser supplier   
to "doctor" secure browsers so that they sent all (or part) of the master   
key in the clear, even when using non-export ciphers. (Of course there   
are better ways to do this; the "random padding" of PKCS block type 2   
comes to mind).

Although this is not nearly as important a result as Ian and Davids, it   
is the first server hack, so can I have another T shirt?  :-)

Andrew
________________________________________________________________
Andrew Roos <andrewr@vironix.co.za>

// C++ programmers have class (but not much inheritance)

PGP Fingerprint: F6 D4 04 6E 4E 16 80 59 3A F2 27 94 8B 9F 40 26
Full key at ftp://ftp.vironix.co.za/PGP-keys/AndrewRoos