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?
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!
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.
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:
- 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.
- 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.
- 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.
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.
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.
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
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.
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.
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.
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/
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.