FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> Has any work been done on deciphering the 0x12 packet types? 
> It appears
> to be what the query analyser 2000 tries to initiate a login 
> with to an
> sql server.
> 
> src/server/login.c says it's a pre-login, but I think it's an actual
> login attempt, and the client only falls back to 0x10 if there's a
> failure (eg an older version of the server.
> 
> Looking at the packet exchange, the first packet is 0x34 (52) 
> bytes long
> and appears constant except for two bytes (offset 0x30 and 0x31) which
> differ each type, and I think are encryption keys.
> 
> 00000000  12 01 00 34 00 00 00 00  00 00 15 00 06 01 00 1b ...4....
> ........
> 00000010  00 01 02 00 1c 00 0c 03  00 28 00 04 ff 08 00 01 ........
> .(......
> 00000020  55 00 00 00 4d 53 53 51  4c 53 65 72 76 65 72 00 U...MSSQ
> LServer.
> 00000030  60 09 00 00                                      `...
> 

is not constant

> The server then responds with an 0x04 response packet which 
> is 0x25 (37)
> bytes long and appears constant in all cases.
> 
> 00000000  04 01 00 25 00 00 01 00  00 00 15 00 06 01 00 1b ...%....
> ........
> 00000010  00 01 02 00 1c 00 01 03  00 1d 00 00 ff 08 00 02 ........
> ........
> 00000020  fe 00 00 00 00                                   .....
> 
> The client then sends another 0x12 packet, this time 0x4e 
> (78) bytes in
> length, and contains a heap of bytes which differ, even with the same
> password, which leads me to think that the two encryption 
> bytes earlier
> are used as a (cheap) encryption method.
> 

This is TLS incapsulated in TDS packets

> 00000034  12 01 00 4e 00 00 00 00  16 03 01 00 41 01 00 00 ...N....
> ....A...
> 00000044  3d 03 01 43 d8 3b 3d 61  53 c6 36 3f 26 3a f2 ca =..C.;=a
> S.6?&:..
> 00000054  7e d8 9a 3f 6e 55 d2 f4  16 1f 54 0e ee b7 a6 eb ~..?nU..
> ..T.....
> 00000064  e6 8f ea 00 00 16 00 04  00 05 00 0a 00 09 00 64 ........
> .......d
> 00000074  00 62 00 03 00 06 00 13  00 12 00 63 01 00       .b......
> ...c..
> 
> Then it loses me completely. The next response is 0x266 (614) 
> bytes long
> and contains a few instances of the server hostname (single 
> byte ascii),
> something that might be the serial number or product number of the sql
> server, and a whole lotta nonsense :). Most of it except for 
> about 0x3f
> (63) bytes are the same for different login attempts though.
> 

There should be that certificate here... try to post here (or directly
to me)

> The next few packets appear random in content.
> 

Probably crypted.

> Maybe it's a cryptographic challenge issued to the client so that the
> password is never sent over the network... seems a bit large for that
> though...
> 
> Thought?
> 
> Thanks
> 
> James
> 

http://cvs.sourceforge.net/viewcvs.py/*checkout*/freetds/freetds/doc/tds
_ssl.html?rev=1.5
And we implemented this some months ago...

freddy77