0

An idea came to my mind about using encryption only for sensitive data while transferring data.

Here's an example: When opening a web page you can see a lot of stuff that's accessible to other users. But a small portion of information on a website is user specific which needs to be protected. You send and receive this data through protected channel, all other are redirected to normal channels (non protected).

With that we can have less overhead that's caused by encryption.

Is this feasible and secure? Has this already been done?

EDIT: I understand from the comments that using two channels is a bad idea. I got another idea: You secure the non sensitive data with computational less demanding crypto algorithm. With sensitive data you use computational more demanding algorithm which provides better security. The data is send trough a single channel.

Improve this question
7
  • 2
    Any information you send over HTTP can not only be read by a MITM attacker, but also changed. So generally, no, that is not considered secure, and most browsers will warn the user of that fact if you try to do things that way.
    – Ajedi32
    Jan 3, 2017 at 14:01
  • You have a point. Attacker can change lets say a link on a known website to a malicious website. What if you send a hash value of the site over protected channel and verify the integrity when it loads.
    – Tilen Kavčič
    Jan 3, 2017 at 14:09
  • @Ajedi32, you could post that as an answer.
    – Sjoerd
    Jan 3, 2017 at 14:15
  • 3
    This might make sense if the overhead was significant, but it's not - see istlsfastyet.com for some details on the level of overhead seen. You'd probably end up with increased overhead in administrating the split - turning on SSL is a one off job, but updating rules following changes in pages would be ongoing...
    – Matthew
    Jan 3, 2017 at 14:15
  • Setting up multiple connections would easily obliterate any moderate overheads - you'd be setting up two connections, that's twice the work. Actually, research shows that HTTP is slower than HTTPS troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage
    – iainpb
    Jan 3, 2017 at 14:19

2 Answers 2

Reset to default
6

This is a bad idea.

Unencrypted data can not only be read by a man in the middle. It can also be modified. So if just a tiny part of your HTML is unencrypted, an attacker can insert malicious JavaScript that reads the sensitive data once it is decrypted in the browser. Boom, the entire encryption is defeated.

This is also, by the way, why you need to serve your whole site and not just the login page over HTTPS.

As for your second idea, it doesn't really help anything with performance but have the same kind of troubling implications for security as your first idea. The content as a whole is not safer than the weakest link.

So why doesn't it help with performance? The main reason crypto can hurt performance is that it complicates cashing. Weaker crypto would not solve that. There might be some algorithm that is slightly faster than say AES-128 but less secure, but that would be a very marginal gain in performance that you pay for in terms of security.

And I haven't even mentioned all the work you would have to go through to separate the "sensitive" data from the "unsensitive"...

Edit: One should not be categorical... If you are e.g. programming a game you might want to send the realtime game data (who shoots what where) over something fast like unencrypted TCP, while you have a separate HTTPS connection for e.g. sending username and password to the server. But that is quite far from the HTTP webpage use case.

Improve this answer
4

Encrypting/decrypting/separating sensitive/not sensitive data in your application probably causes more overhead than HTTPS would anyways. Don't reinvent the wheel! In 2017, choosing TLS protection causes so insignificant overhead related to server or user bandwidth prices, that it's not even worth to mention.

Improve this answer

You must log in to answer this question.

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