We are using SSL to make our connection between clients and backbone servers safer. Does it really make sense if also we use another encryption mechanism to encrypt transmitted data twice? For example, encrypt data by AES and then transmit data on an SSL connection?

  • 3
    Please expand your original question to better define your threat model and what you are protecting against. – user84662 Dec 30 '15 at 13:46
  • As an addendum to @iancnorden 's question, can you explain what you mean by ssl connection? Which version of ssl/tls are you using? Is this a web server/client? Are you using certificates on both sides (i.e. client authentication certificates, on one side (server certificate) or neither (yes you can actually do that)? – DRF Dec 30 '15 at 19:40
  • 1
    Agree with @iancnorden : whether a security measure "makes sense" depends on who your presumed attacker is. – Eric Towers Dec 30 '15 at 22:49

It really depends on what you're trying to protect.

SSL only protects data in transit, and between the two set points. It doesn't protect data at rest, and it doesn't offer any guarantee that the data came from the person claimed.

So if you need to protect the data while it's stored at either of the endpoints, then encrypting it might make sense. Or if you need to provide assurances that the data came from a certain party, then signing it might make sense.

On the other hand, if you're simply decrypting the data and storing it at the endpoint, and not doing any authentication, then it wouldn't make a lot of sense to add another transportation layer.

Security often works in layers, so it's important to understand what each layer provides. SSL is merely a transport layer, and only provides assurances that the data sent wasn't intercepted along the way, or replaced with something by an attacker in the middle.

  • SSL ... doesn't offer any guarantee that the data came from the person claimed - It does from the server to the client, doesn't it? – ispiro Dec 30 '15 at 18:41
  • 2
    +1 for describing cases which one may not think of unless one has given good thought to the threat model they are dealing with. – Cort Ammon Dec 30 '15 at 19:32
  • 1
    @ispiro It depends how SSL is being used. Without that extra information is actually quite hard to tell what the correct answer should be. Are we talking web servers and https? Are we talking mail server and imap? Or is this a proprietary client/server application architecture? Which version of ssl/tls is being used? etc. As a side comment if no authentication is used then you aren't making sure that the data was not intercepted in the middle. – DRF Dec 30 '15 at 19:35
  • This answer does a great job in pointing out the distinction between point-to-point and end-to-end security. If the data is going to be forwarded to some downstream service, then there are no guarantees on the data being protected from that point on. Encrypting and Signing the data would protect the data end-to-end. – Derek W Dec 30 '15 at 19:41
  • 1
    SSL does authenticate the origin of the data, if the origin of the data have a properly validated certificate. You can use mutual authentication if both parties need to authenticate each other. – Lie Ryan Dec 31 '15 at 7:41

Almost certainly, no, particularly if the client is a browser. One reason that SSL/TLS works, is that it is already embedded in clients. There's nothing to transmit in the clear that can be intercepted and modified by attackers in transit. If SSL itself is broken, then any encryption you send (such as JavaScript based encryption) can potentially be modified by an active attacker to make it impotent, or keys to the inner encryption scheme stolen by a passive attacker to make the data decryptable, and you've lost regardless.

So no, in the general case it is not worth adding complexity for no actual gain in security. There are cases where certainly implementations might in fact make sense, but unless you have a very strong argument as to why it make since given your specific architecture, the general case applies.


The established SSL/TLS protocols provide the ease of all important key exchange. The additional encryption layer you have proposed will of course increase confidentiality (one of the tenets of data security). However, arriving at what key that AES can use, will be another headache, especially when you expect the key to be changing for every session.

@Xander correctly points out that adding another layer of encryption will break client browsers. But you already knew that. By adding another layer, both client and server may need modification.

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.