Thread View: de.comp.security
2 messages
2 total messages
Started by Roger Auinger
Mon, 02 Sep 1996 00:00
SSL: Client-Hello-Problems
Author: Roger Auinger
Date: Mon, 02 Sep 1996 00:00
Date: Mon, 02 Sep 1996 00:00
104 lines
3933 bytes
3933 bytes
Hi
I've captured a Client-Hello with my sniffer from Netscape 3.0 to a
server in two different ways. Our server is on isolated network, so
that anybody else couldn't access to the server. Because of this rea-
son I'm sure that I've captured the right packets from the Client-Hello.
first:
configuration in the Netscape browser:
SSL2 disabled
SSL3 enabled
RC4 encryption with a 40-bit key and an MD5 MAC enabled
RC2 encryption with a 40-bit key and an MD5 MAC disabled
No encryption with an MD5 MAC disabled
The client-browser is installed on a PC (pentium) with Windows 95.
In this case I've captured the following TCP-packet.
- - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - -
-
TCP: No TCP options
TCP: [33 byte(s) of data]
TCP:
ADDR HEX ASCII
0030 xx xx xx xx xx xx 80 1F 01 03 00 00 06 00 00 00 "8..............
0040 10 04 00 80 00 00 03 27 73 EA DD 24 53 06 1C F3 .......'s..$S...
0050 2D 71 EB FE C4 61 C5 -q...a.
The 33 bytes of data starts at Address 0036 and ends at Address 0056
(start-
and end-address included).
**************************************************************************
second:
configuration in the Netscape browser:
The configuration in the Netscape browser is exactly the same
as above.
The main difference to above is that client-browser is installed on a
SUN with SunOS 4.1.4
In this case I've captured the following TCP-packet.
- - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - -
-
TCP: No TCP options
TCP: [36 byte(s) of data]
TCP:
ADDR HEX ASCII
0030 xx xx xx xx xx xx 80 22 01 03 00 00 09 00 00 00 ..1...."........
0040 10 04 00 80 02 00 80 00 00 03 E8 0D 2B 8D 2F C3 ............+./.
0050 A1 1B 09 5B E9 C3 EF 2C EE 3C ...[...,.<
The 36 bytes of data starts at Address 0036 and ends at Address 0059
(start-
and end-adress included).
**************************************************************************
Questions:
Can anybody explain what content the value 0x80 on address 0036 has? The
value
occurres in both TCP-sequences.
Why I'm having to different numbers of bytes if I use two different
machines?
What could be the reason for this?
If I get a connection with the PC the content type is 0x1F on Address
0037
in the handshaking. I've nowhere found this content type in the SSL3
documentation. The content type if I connect with the SUN is o.k. !
Can anybody explain where I could see the Random (challenge[28 bytes]
+ gmt_unix_time[4 bytes]) = [32 bytes]?
In my opinion is this strange occurance not a problem of the server.
Thank's in advance
Roger Auinger
roger.auinger@itr.ch
http://www.itr.ch:8000/~rauinger/
Re: SSL: Client-Hello-Problems
Author: Juan Postlbauer
Date: Thu, 05 Sep 1996 00:00
Date: Thu, 05 Sep 1996 00:00
63 lines
3004 bytes
3004 bytes
In article <322AE9A8.3F54BC7E@itr.ch>,
Roger Auinger <rauinger@itr.ch> writes:
> Hi
>
> I've captured a Client-Hello with my sniffer from Netscape 3.0 to a
> first:
>
> configuration in the Netscape browser:
>
> SSL2 disabled
> SSL3 enabled
> RC4 encryption with a 40-bit key and an MD5 MAC enabled
> RC2 encryption with a 40-bit key and an MD5 MAC disabled
> No encryption with an MD5 MAC disabled
>
> The client-browser is installed on a PC (pentium) with Windows 95.
>
> **************************************************************************
>
> second:
>
> configuration in the Netscape browser:
>
> The configuration in the Netscape browser is exactly the same
> as above.
>
> The main difference to above is that client-browser is installed on a
> SUN with SunOS 4.1.4
>
>
> **************************************************************************
>
>
> Questions:
>
> Can anybody explain what content the value 0x80 on address 0036 has? The
> value
> occurres in both TCP-sequences.
>
Data says it's SSL3, but is encoded with SSL2 specification (I suppose the first message a browser sends dos this for compatibility with older servers?)
08 1F means "length expressed in 2 bytes, and equals 001F"
> wHY i'M HAving to different numbers of bytes if I use two different
> machines?
> What could be the reason for this?
The PC ciphers in the packet are RC2-128(40)-MD5 (NOT RC4)
The SUN ciphers are RC2-128(40)-MD5, RC4-128(40)-MD5
(Maybe not restarting browsers after setting configuration?)
The additional cipherspec takes the 3 bytes you ask for
> If I get a connection with the PC the content type is 0x1F on Address
> 0037
> in the handshaking. I've nowhere found this content type in the SSL3
> documentation. The content type if I connect with the SUN is o.k. !
As said above it's encoded with SSL2. 1F (and 22) express here a length
--
#include <std/disclaimers.h> my.opinions!=HP.opinions
if (dislike(contents)) {system("/bin/flame",">/dev/null")}
------ Juan Postlbauer ------
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads