3

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?

  • 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
  • 2
    @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
  • 2
    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
  • 3
    "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
10

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.

  • 1
    HSTS Preload can help stop HSTS being Trust On First Use – jrtapsell Jan 28 '18 at 21:20
  • It reall yseemts I was undervaluing what HTTPS gives me. Thank you :) – Nico Jan 29 '18 at 6:33
  • What do you use for your authentication methods? Is it a PIN, a password, or a API key? Could it be brute forced? Have you give a thought about MFA methods? – Filipe Rodrigues Jan 30 '18 at 0:51

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.