Is it possible/valid to have a TCP connection with secure login only, but non-secure messages?

This isn't a valid use case. Why authenticate, only to allow an attacker to step in and forge the information that is subsequently sent and received?

This isn't a valid use case. Why authenticate, only to allow an attacker to step in and forge the information that is subsequently sent and received? SSL isn't just for confidentiality.It also provides integrity: every packet that is exchanged is protected by a message authentication code so that a man-in-the-middle cannot alter the contents.

If the content lacks integrity protection, the connection is effectively anonymous. In that case, why bother pretending to authenticate?

I'm looking for a trade-off: there are messages that I don't want hacked - and there are messages I don't really care about. Perhaps my example should be a little more complicated like: "chat messages should be secured, but there is also a 'key pressed time-stamp' message which is sent frequently and is not critical so I want the least possible overhead for that". – Timothy Pratley Oct 19 '09 at 0:58 1 Most of the overhead in SSL is in the initial handshake.

The symmetric algorithms used after the handshake don't add a lot of overhead (you'd have to profile your specific application to see how big of an impact it has). However, if you do have a mix of secure and insecure traffic, it's probably best to have two separate channels... an SSL connection, and an insecure connection, maybe even using UDP for things like key-presses. Even though SSL avoid expensive handshakes when resuming an SSL handshake, the overhead of turning SSL on and off on one connection would be counterproductive.

– erickson Oct 19 '09 at 2:58.

You can use a hashed exchange, with each party sending a per-connection nonce (a one-time random value).

With C# it's easy to do. You would pass a normal unencrypted NetworkStream (which is the encapsulation of the TCP socket connection) as the parameter to an SslStream object. Once you've finished with the initial SSL transmissions you can simply close the SslStream and use the underlying NetworkStream for subsequent plaintext transmissions.

Login auth" is not enough, please think a case that the client is wrapped in a shell so it is able to login successfully and is able to inspect or send any malicious message because of clear message format and protocol.

The same is true for most SSL implementations ( as long as the shell has access to the key store and host resolution ). SSL gives you protection against man-in-the-middle between client and server, but assumes the client's environment is secure. – Pete Kirkham Oct 18 '09 at 9:01.

You seems need the RSA public key authentication which means that the username and password is encryped with server's public key. With a quick a google search, here is a http auth scheme may be referenced: httpsec.org.

Most systems which allow login this use a secure login without SSL by passing the hash of the password and some unique information from the server to prevent replay. Several best practices are encapsulated in SASL. I am not interested in certificates or verifying identity, I just want to make sure that the information supplied is not at risk of being exposed In that case you could encrypt just that information, though if you're not using it for identifying the user, and it can't be used in any further messages ( as they are sent in plain text ), why is it being sent at all?

Much of the cost of SSL is in the handshake creating the stream, so creating a temporary stream doesn't seem to be a good way of going about it, though the only way you'll know for your application is measuring it.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.