FreeTDS Development Group

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

Jeremy Kister wrote:

> right, i can use TDSVER=8.0 with 0.63, but cannot with 0.82.  I have
> 0.63  and 0.82 on different hosts, so there might be other differences. 
> I  suppose I can install 0.63 on the host with 0.82 if need be.
> 
> http://jeremy.kister.net/tmp/tdsdump-0.63rc10.txt
> http://jeremy.kister.net/tmp/tdsdump-0.82.txt

Hmm.  It seems 0.82 detects an encryption flag during the prelogin that it
understands to mean "encrypt only the login packet".  The server then
drops the connection when it gets the login packet.  I would suspect a
problem at the SSL layer, either how we use the library or some
incompatibility between Microsoft's and the library we use.  

In both cases you're connecting to 204.11.57.12.  With 0.63, you proceed
with a normal connection.  With 0.82, you get:

        login.c:1000:detected flag 0

and the client starts encrypting.  Here's the code:

[=snip=]
/* if server do not has certificate do normal login */
if (crypt_flag == 2) {
        /* unless we wanted encryption and got none, then fail */
        if (connection->encryption_level >= TDS_ENCRYPTION_REQUIRE)
                return TDS_FAIL;

        return tds7_send_login(tds, connection);
}

/*
 * if server has a certificate it require at least a crypted login
 * (even if data is not encrypted)
 */

/* here we have to do encryption ... */

if (tds_ssl_init(tds) != TDS_SUCCEED)
        return TDS_FAIL;

ret = tds7_send_login(tds, connection);

/* if flag is 0 it means that after login server continue not encrypted */
if (crypt_flag == 0 || ret != TDS_SUCCEED)
        tds_ssl_deinit(tds);

return ret;
[=snip=]

Because crypt_flag is zero, you send the (encrypted) login packet, call
tds_ssl_deinit(), and return.  The rest of the session is not to be
encrypted.  But that doesn't matter: the first time the client attempts to
read the server's login response, it finds the server has already dropped
the link.  

I can only suppose it does that because it can't say anything else
securely.  If it can't decrypt the login packet, it can't encrypt a
reasonable answer.  It also can't send something "in the plain" both
because that would be understandable to an observer and because, after
all, the client is *expecting* an encrypted response.  

I think for now your best workaround is TDS 7.0 because it skips the whole
prelogin/encryption step.  Alternatively you could set your server not to
use any encryption; that would let you use the other TDS 8.0 features.  

Then if someone who cares about this feature can reproduce your results
(perhaps using your server) you may eventually see a patch.  

Thanks for the logs and the problem report.  

HTH.  

--jkl