If I have a website or mobile app, that speaks to the server through a secured SSL/TLS connection (i.e. HTTPS), and also encrypt the messages sent and received in-between user and server on top of the already secure connection, will I be doing unnecessary moves? Or is double-encryption a common method? If so, why?

  • 128
    One reason would be to utilize the highly effective double ROT13 encryption algorithm.
    – Keavon
    Commented Mar 15, 2016 at 23:02
  • 24
    You might want different levels of encryption - you want to encrypt the user's text message so that only the recipient can read it, and you also want to encrypt the protocol message that carries that, so only your server can read it. Commented Mar 16, 2016 at 4:37
  • 15
    Some legacy applications might have been using their own encryption on different channels than TLS long ago. When the developers convert them to TLS, they probably don't want to introduce new bug possibilities by removing the old encryption layer. Commented Mar 16, 2016 at 9:24
  • 3
    @immibis How can you apply ROT13 twice and pretend the text is encrypted? Commented Mar 17, 2016 at 7:33
  • 8
    @DmitryGrigoryev - that's an old joke about ineffective security for exactly the reason you're asking - it sounds good but is totally useless.
    – FreeMan
    Commented Mar 17, 2016 at 13:29

15 Answers 15


It's not uncommon, but it may not be required. A lot of developers seem to forget that HTTPS traffic is already encrypted - just look at the number of questions about implementing client side encryption on this website - or feel that it can't be trusted due to well-publicised issues such as the Lenovo SSL MitM mess.

However, most people weren't affected by this, and there aren't any particularly viable attacks against TLSv1.2 around at the moment, so it doesn't really add much.

On the other hand, there are legitimate reasons for encrypting data before transmission in some cases. For example, if you're developing a storage application, you might want to encrypt using an app on the client side with a key known only to the user - this would mean that the server would not be able to decrypt the data at all, but it could still store it. Sending over HTTPS would mean that an attacker also shouldn't be able to grab the client-encrypted data, but even if they did, it wouldn't matter. This pattern is often used by cloud based password managers.

Essentially, it depends on what you're defending against - if you don't trust SSL/TLS, though, you probably can't trust the encryption code you're sending (in the web application case) either!

  • 7
    Come to think of it, there's a reason to not jettison all those stackoverflow questions involving client-side web browser encryption in javascript. They render superfish and friends useless, and packaged corporate interceptors easily defeated (the problem converts to an arms race).
    – Joshua
    Commented Mar 15, 2016 at 18:06
  • 48
    If the HTTPS layer is compromised via a MITM attack, surely the client-side JavaScript encryption would be made... less secure.
    – wizzwizz4
    Commented Mar 15, 2016 at 22:22
  • 7
    If you work for a large company, your IT department may be intentionally MITM-ing your SSL connections -- several companies sell "SSL inspection" proxies -- this usually involves installing "compromised" root certs on corporate devices. These "inspection" tools wouldn't be able to do anything to compromise custom per-application encryption, however. Commented Mar 17, 2016 at 22:34
  • 1
    If you work for a large company and circumvent filters or traffic inspection, your IT department may come after you.
    – ASA
    Commented Mar 21, 2016 at 9:54
  • 1
    based on @FrankFarmer there is now also scope for malicious browser plugins to perform a MITM by replacing the XMLHttpRequest or Fetch Prototypes in the browser with there own sitting on top of the native browser versions and capture all input before sending to the browsers HTTPS handler or after the HTTPS handler has decrypted the data. Commented Apr 22, 2020 at 18:26

HTTPS only provides encryption while the message is in transit over the network/internet.

If the message is stored or processed by an intermediary (e.g. a message queue) at some point between the client and the server that finally processes it then it will not remain encrypted whilst it is in the intermediary.

Also, if the TLS/SSL is terminated at the service perimeters (e.g. on a load balancer) then it may not be encrypted on the internal network. This may be a problem where high security is required, for example in some regulated environments.

In both of these cases, message level encryption will ensure that the data is encrypted at all points in between the client and the final receiver.

As @honze said, this is called defense in depth and it is intended to ensure that even if a system is partially compromised (e.g. they manage to do a man-in-the-middle attack to compromise the SSL/TLS, or exploit a vulnerability in the message queue to get at the data at rest) the attacker cannot get at the protected data.

  • 19
    This seems a more clear answer about why you'd want to encrypt something sent by SSL. Commented Mar 15, 2016 at 19:37
  • 2
    Note to add: this also allows the client to control who is allowed to decrypt the final package. For example, with backups that are sent to a cloud. You wouldn't need to share the decryption key with the cloud provider, meaning even if the cloud provider is "hacked" or legally forced to divulge their data, then the client is still the only one with the keys.
    – NotMe
    Commented Mar 17, 2016 at 16:49

