2
$\begingroup$

This might be in danger of being too elementary a question for this community but I'm hoping for expert help:

Assuming that TLS is not enough to protect messages transmitted between a client and a server, what is a good way to establish secure communication between a client and a server? In my case this is between a web server and a mobile app, with typical requests and responses between the two.

I have the following idea: Generate an asymmetric key pair, distribute the public key with the mobile client and keep the private key on the server. When initiating communication with the server from the client I could generate a symmetric key for the session, encrypt the key using the public key, send the encrypted key to the server which would then decrypt the symmetric key using the private asymmetric key, and then continue to decrypt requests and encrypt responses using the symmetric key.

Is this anywhere close to an acceptable solution, what are the nuances I should be aware of to achieve an acceptable solution? What algorithm choices should be made?

$\endgroup$
  • 2
    $\begingroup$ Please note very well: Chances are high that you can't design a full security protocol that will be better and / or more reviewed / secure than TLS. Note also that TLS allows you to pin your public key as well and you don't need a fully-featured certificate neccessarily. $\endgroup$ – SEJPM Jul 5 '16 at 18:41
  • 3
    $\begingroup$ Assuming that TLS is not enough, OK, but which version/ciphersuite would not be enough and why wouldn't it be enough? We cannot give a hint on how to secure things against unknown attack vectors. I've voted down for this reason, will remove the vote down if you can name an attack vector that you're trying to protect against. You can always use TLS 1.3 (draft) if you think 1.2 is not enough. $\endgroup$ – Maarten - reinstate Monica Jul 5 '16 at 18:47
  • 1
    $\begingroup$ @MaartenBodewes I don't have a good reason to believe TLS is not enough but its an assumption I want to make for the purposes of finding a solution to the mandatory security requirements (necessary or not) to further encrypt requests and responses between client and server. Also I want to extend the solution to a real scenario where the first server (in the cloud) is just going to pass messages on to a second server (behind a corporate firewall) and we don't want the first server to be able to know the content of the messages. $\endgroup$ – Matthew Jul 6 '16 at 7:37
3
$\begingroup$

Your idea lacks forward secrecy, which protocols like TLS often (in newer versions anyway) offer. Otherwise it is close to how such things are usually done.

To get forward secrecy you would instead use an ephemeral Diffie-Hellman key exchange, which you would authenticate with the pre-shared public key (which would be a signing key, not an encryption key, where that makes a difference).

There are several alternatives for algorithms, but basically you should... do what good TLS cipher suites do. E.g. ECDH or EDH with either ECDSA or RSA signatures. AES-GCM would be a good default choice for symmetric encryption.

$\endgroup$
2
$\begingroup$

As no particular attack scenario has been given I'd add another, more high level option.

When point-to-point transport security isn't supposed to be secure enough then you might consider end-to-end message security or application level security as well.

The idea of TLS is that it protects messages from client to server. However, the client and the server are not always the endpoints of the information; for instance an SSL offloader may be used. Furthermore, messages may be buffered or stored for further processing. TLS only protects messages in transit. TLS keys may also be less secure than application level keys, e.g. when a TLS key is used for generic security of multiple connections.

So, for instance, you could use the Cryptographic Message Syntax to encrypt-and-sign (certain) messages send through the TLS connection. Obviously it would be nice to make certain that the messages and the message protocol are secure even when the TLS connection was negated by an attack.


Note that - for instance - web services (WS-security) already has an option to perform both transport and message level security. It's of course up to you if you trust that enough or that you want to use your own protocol. I've opted to generate my own implementation before (due to missing security reviews), but usually it is better to trust a well maintained, existing library.

$\endgroup$
  • $\begingroup$ Thanks for your suggestion about Cryptographic Message Syntax, I'll prototype a solution with that in mind. $\endgroup$ – Matthew Jul 7 '16 at 8:53
1
$\begingroup$

As an addition to the other answers: there are indeed multiple solutions available to you that do not rely on designing your own encryption-scheme and code. This is of importance as it is very easy to make mistakes on both the scheme and the implementation level. You might for example be able to take a certain (trusted) algorithm which should be safe and implement it in a way that circumstantial evidence (such as computing and response-times) leaks information that makes the connection less secure.

Without a deep understanding of both the algorithms and their implementations, I would thus opt for a tested solution.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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