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

Question

Say I am writing a chat server and client that allows users to login with their user-name and password. Now I could just send and receive the information as plain-text but there is the risk that the information may be intercepted. So the socket should be secured to protect the user. 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. Neither am I interested in protecting subsequent messages that are sent/received. What is a good approach to take?

1. Can I replace a regular socket with a secure socket transparently?
2. Is there overhead associated with a secure socket that I might want to avoid for non-secret information messages?

I would prefer java pointers/examples, but interested in other languages also.

Answer 1

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

Answer 2

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.

Answer 3

"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.

Answer 4

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:

http://www.httpsec.org/

Answer 5

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.

Answer 6

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?