I'd like to share my experience on the title question. It's not really related to the complete question itself, but this answers the question "why would someone double-encrypt?"

In the past I worked for an organization that handles the communication between care providers (doctors, hospitals, etc.) and insuring organizations (mutualities). We kind of acted like a router.

The schema was roughly the following:

care provider 1 \                   / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 /                   \ insuring organization 3

We had the following protection:

  1. End-to-end encryption: Care provider 1 needs to send patient info to insuring organization 1. This info is privacy-sensitive and therefore needs to be encrypted. At our level we have no right to know what data is being sent to the insuring organization.
  2. Care-provider - router encryption: The care provider sends information as metadata for us to be able to handle it. This information needs to be encrypted. The contract stated that the messages still had to be encrypted even inside our network so that only one of our servers ever knows the metadata of the information being sent. Since we have several pipes (load balancers, firewall, etc.), encryption is required at this level as well.
  3. HTTPS to avoid MITM attacks: Not only did our data need to be protected, but the HTTP metadata needed to be protected as well, therefore HTTPS.

I hope this sheds some light on why several layers of encryption can be required.


You are right. This is a multi layer security concept known as defense in depth.

The encrypted messages are likely to address end to end encryption and the SSL/TLS addresses the encryption of the metadata. This is a useful pattern.

  • 1
    It does kinda answer the question, but it's a little thin for what I'm looking for in an answer... +1 still.
    – Lighty
    Commented Mar 15, 2016 at 9:21

HTTPS is encrypted in transit and decrypted at the ends. So the obvious situation where you might want to double-encrypt is where you don't want one (or possibly both!) of the ends to see the cleartext.

Some situations I can think of off the top of my head:

  • encrypted email through webmail providers. If I send a GPG encrypted message through Gmail which I access over an HTTPS connection, it's encrypted twice. Because I don't want gmail to read the contents.

  • encrypted backup services. I want to use HTTPS to stop my login credentials being stolen, but I don't want the backup service to see "inside" the backups.

  • payment gateways. You could imagine one where an encrypted message is sent between a secure payment hardware token and a bank, via a user's insecure device and a merchant's site. The link in the middle should be HTTPS, but that's not sufficient: it needs to be encrypted at the insecure PC and less-secure merchant's website.

Note that S/MIME provides for "triple wrap" (sign/encrypt/sign) : https://www.rfc-editor.org/rfc/rfc2634 , so if you consider signing as well as encryption even more possibilities may make sense.


I wanted to give an additional reason: Standardization.

I have an application that for security reasons, all data flowing into and out of it must be encrypted. Because it's already encrypted once, the data is permitted to flow over both http (legacy) and https (current) connections. It makes much more sense to encrypt twice than to create a version of the application that runs unencrypted over https and encrypted over http.

  • 3
    An argument could be made for desupporting the http protocol, however, maintaining ssl certs and current ssl software is tricky and has a lower reliability than http for our environment.
    – DKATyler
    Commented Mar 16, 2016 at 5:39
  • I understand your point, but someone who would make an Application where security is an important aspect, will force HTTPS, and disable HTTP, or in case of a web application, the HTTP pub would be empty, and only HTTPS would be supported.
    – Lighty
    Commented Mar 16, 2016 at 8:23
  • @Lighty Trust me, the real world doesn't operate on sensible principles like that. Reality leads to much harsher situations. Commented Mar 17, 2016 at 0:42

It is best practices when dealing with highly sensitive information such as financial, medical, military, or psychological data. The basic idea of multiple encryptions is to prevent any unauthorized user from retrieving the data. Suppose the initial possible combinations for the encryption method was 1 billion. By applying another encryption method on top of it, we could multiply the possibilities to 1b ^ 3. It would require an unauthorized user to take longer to decrypt the data. While the encryption is still not perfect, it is better.

At one of the organizations I worked at we utilized multiple encryptions. This is a simplification of the previous flow:

  • Audit both client and server devices and components for clearance over software
  • Encrypt the data on storage
  • Compress data
  • Encrypt data with proprietary software
  • Begin connection with server
  • Audit both client and server devices and components for clearance over connection
  • Compress transmission
  • Send data over encryption connection; If the connection is dropped, restart entire process.
  • Upon successful file completing, audit data for consistency

If you aren't dealing with an environment that is network heavy with sensitive data then this is overkill.

