FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

"ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com> wrote:
> > I'm working on this (sometimes I like to play with bits :) ). 
> > Some bits left but mainly it's ssl...
> 
> Catched: 
> 
> Now prelogin packet (tds 8.0 only)
> 
> client to server 
> 
> 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 01 4d 53 53 51  4c 53 65 72 76 65 72 00 U...MSSQ
> LServer.
> 00000030  38 09 00 00                                      8...
> 
> 00 00 15 00 06 netlib version (0) start from 0x15 length 0x06
>   8.341.0
> 01 00 1b 00 01 encrypt flag (1) start from 0x1b length 0x01
>   1, see below
> 02 00 1c 00 0c instance name (2) start from 0x1c length 0x0c
>   "MSSQLServer\0"
> (\0 padding ???)
> 03 00 28 00 04 process id (3) start from 0x28 length 0x04
>   0x938 (why in little endian ??)
> ff             end
> 
> Meaning of encryption flag (client):
> 0x00 normal
> 0x01 high encryption (128 bit ??)

[much interesting stuff omitted]

> With force login (0x03 from server) after crypted login packet server
> and client continue to keep encrypting full packets

Cool!  

Maybe Steve Langasek would have LGPL ssl information.  Otherwise, a
configure option that pulls in openSSL would be OK.  Most people don't
want encryption, so for them FreeTDS would continue to have basically no
dependencies.  

--jkl