7

Actually I got some projects from my ex-colleagues. These are App-Server TCP socket based applications. I noticed that some of auth/login interactions are using RSA/AES encrypt/decrypt

as I know, if we adopted TLS socket in transport layer, the data between us is encrypted.

so..if we use TLS, do we still need to encrypt/decrypt data in Application Layer Code? or it just a redundant effort.

  • 2
    OAuth2 specification specifically does not have encryption (unlike OAuth1) and instead specifies that it has to be used over a secure connection with transport layer security in order to be secure. I'm giving you this as an example that there are serious use cases that do this. Your own mileage of course may vary. – Andrew Savinykh Nov 2 '15 at 10:28
  • Encryption is a-given when passing private data along to machines that you do not control (i.e. the internet). If you have concerns beyond that, try to think about what sort of attacker you might expect (someone cold-booting the machine with a thumbdrive, you're using cloud services so you don't actually control the machines, etc.) and you can come up with specific responses. – Nick T Nov 2 '15 at 14:35
16

Yes and No.

Encryption isn't a "have it" or "don't have it" sort of proposition. The concept of encryption only makes sense in context.

As an example that should more obviously demonstrate the failure: Imagine you have a document that needs to be kept safe. You upload it to your Dropbox account. Now, is it encrypted?

Yes, it was encrypted in transit. Dropbox uses HTTPS, so it was encrypted using TLS during upload (and any download). It's then decrypted on the other side after it's been transferred.

Yes, it's is encrypted in storage (as far as we know). Dropbox says they encrypt all data on their servers using keys specific to your account. It's then transparently decrypted for you on demand.

But No, the document is not encrypted in a way that matters to you. Dropbox syncs the files to all your computers, and stores a plain text copy on your machine. So if anyone looks at your computer, they can read the document without having to circumvent any encryption at all.

When encrypting data, you have to figure out what you're trying to protect and whom you're trying to protect it from. You need to understand what you're trying to prevent with your encryption. Once you understand what you're trying to accomplish, it should be immediately obvious whether the encryption you have is doing you any good or not.

|improve this answer|||||
5

From a defense in depth perspective it could be useful to implement application layer encryption, depending on the classification of your data.

Imagine the following example: You're a bank and you use a REST API to retrieve balance information for a specific bank account. The API URL is:

https://www.bank.com/api/balance/12345678

The bank account number in this example is 12345678. Although your communication channel is encrypted, the bank account number can still be cached locally and will show up in web server log files.

This could be a good reason to have application layer encryption to avoid sensitive information being logged.

|improve this answer|||||
  • How could a proxy see the URL? – Siyuan Ren Nov 2 '15 at 11:47
  • GET requests are read by proxy servers as they pass on the request and therefore logged in the proxy logs. – Jeroen Nov 2 '15 at 11:51
  • @Jeroen-ITNerdbox URLs of HTTP requests are encrypted with HTTPS / TLS, so the proxy can't see it (unless both the proxy and the client are configured to make a MITM attack possible). Actually the URI part is encrypted, and the server part can be deducted from the IP adress or read from the Server Name Indication of TLS – LordOfThePigs Nov 2 '15 at 11:54
  • Anything transmitted in a GET request is not encrypted and is logged in web server / proxy logs. – Jeroen Nov 2 '15 at 11:56
  • 3
    @Jeroen-ITNerdbox Sorry, but no. That's not how it works. At least not with HTTPS (stackoverflow.com/questions/4143196/…) – LordOfThePigs Nov 2 '15 at 11:57
-1

First of all, SSL is neither a network layer protocol nor an application layer protocol. It is one that "sits" between both layers.

Second, because of its position, SSL gives the client machines the ability to selectively apply security protection on individual applications rather than set forth encryption on an entire group of applications.

The procedure can be done without concerning the network layer. For these reasons when SSL is used for encrypting network traffic, only the application layer data is actually encrypted.

So, all you need is HTTPS/SSL with client authentication. Adding a second layer of encryption doesn't actually add any security.

|improve this answer|||||
  • 3
    "SSL is used for encrypting network traffic, only the application layer data is actually encrypted." This is incorrect, the application layer data is not encrypted, it is the communication channel that is encrypted. – Jeroen Nov 2 '15 at 6:29
  • "to selectively apply security protection on individual applications" - that sentence does not say anything really... what's "security protection"? "The procedure can be done without concerning the network layer" - well, the most many applications see is TCP sockets, and you need to replace or tunnel those. "only the application layer data is actually encrypted"... and there's me thinking that it is transport or socket layer security. "So, all you need is HTTPS/SSL with client authentication. Adding a second layer of encryption doesn't actually add any security. " Life is not that simple. – Maarten Bodewes Nov 2 '15 at 20:29

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.