The strategy behind this method ensures that the devices, components (MAC), and IP have been authenticated. Encrypting data is standard procedure and so is sending over HTTPS. Some organizations go beyond the basic security and also require darknet-like networks utilizing Freenet, I2P, IPsec/VPN, or Tor to connect. Regardless of encryption, the data compression will reduce the required storage and network resources; however, it will offset your performance to RAM or processing. Finally, the reason we restarted the connection after a disconnect is we discovered a way to hijack the data stream via man-in-the-middle.

Ultimately, there is no perfect way to encrypt data forever, but focus your efforts to encrypting until the data or information becomes irrelevant or you produce a superior way to encrypt data.

  • 2
    Or you could just use a key that is twice as big. Commented Mar 17, 2016 at 1:15

There are a number of reasons for sending encrypted data over an encrypted connection:

  • even if the encryption of the connection is broken (e.g. MitM, possible but challenging with HTTPS, and leading to interception of all transmitted data), the data is still encrypted
  • the HTTPS server may not be trusted, and is responsible for relaying the data to another server
  • similarly, the HTTPS server may relay the data to another server over an unencrypted connection, and having the client encrypt the data before transmission reduces the load on the HTTPS server which would otherwise have to encrypt the data from all clients instead being able to pass it straight through

API obfuscation

Even if all communication is encrypted via HTTPS, the client can still have the option to see his traffic before encryption with various debugging tools. Especially if you use a browser environment or an app with https provided by an underlying system.

In this case you could encrypt your data with a static key, so the client can not easily read and manipulate the traffic. Of course this is only obfuscation, since the key needs to be stored somewhere on the clients machine (at least in RAM), but with software source code it is always just obfuscation. The user would have to spend some considerable effort to recover your key and decrypt your traffic to read an manipulate his requests.

Examples could be a web-based game, which submits the players high-score.

  • Or figure out how to access the game's admin/super-user methods.
    – Armfoot
    Commented Mar 17, 2016 at 12:10
  • A better method for securing APIs is authentication. If the user must be authenticated using a strong authentication system such (e.g. public key) before being able to use administrative features then the API doesn't need to be obfuscated. Similarly, features such as score submission can use a temporary "signature" (YouTube uses something like this) which must be generated at least once and passed with every request - while this can always be reverse-engineered, it can be made very complicated (and could even be based on the content of the request, making it different for every request). Commented Mar 17, 2016 at 14:03
  • @MichealJohnson this won't help at all, if you send authId=746788553 score=200 the user just needs to change the score value via man in the middle (easy on his own device) if you obfuscate, he will have a hard time
    – Falco
    Commented Mar 17, 2016 at 18:14
  • 2
    You also send signature=21a87c7b0a6005df838b17b9aafd0dc1, where signature is generated by an obfuscated algorithm (preferably changed every few weeks) from authId, score, and the current time. You don't have to obfuscate the transmission of the signature via a second layer of encryption, because even though the user knows it's a signature and knows it's value, if they change the score then the signature won't be valid anymore (because the score is used in the calculation) and by the time they've reverse-engineered the obfuscation the algorithm has hopefully been changed. Commented Mar 18, 2016 at 14:44
  • @MichealJohnson This is a really good point and will achieve the same benefit. - But your previous statement didn't fit this which must be generated at least once and passed with every request sounds more like a static value per session, your second comment is much better
    – Falco
    Commented Mar 18, 2016 at 16:09

The main reason for multi levels encryption is separation of concern.

Often a set of data may be processed by multiple servers, possibly controlled by multiple organizations, not all of whom are completely trusted with the entire data. In most cases, most of these intermediate servers only need to act on parts of the data, and so if they don't need to see some parts of data, that part can be encrypted. You'd give the intermediate access to the data they need to see encrypted in a key that they have and encrypted blob(s) they can pass on to other servers for further processing.

The simplest example is email with GPG and TLS encryption. The main job of a mail transfer agent (email relays) is to transfer email from one hop to the next. They need to see the mail routing information to do their job, but they shouldn't need to see the messages itself. Thus you'd double encrypt the email connection with one key that the mail transfer agent can understand and the message with another key that only the recipient understands.

Another example is calendar/notification scheduling service. You put events into your calendar, to be notified by your calendar application that something is happening at a certain time. The calendar had no need to know what the event is, who are involved in the events, nor where the event is.

A secondary reason for multiple encryption is as an insurance in case one of the encryption layer is broken. IMO, this is a much weaker reason because you need to consider that every unnecessary additional layer increases the implementation complexity and complexity is the enemy of security.


