Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

SQLProxy and tds=8.0;ssl=request connection options

2013-10-31
2013-11-27
  • momo
    momo
    2013-11-07

    Why don't you just disable encryption? Of course there is no (reasonable easy) way of braking TLS, that is what encryption is all about. And if you would be able to compromise the driver by modifying it to dump network packets, than once again: why don't you just disable encryption if you have access to the client system?

    Maybe you'd better ask the NSA for help ;-)

     
    • Well, there is principialy no problem to either decrypt the connection or to inject a proxy which is doing man in the middle, because you can control what certificate the SQL Server is using and/or the client is accepting.

      This is quite usual for (Enterprise) HTTPS proxies. (But it would require SSL Server code which is currently not in the proxy stub I guess. Thats why it is not "easy" to add (in terms of work required not in terms of spy agency capacity).

      Depending on what you want to intercept it should be enough to turn off data encryption and have a look at the statements in a network analyser which can parse the protocol. (or you use client side trace logging or similiar. Without descreibing what exactly you are interested in its hard to give an alternative recommendation).

       
  • Hi:
    Only jTDS allows disable encryption.
    Clients using M$ SQLServer driver can't disable encryption :(
    Best regards, Marcelo.

     
  • Hi:
    I did some experiments doing a SQLProxy using Unix Netcat as:

    mknod pipe p
    nc -l 1433 0<pipe | nc localhost 2433 1>pipe

    then using Wireshark I captured the packet flow and a proxy using Netcat is working perfect because Netcat do not open TDS packet just simple copy in/out the TCP stream.
    The I captured the packet flow running net.sourceforge.jtds.tools.SQLProxy listening at the port 1433 and M$ SQLServer listening in 2433 port and I found that the first packets differs in the size of bytes, here the summary of the wireshark capture:
    traffic from SQLClient -> SQLProxy

    No. Time Source Destination Protocol Length Info
    4 0.000626 127.0.0.1 127.0.0.1 TDS 133
    TDS7 pre-login message

    traffic from SQLProxy to M$SQLServer

    No. Time Source Destination Protocol Length Info
    25 0.024131 127.0.0.1 127.0.0.1 TDS 125
    TDS7 pre-login message

    Note that the size of the packet differ exactly in 8 bytes so I think is something in the logic of DumpThread class.
    Best regards, Marcelo.

    PD: I working with this classes to provide on-the-fly alteration of the SQL between a client and server.

     
  • Hi:
    Finally I have the SQLProxy working with ssl=require|request options, also with the M$SQLServer native driver.
    The problem was an intermediate packet sent in TLS format, packet type 0x17 (23) which have the length information in different position:
    http://en.wikipedia.org/wiki/Transport_Layer_Security#Application_protocol
    Attached a new DumpThread class implementation which fix the problem.
    Best regards, Marcelo.

     
    Attachments