Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

i'm looking at implementing my own security mechanism rather than using ssl due to ssl being 'hopelessly broken' http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ and also because it is an interesting exercise :) This is for a client-server internet application. Caveat - i am not a security expert - just been reading up on security. I will also be building the client application therefore i will have control over the implementation both sides.

SSL Problem

The main problem with ssl I see is due to the swapping of public keys at the handshake stage, and a man in the middle intercepting this. SSL tries to avoid this problem using message signing and certificates etc to validate the server's public key to the client. But an attacker with a forged certificate can still get around this.


Due to this problem of safe public key exchange, i'm thinking this can be avoided by simply not having to swap the server public key, by having 'known' server public key built into every client application. Say a 3072 bit RSA key.


  1. The implementation for each communication session would thus be client generates a public / private RSA key pair.
  2. client encrypts it's new public key with server's public key and sends it to server
  3. server decrypts message to discover client's public key and then uses this to encrypt any responses to the client.
  4. client continues to send traffic to server encrypted with server's public key
  5. each message sent from the client also contains in the header:
    1. the client's username encrypted with the server's public key
    2. a hash of the un-encrypted client message - using as input to generate this hash, another hash of [client username + realm + client password]


  • Server can prove identity of client by first decrypting message using it's private key, and then calculating hash of the unencrypted message using the hash of [client username + realm + password] which it has stored in it's database.
  • Man in the middle cannot monitor traffic as it is encrypted both ways
  • Man in the middle cannot pose as client because he cannot generate a valid message hash
  • Man in the middle cannot pose as server because since he cannot decrypt initial message, he cannot discover client's public key in which to encrypt responses to the client
  • The client's password itself is protected against brute force scrutiny as the hash which used the clients password as input, is against the un-encrypted message, so attacker would first have to decrypt the message before beginning a brute force attack against this hash

Seeing as i'm not a security expert i am hoping if someone who know's more about security can spot any holes in this approach, or confirm if it is good. And also if a 3072 bit RSA key can stand the test of time without being broken.


share|improve this question

migrated from stackoverflow.com Dec 6 '11 at 19:33

This question came from our site for professional and enthusiast programmers.

Anything you implement before learning a lot more than "just reading up" will be orders of magnitude less secure than SSL. –  Matti Virkkunen Dec 2 '11 at 14:28
SSL might be "horrendously broken" but whatever you come up with will be even more broken. Count on it. SSL isn't perfect but it's good enough. DON'T REINVENT THE WHEEL. –  jathanism Dec 2 '11 at 14:28
What is the best way to shoot myself in the foot? –  Eugene Mayevski 'EldoS Corp Dec 2 '11 at 14:48
Voting to reopen - this was downvoted/closed because it's a terrible idea, not because the question itself is poorly phrased or off topic. It makes sense that other programmers having similar thoughts could find this question and see answers explaining why this is a bad idea. –  Martin Dec 3 '11 at 0:32
It is however a good question for security stack exchange –  Rory Alsop Dec 6 '11 at 19:18

3 Answers 3

You're confusing SSL/TLS with its most common usage pattern, which is TLS in conjunction with X.509 certificates and a Public Key Infrastructure (PKI, RFC 5280).

While it's really important to secure a TLS connection by authenticating its server site (to prevent active MITM attacks), the TLS specification doesn't actually mandate to do it using X.509 certificates, even less using a PKI.

As @jathanism said, you can choose not to rely on a hierarchical PKI, by using a self-signed X.509 certificate. You will have to establish trust in the server certificate by some other means.

In addition, TLS can also be used with OpenPGP certificates, Kerberos or Pre-Shared Keys.

TLS itself has had very few known bugs as far as I know, e.g. there was the renegotiation bug (CVE-2009-3555), which has been fixed (more recently, there were also certain issues with certain block ciphers, which can be fixed by choosing better cipher suites, or upgrading to newer versions of TLS).

The issues you're talking about (and often discussed in the press) tend to be related to PKIs, i.e. how to establish trust in the remote party. How this should be done isn't dictated by the TLS specification itself.

If you want to try to find a better way, by all means do some research, but I'd suggest focussing on this part and leaving SSL/TLS and the cryptography side of things alone. You'll probably find that the biggest problems regarding PKIs and their alternatives are administrative, not so much technical ones.

The other aspect of authenticating the remote party is to check you're talking to the intended party (i.e. host name verification).

share|improve this answer
thanks, that is useful information. –  DaManJ Dec 6 '11 at 23:18

If you have control of both sides, use self-signed SSL certificates. Done. You're not trusting a root Certificate Authority, and therefore your crypto becomes almost impossible to crack without internal knowledge of the architecture.

share|improve this answer
And thus SSL still wins the day. –  Jasarien Dec 2 '11 at 17:32
up vote 4 down vote accepted

I have decided to go with SSL as in the end it ended up being the simplest approach - the other idea just wasn't working well on the WCF side.

I have written this up on code-project to help others out having a similar problem.


I'd still need to figure out how to trust only my own public key and no CA keys - looking at the as3cryptolib it might be possible with the CAStore property on the TLSConfig - http://code.google.com/p/as3crypto/source/browse/trunk/as3crypto/src/com/hurlant/crypto/tls/TLSConfig.as

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.