2
$\begingroup$

I need to send data between two applications. I've got requirement that says that data should be transmitted using secure protocol such as SSL/TLS. Data is sent using TCP sockets and I don't have built in SSL/TLS support. However, I'm able to encrypt content using AES and I'm also able to exchange small amount of data using https. I'm thinking of exchanging the key for symmetric encryption using https and then encrypt the data with AES before sending it over the network.

I'm in full control of both parties that exchange information. The keys are exchanged using SSL and I know that both parties are able to use AES. I guess there is no way anyone could decrypt the data without knowing the key. I agree that someone would be able to interrupt the transmission but it will be only noise since he would have to know the key to encrypt data with it.

Is this solution safe? Can it be compared to using SSL/TLS in terms of security? Is there some obvious security hole that I'm missing? Do you see any flaws in terms of security of the message (by it I mean that someone who is unauthorized sends his data as part of transmission or reads data from my transmission)?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Please give more information on the environment that does not provide a SSL library. You really should try to stick to well tested standards instead of inventing your own crypto. $\endgroup$
    – Hendrik Brummermann
    Commented Jul 4, 2012 at 20:48
  • $\begingroup$ I'm experiencing this issue in SilverLight. SSL at socket level is available in third party libraries. Since SilverLight doesn't support NetworkStream abstraction using third party library basically requires rewriting transport layer in my application. $\endgroup$
    – empi
    Commented Jul 4, 2012 at 21:04
  • 1
    $\begingroup$ You might want to consider writing your own I/O abstraction layer. Nothing fancy, just a bunch of simple and fairly high-level methods that will take care of your I/O needs and let you change the underlying transport mechanism in one place as needed. $\endgroup$
    – Ilmari Karonen
    Commented Jul 5, 2012 at 13:47
  • $\begingroup$ My method may inspire you crypto.stackexchange.com/questions/62218/… $\endgroup$
    – auxten
    Commented Sep 12, 2018 at 8:14

1 Answer 1

Reset to default
5
$\begingroup$

TLS not only provides privacy, but also authentication:

  • You can be sure you know who you speak to (at least the client knows if the server was using a certificate). (You provide this by the "HTTPS key exchange" you are doing at the start.)
  • You can be sure that you speak to the same entity at the other side throughout the whole live of your connection (even if you don't know who this is, e.g. as a server with non-authenticated client).
  • You can be sure that you get exactly what the other side sent, not something modified by someone between both sides.

AES (or any other block cipher) in a streaming mode (like CBC, CFB, OFB, CTR, ...) doesn't provide this guarantee. Because of this, there are various attacks at these modes which also endanger your privacy.

So make sure you are either

  • using a mode of operation which also includes authentication (look for "AEAD") or
  • using a normal privacy mode together with an external MAC (like HMAC) - and transfer the MAC key together with the encryption key during your key exchange).
Improve this answer
$\endgroup$
7
  • 2
    $\begingroup$ Also, if sending data in multiple messages, remember to include a sequence number to protect against message dropping or replay attacks. $\endgroup$
    – Ilmari Karonen
    Commented Jul 5, 2012 at 13:44
  • $\begingroup$ If add HMAC (e.g. Encrypt then MAC as described here daemonology.net/blog/2009-06-24-encrypt-then-mac.html) it should be safe in your opinion, right? Of course HMAC will use different key that would also be exchanged using https. $\endgroup$
    – empi
    Commented Jul 5, 2012 at 19:13
  • $\begingroup$ @empi: Yes, HMAC (with SHA-2 - don't use MD5) should be safe. Also, you'll likely have to partition your data stream in messages - then each of them should have a MAC (and a sequence number, and the MAC should cover both IV and sequence number). $\endgroup$
    – Paŭlo Ebermann
    Commented Jul 5, 2012 at 19:27
  • $\begingroup$ @PaŭloEbermann: Do I need sequence number if I'm sending data over tcp? I was thinking that my frame would like this: [messsage length][encrypted content][hmac]. If anyone would be able to insert segments into the tcp stream then it would be seen as noise that could potentially break the transmission (I'm not sure how the tcp library handles such case) but I don't consider it to be a security problem. What is important is that I could verify the message and it is not possible for anyone unauthorized to read the content. $\endgroup$
    – empi
    Commented Jul 5, 2012 at 19:51
  • $\begingroup$ @empi: TCP has no authentication build in, so it allows an attacker dropping messages or replaying previous ones (or inserting noise), as Ilmari mentioned in his comments. To prevent this, you want a message number in your crypto layer. $\endgroup$
    – Paŭlo Ebermann
    Commented Jul 5, 2012 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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