I don't see this mentioned here, but I think it's slightly more important than a comment. They might do that for perfect forward secrecy. An attacker might not know the key to your HTTPS connection, but they might record every single byte and store it for years. Then they may hack you down the line, discover a vulnerability, or compel you to reveal your server's private key later, then go back in history and decrypt your messages. By having a temporary ephemeral key encrypting messages underneath the HTTPS connection, the attacker would still be unable to read the messages, or at the very least significantly delayed.

  • That's not really double encryption, though; it's only (mostly) about how the session key is derived, agreed upon or shared. Basically, if the session key is derived in such a way that someone who has a complete record of the plain text of all the data that was transferred back and forth during the key exchange cannot later recreate the session key, then you have PFS; if someone with such a record can recreate the session key, then you don't. PFS is awfully nice to have, but it (potentially) solves a very different problem, as indicated by examples of untrusted intermediary endpoints.
    – user
    Commented Oct 7, 2017 at 10:51

If I understood correctly, the Tor network works that way:

Alice writes a letter to Dave and encrypts it three times: first with Dave's key, then adds Dave's address, encrypts the package with Craig's key, adds Craig's address and encrypts the package with Bob's key.

She then sends the letter to Bob, who decrypts it, and finds Craig's address, and forwards it to him.

Craig decrypts it, finds Dave's address, and forwards it to him. Dave decrypts it and finds that the letter is for him

In a perfect world, no one except Alice and Dave could now tell that Dave is indeed the recipient of that letter, because it COULD BE that he had found Emily's address inside the envelope and forwarded it.

A second application would be that you encrypt a message with both your private key and the recipient's public key. The recipient decrypts the message with your public key and his private key, and can thus obtain the information that the message is from you and for him. But usually, a HMAC is used to make sure the message is indeed from a certain sender and has not been tampered with.


Flaws in both algorithms and implementations likely exist right now, that have yet to be discovered. Ideally these flaws wouldn't exist but they do.

If you encrypt with two different algorithms and only one of them is flawed, you're still okay and your data is safe. If the first layer is broken, then an attacker is only able to get ciphertext. If the second layer is broken, an attacker is not able to get through the first layer.

Double-encrypting(or triple or quadruple or..) can be a good way to avoid putting all of your eggs in one basket.

  • 1
    You are assuming that the double encryptions don't interact in a way that means the combination is easier to break than either algorithm on its own. Do you have a proof of that? Commented Mar 18, 2016 at 9:02
  • @MartinBonner No, I don't
    – Shelvacu
    Commented Mar 18, 2016 at 9:25
  • It's seems a plausible assumption to me - but it smells of developing your own crypto algorithm (even if it is from well respected building blocks). Commented Mar 18, 2016 at 10:15
  • Yes, it is proven that combining two cyphers correctly will be at least as strong as the better of the two. If the passes are separate (not combined), a middle conditioning pass can be used to prevent "known plaintext" packet metadata from the outer cypher.
    – JDługosz
    Commented Mar 21, 2016 at 6:27
  • @JDługosz What is your definition of a cipher? Does ROT13 count?
    – Shelvacu
    Commented Mar 21, 2016 at 6:52

To avoid problems with PCI compliance, where the developer wishes to use payment gateway and puts the compliance onus on the 3rd party.

The fields in the form post can be encrypted client side, so the developer doesn't have any unencrypted card details pass through their systems (so a step further than not storing them).

Notably, this is on top of HTTPS. Thus the website doesn't even see the unencrypted data, only the user and the payment gateway.

Example with the Brain Tree payment gateway: https://www.braintreepayments.com/blog/client-side-encryption/

  • Why the -1? I've added a sample document to backup my case. Commented Mar 18, 2016 at 18:58
  • The form data can still be considered a "message". Commented Mar 18, 2016 at 19:00
  • I'm certainly not suggesting just client encryption! This is on top of HTTPS! Commented Mar 18, 2016 at 19:00
  • 1
    This is an example of quite a reasonable application, in fact.
    – Xander
    Commented Mar 18, 2016 at 19:08
  • Thanks @Xander yeah I'm guessing my answer was probably misread by people at first as just client side encryption (an obviously very bad thing!) Commented Mar 18, 2016 at 19:20

Not exactly HTTPS problem, but another valid use case of double encryption is in commonly used in Tor in case "I don't believe the delivery guy and want to stay anonymous by using more steps".

Every "delivery guy" decrypts only the envelope to find out the other delivery guy. The communication in this case is encapsulated and encrypted in SOCKS proxy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .