Is Sending Sensitive Data over HTTPS and Non-sensitive Data over HTTP Feasible?
Many people have wondered whether it is possible to send sensitive data over HTTPS and non-sensitive data over HTTP as a means of reducing the overhead caused by encryption. This blog post aims to explore the feasibility and security implications of this idea.
Question:
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 a protected channel, all others 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?
Answer:
Unfortunately, this idea is not feasible and poses significant security risks. Unencrypted data can not only be read by a man-in-the-middle but also modified. If even 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, rendering the entire encryption useless. This is why it is crucial to serve the entire website over HTTPS and not just the login page.
Additionally, the second idea of using different encryption algorithms for sensitive and non-sensitive data does not improve performance and raises similar security concerns as the first idea. The overall content is only as secure as the weakest link.
Furthermore, weaker encryption algorithms would not significantly enhance performance due to the complications they introduce in caching. While there may be slightly faster but less secure algorithms available, the marginal gain in performance would come at the expense of security.
Lastly, the implementation of separating sensitive and non-sensitive data would require significant effort and may not be practical in many cases.
Edit:
While it is possible to consider using faster but unencrypted TCP connections for sending real-time game data, this is quite different from the typical use case of HTTP webpages.