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

Originally Posted by mike_g

Its not an invalid argument. You suggested that they hire a coder to write a new encryption and authentication protocol. It would indicate that it would probably be closed source and insufficiently tested, and anyway why invent something new when there are plenty of well tested protocols that exist. Even Microsoft use open source encryption and authentication.

Just because its closed source does not mean it doesnt impliment a well tested algorithm, just that the company wont make it easier on potential hackers by telling them which algorithm. That's why I more or less disregard the opinion of anyone that claims you have to make your security open source to be sure its secure.

You really have to take things to extremes don't you

You are the one suggesting you dont hire people for complex projects because they might drop dead at any moment.

Death is unlikely, but possible.

Its also possible that a meteor will crush your entire company, o rthat a solar flare will wipe out your bank account. I can see now that the nitpicking result is probably what has happened to you before.

A more probable scenario may be that the coder ends up working for someone else, and is simply to busy to fix the problems or maybe even just cant be bothered.

Then you either downsized them, ........ed them off, underpaid them, or soem other management related issue. If you have soemone that has critical knowledge that yoru company depends upon, you dont just get rid of them, thats stupid and a waste of human capital.

Disagreements happen, and it doesent necessarily mean that anyone involved is emotionally unstable.

Disagreements that can only be resolved by the termination of current and future business relations DO NOT 'JUST HAPPEN'. Someone let their ego get in front of their intellect.

Again, you are taking a reasonable statement and turning it into a drama. Which is a sign of emotional instability in itself.

ad hominem, I win.

There is another issue with hiring one person to be the sole creator of your companies encryption/authentication, which is one of integrity. Whats stopping him/her from adding their own holes to subvert the system? It would certainly be a temptation. If the authentication is compromised, you may never find out - or at least until its too late.

What's stopping them? Oh if 5 to life and restriction from ever using a computer again for tampering with a computer system isnt enough then I don't suppose anything is stopping them. This isnt particular to security though, any programmer could add back doors to any piece of code. If you arent doing a thorough review of the code then that is the real problem, not the potential for abuse. If you can't understand the code then I guess we are back to your argument about 'dont hire smart people'.

This is going nowhere. I said what I have to say

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.