FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Actually is a big more complicated that what can appears. It's a
combination of settings on the server and on the client. To avoid
loading too much the server doing encryption the default setting make
the client turn to unencrypted after the encrypted login. You can
either disable the encryption at all or force the client to stay
encrypted.

Note that TDS log log data unencrypted even on encrypted connection.
If you increase verbosity you can see both crypted and unencrypted
data.

Frediano

2013/10/17 Marc Abramowitz <msabramo AT gmail.com>:
> Another oddity. I set "encryption = off" in freetds.conf and I turned on
> "force encryption" on the server.
>
> I was surprised to see that it successfully connected and appeared to be
> using GnuTLS at least for the login packet even though I set "encryption =
> off". This setting appears to have little or no effect, as far as I can
> tell? More likely is that I am misunderstanding how it works of course.
>
>
>
> On Thu, Oct 17, 2013 at 10:26 AM, Marc Abramowitz <msabramo AT gmail.com>wrote:
>
>> I've been playing around a little with encryption and confused by what I'm
>> seeing.
>>
>> At first, I set "encryption = required" in the freetds.conf file and I
>> would try to connect with tsql and the connection was made totally in plain
>> text. Is this a bug? Shouldn't the connection fail because "encryption =
>> required" was specified and it wasn't able to establish an encrypted
>> connection?
>>
>> After rebuilding FreeTDS with GnuTLS support, things got a little better.
>> Now I could look the the tdsdump and it looks like the login is happening
>> encrypted, but then there is something in the dump about
>> SSL_Self_Signed_Fallback:
>>
>> packet.c:581:Received packet
>> 0000 12 01 02 69 00 00 00 00-16 03 01 02 5c 02 00 00 |...i.... ....\...|
>> 0010 4d 03 01 52 60 0a 3d 3b-6e 06 c6 d2 11 c6 1a 4b |M..R`.=; n.ÆÒ.Æ.K|
>> 0020 5c 19 9f 5a 5a 7a 25 fa-0f 55 68 2d 90 29 64 54 |\..ZZz%ú .Uh-.)dT|
>> 0030 5e 98 f0 20 69 2e 00 00-79 8c fc e4 77 1c f6 e2 |^.ð i... y.üäw.öâ|
>> 0040 42 13 ba d7 99 90 97 ab-85 06 c1 44 31 df 86 f8 |B.º×...« ..ÁD1ß.ø|
>> 0050 e9 97 6d e5 00 2f 00 00-05 ff 01 00 01 00 0b 00 |é.må./.. .ÿ......|
>> 0060 02 03 00 02 00 00 01 fd-30 82 01 f9 30 82 01 62 |.......ý 0..ù0..b|
>> 0070 a0 03 02 01 02 02 10 67-95 12 c9 3f f3 37 a9 4c | ......g ..É?ó7©L|
>> 0080 8c 91 f1 e4 0b 17 bf 30-0d 06 09 2a 86 48 86 f7 |..ñä..¿0 ...*.H.÷|
>> 0090 0d 01 01 05 05 00 30 3b-31 39 30 37 06 03 55 04 |......0; 1907..U.|
>> 00a0 03 1e 30 00 53 00 53 00-4c 00 5f 00 53 00 65 00 |..0.S.S. L._.S.e.|
>> 00b0 6c 00 66 00 5f 00 53 00-69 00 67 00 6e 00 65 00 |l.f._.S. i.g.n.e.|
>> 00c0 64 00 5f 00 46 00 61 00-6c 00 6c 00 62 00 61 00 |d._.F.a. l.l.b.a.|
>> 00d0 63 00 6b 30 1e 17 0d 31-33 31 30 31 31 30 35 35 |c.k0...1 31011055|
>>
>> and then later on in the dump, I can see status messages and queries being
>> sent in the clear -- e.g.:
>>
>> packet.c:581:Received packet
>> 0000 04 01 01 89 00 3a 01 00-e3 1b 00 01 06 6d 00 61 |.....:.. ã....m.a|
>> 0010 00 73 00 74 00 65 00 72-00 06 6d 00 61 00 73 00 |.s.t.e.r ..m.a.s.|
>> 0020 74 00 65 00 72 00 ab 6e-00 45 16 00 00 02 00 25 |t.e.r.«n .E.....%|
>> 0030 00 43 00 68 00 61 00 6e-00 67 00 65 00 64 00 20 |.C.h.a.n .g.e.d. |
>> 0040 00 64 00 61 00 74 00 61-00 62 00 61 00 73 00 65 |.d.a.t.a .b.a.s.e|
>> 0050 00 20 00 63 00 6f 00 6e-00 74 00 65 00 78 00 74 |. .c.o.n .t.e.x.t|
>> 0060 00 20 00 74 00 6f 00 20-00 27 00 6d 00 61 00 73 |. .t.o.  .'.m.a.s|
>> 0070 00 74 00 65 00 72 00 27-00 2e 00 0c 53 00 4d 00 |.t.e.r.' ....S.M.|
>>
>> Querying sys.dm_exec_connections, the connection appears as unencrypted
>> (encrypt_option = FALSE).
>>
>> Basically, this is the same problem as:
>>
>> http://comments.gmane.org/gmane.comp.db.tds.freetds/12941
>>
>> I tried the suggestion at the end of that message and added this to
>> src/tds/login.c:
>>
>> // 2013-10-17 msabramo - hacks to try and figure out why FreeTDS isn't
>> using enryption...
>> login->encryption_level = TDS_ENCRYPTION_REQUIRE;
>> printf("*** %s:%d - login->encryption_level = %d\n", __FILE__, __LINE__,
>> login->encryption_level);
>>
>> login->encryption_level seems to be equal to zero even though I specified
>> "encryption = required". Setting it manually to TDS_ENCRYPTION_REQUIRE
>> didn't seem to help.
>>
>> Are these bugs that I'm seeing or am I confused about how things should
>> work? Maybe FreeTDS only supports encrypting the login packet and not the
>> whole encryption? Or maybe it doesn't work with a self-signed server
>> certificate?
>>
>> Cheers,
>> Marc
>>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds