Hi:
I am working in a kind of interceptor for MSSQLServer messages and want to see the traffic between a client and SQLServer 2000+.
The SQLProxy class at the tools directory is great but it doesn't work with connection options like "tds=8.0;ssl=request" which enables TLS encryption.
If anybody can help me on how to modify the SQLProxy class or have a modified version to dump packets with TLS enable it will be great.
Best regards, Marcelo.
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 ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Hi:
I am working in a kind of interceptor for MSSQLServer messages and want to see the traffic between a client and SQLServer 2000+.
The SQLProxy class at the tools directory is great but it doesn't work with connection options like "tds=8.0;ssl=request" which enables TLS encryption.
If anybody can help me on how to modify the SQLProxy class or have a modified version to dump packets with TLS enable it will be great.
Best regards, Marcelo.
PD: MSSQLServer JDBC driver also always works in TLS mode so I can't see the information :(
http://blogs.msdn.com/b/jdbcteam/archive/2008/09/09/the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption.aspx
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:
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
traffic from SQLProxy to M$SQLServer
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.