Thread: SSL... too many tcp sessions...

All:

I work for an application-service provider.. sort of... anyway. One of our many applications is actually a TN3270/telnet application which has hooks into a microsoft DLL to tunnel/encrypt the user traffic over SSL. So on the network, we see encrypted packets destined to/from port 443.

This traffic hits a load-balancer that offloads the SSL encrypt/decrypt process.

We are having an issue where, it seems, everything a single user does (like just login, or pull up a VT100 screen) ends up launching 8-12 TCP connections. Over the course of a day 160 users launched upwards of 90000 tcp sessions. Each session is very predictable. its the same number of packets, and on the server side follows nearly the exact same sequence numbers every time.

We have many thousands of users that use this application. Needless to say, this is starting to cripple our load balancer.

Its my belief.. as an ex-programmer from a decade+ ago, that for the duration a user is logged into this app there should be a single TCP session.

Does anyone know why this might be occuring or if there is someway of fixing this? I am speaking in the broadest possible terms here because I am a network engineer, not a programmer. I will try to get more details if I can.

Derick
CCIE 15672

SSL is bloatware. Those extra sessions are for key exchange. You would be better off implimenting your own security if you have a mathematician on staff. There realyl is no way aroudn it unless you directly impliment the SSL yourself using the API functions. Going through a 3rd party DLL there is nothign you can do.

So.. I'm guessing that there are multiple passes occuring to InitializeSecurityContext (clienthandshakeloop), and instead of reusing the preexisting connection (I'm guessing by reusing the output-buffer pointer), we are launching a new connection for each exchange with the load-balancer that is doing the SSL offload...


Is that terribly far off? All 8 or so connections are launched in the same 100ms window. This would mean its the last of the 8 connections that does something useful.

Not all SSL stuff behaves this way, not even all Secure32.dll stuff, so I'm guessing its coded wrong.

Im guessing its coded wrong as well. It really shouldnt take more than a single session. Personally I impliment our own encryption routines. Its more secure and faster IMO.

You would be better off implimenting your own security if you have a mathematician on staff.

It could be more secure for you. Maybe. But telling some dude who is probably not an experienced cryptographer to replace a widely used and quite secure system with something they manage to invent is bad advice IMO.

Well then.

Since I originally posted, I have gained a great deal of clarity on what is going on with this app.

First, it is not actually tunneling tn3270 over SSL. It is, in fact, HTTP over SSL. So there is a front-end "option" that makes it look like TN3270, but when the user does a query or fills in the fields on the "screen" and hits send, its actually an HTTP Post that goes out. Users don't have to use the tn3270 screen option. In this case, its a web page with numerous elements. These elements each must hit the server querying for specific information or submitting specific information. All of this is done with HTTP posts.

They are using Wininet.

Essentially every query or transaction for each element results in a new TCP connection over which a single HTTP post is "executed." If an element refreshes... its a new TCP connection. All elements on all pages hit the same server with the same certificate.

Users who do not have publicly registered certificates... each transaction/query ends up being two TCP connections. This happens for unknown reasons, but a capture/decrypt shows the first TCP session there is a certificate/key exchange and then the connection is FIN'd straight away. Then the second connection is opened and the data is exchanged.

So a page with 5 or 6 elements may end up launching 10 or 12 TCP connections straight away to load all the elements.



Isn't this supposed to be what HTTP persistent connections are for? Couldn't they re-use the handle that is returned when they initially login to the server?

yes,they could, apparently they didn't. Welcome to the reality of programming.

Hey one last update..

To make a long story short, our programmers admitted to not implementing HTTP "persistent connections" as specified in RFC 2616, Section 8.1. See HTTP spec here.

So now they are moving forward with that. Also the double TCP connections for unsigned/unregistered certificates is a known issue with the WinInet DLL they were using, so they are abandoning it for winhttp.

The end!

Thanks for the replies. I bought a C programming book because all of this. I should read it one of these days.

Well, given that all programmers are usually working under unrealistic time constraints, you should feel lucky it works at all. I'm rewriting a class that took 2 months to write the first time, so of course the boss expects the rewrite to take 2 days because ' you can reuse the old code'. If the old code was worth reusing, we wouldn't be doing a rewrite, but whatever.