Simple handshake for encrypted socket

I need to secure a socket connection between my client and server. Unfortunately SSL/TLS is not available on the client platform (so to those who would automatically answe开发者_如何学Gor "don't roll your own security": don't :-) ), and I need to build something myself. I've come up with this simple scheme (based on my small, probably outdated knowledge of SSL):

• Client connects to server
• Client generates a key for symmetric encryption
• It encrypts this with the public key of the server (which it knows since it's hardcoded in the program)
• It sends that key to the server
• The server decrypts it with its private key
• Communication begins, and is done in the form of messages, each encoded symmetrically.
• Each message includes a sequence number, so no two messages will be the same even if their actual contents are the same. (If this is not even neccessary, do tell, because leaving it out would make things easier)

As far as I can see, this is secure. MITM is impossible because he cannot decrypt the generated key. The client software itself is downloaded from an HTTPS website. The only "flaw" is that a sniffer can still see the amount and size of the messages that are sent, but that's not a problem.

What are your expert opinions?

I need to look into the specific encryptions to use (depending on what's available on the client), but I assume RSA and AES-256 are safe choices?

RSA and AES-256 are safe choices as long as you provide a long enough key.

Yes, that's the basic (simplified down) idea for SSL. As for the key lengths, AES-256 is fine for the symmetric, and RSA with 2048 should be fine at this time. Not sure how long the systems are expected to last, but you might want to consider how quickly encryption (increasingly larger) key sizes are being broken all the time. So that might be an issue with your idea of hardcoding, versus leaving this as user-specified.

I'm not sure why you'd want to hardcode the public-key in there. If it ever gets revoked, or they ever (for whatever reason) change keys, or if they want to connect to a different site using a different certificate, or whatever other things might happen, this might go from being a convenience to a bug pretty fast.

Have you considered elliptic curve encryption on the asymmetric side? Not sure what the client is, but ECC is getting popular (especially in mobile) since it uses significantly smaller key sizes than RSA and therefore requires less resources in processing.