Because I don't want gmail to read the contents.Įncrypted backup services. If I send a GPG encrypted message through Gmail which I access over an HTTPS connection, it's encrypted twice. Some situations I can think of off the top of my head:Įncrypted email through webmail providers. 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. HTTPS is encrypted in transit and decrypted at the ends. I hope this sheds some light on why several layers of encryption can be required. 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.Since we have several pipes (load balancers, firewall, etc.), encryption is required at this level as well. 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. Care-provider - router encryption: The care provider sends information as metadata for us to be able to handle it.At our level we have no right to know what data is being sent to the insuring organization. This info is privacy-sensitive and therefore needs to be encrypted.
I'd like to share my experience on the title question. 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. 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.Īs said, this is called defense in depth and it is intended to ensure that even if a system is partially compromised (e.g. This may be a problem where high security is required, for example in some regulated environments. on a load balancer) then it may not be encrypted on the internal network. 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.Īlso, if the TLS/SSL is terminated at the service perimeters (e.g. If the message is stored or processed by an intermediary (e.g. HTTPS only provides encryption while the message is in transit over the network/internet. This pattern is often used by cloud based password managers.Įssentially, 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! 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. 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. On the other hand, there are legitimate reasons for encrypting data before transmission in some cases.
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. 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. It's not uncommon, but it may not be required.
0 kommentar(er)
