6

Let's set up the environment before coming to my question.

  • We have an web application which will be accessible by browsers/clients over HTTPS.
  • Monstly only accessible in the intranet ( rarely over the internet )
  • Frontend using Angular
  • Backend using Java-EE

Now I came to an argument with my colleagues over an concern of mine.

The communication between the frontend and backend is completely unencrypted, resulting in the credentials of a user logging in send over the intranet/internet completely clear text. Also they will enter sensitive data which is a secret of the company (ingredients, proportions, etc.).

Adding the fact we integraded LDAP Login possibility to our application this fact seems highly risky to me, possibly resulting in an entry point to gain more informations off the intranet (getting LDAP credentials and accessing more services and machines).

My colleagues said thats nothing to worry about since the communication between client and server is established over HTTPS.

However they couldn't convince me with only providing that one single argument at all, especially since there are known problems like SSL Stripping, MITM, or even traffic analysis. I know that I should only worry about those if we don't configure everything correctly, but thats also a concern of mine.

I am on the point that we should encrypt the communication betweeen client and server additionally with something like Jose4J. That would ensure that even in an intranet breach or HTTPS Problem the sensitive data would still be a secret. It would also be more hard to analyse the traffic.

Now I wanted to get an answer which provides more facts and a better conclusion than only "but we are using https".

Is only using HTTPS for an web application dealing with sensitive data "secure" enough?

Anders
  • 64,406
  • 24
  • 178
  • 215
Nico
  • 499
  • 1
  • 4
  • 12
  • 1
    I agree with you and recently dealt with similar issues but only in regards to passwords. For passwords best practice would be conduct both client and server side hashing. Use the username as salt on client side and hash for as many rounds as you can before creating a performance issue, then transmit this hash over HTTPS and have the server complete many more rounds of hashing. This way if the traffic is ever sniffer (via breaking HTTPS) at least the clear-text password doesn't leak. – dFrancisco Jan 24 '18 at 14:30
  • 1
    This document ( https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf ) shows how often TLS gives a false impression, specially outside of web browsers and human interaction, because of a mix of human errors, bad documentation, eagerness to go fast instead of checking things, etc. It at least shows that just activating TLS is not enough. It has to be taken seriously in the code too. – Patrick Mevzek Jan 24 '18 at 16:45
  • 3
    @dFrancisco: do not invent new methods, for passwords, you have PBKDF functions, and the newer kids on the block like `argon` or `scrypt`. Never use the username as salt! A salt should be a random value. – Patrick Mevzek Jan 24 '18 at 16:46
  • @PatrickMevzek I never said to, personally I always use the PBKDF family of functions. Ran out of space in the comment so never specified the algorithm to be used but a simple google search can bring up all the necessary info to compare and contrast available hashing algorithms. – dFrancisco Jan 24 '18 at 16:50
  • 3
    You say the client to server communication is completely unencrypted, but then you say it goes over https. Which is it? – Xiong Chiamiov Jan 24 '18 at 17:12
  • 1
    Also, what is your threat model - who are you trying to protect against? – Xiong Chiamiov Jan 24 '18 at 17:13
  • @XiongChiamiov sure the traffic generally is encrypted because of using HTTPS. My concern was the traffic itself from client to server inside the https layer. For example a JSON containing a username and password will be transmitted clear text from the browser to the server. That is my concern. Shouldn't all requests itself ( the json ) be additionally encrypted with some library like Jose4J to gain higher security. Out threat model is espionage (e.g: secret ingredients), sensitive user data ( ldap passwords, etc) and using our application as an entry point for further damage in the intranet. – Nico Jan 25 '18 at 07:17
  • 5
    "For example a JSON containing a username and password will be transmitted clear text from the browser to the server." -- No, it will be encrypted with TLS via HTTPS. – Xiong Chiamiov Jan 25 '18 at 17:55

1 Answers1

19

The communication between the Frontend and Backend is completely unencrypted, resulting in the credentials of a user logging in send over the intranet/internet completely clear text.

...the communication between client and server is established over HTTPS.

You are contraditcting yourself. If you are using HTTPS, your data isn't unencrypted.

...especially since there are known problems like SSL Stripping, MITM, or even traffic analysis.

SSL stripping is solved by HSTS. Use it. A MITM is exactly what TLS protect against, so I fail to see how that is a "known problem". Not sure what you mean by "traffic analysis", but implementing your own application level crypto is not going to solve it.

I think you are undervaluing what HTTPS gives you.

Is only using HTTPS for an Web application dealing with sensitive data "secure" enough?

What your question basically boils down to is this: Is transport layer encryption enough, or do I need application layer encryption as well?

For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.

And anyway: You do not trust yourself to configure your own TLS. Why should you trust yourself with the much more complex task of setting up safe application layer crypto? I promise, it will be much easier to just read up on TLS and do that right.

Your collegues provided you with only one argument, because it's the right argument. Use HTTPS.

Anders
  • 64,406
  • 24
  • 178
  • 215