HTTPS web service switched to HTTP. What can go wrong?

Question

I recently visited a website which used to have an HTTPS connection. Now it has just a plain HTTP connection, and the authentication method has changed from user+password to "authenticate with Google account".

I contacted them and asked them why they dropped the HTTPS, and they told me "because now the authentication is secure with Google, so it is not necessary anymore".

Well, I am not an expert in security, but before replying to them, I would like to know: what could go wrong?

So, with my little knowledge, I would say (correct me if I am wrong):

• Privacy loss in the communications between client and server (the attacker can read any information exchanged, and that includes personal information that the client may be posting to the server).
• An attacker could modify the client's requests, maybe with malicious intentions.
• An attacker could read the cookie and use it to get access to the service as if they were the client that originally authenticated using Google's services.

Am I right? What else could go wrong?

Answer 1

You are right, the regression to HTTP is pointless.

Note that all your points apply to one particular kind of attack, where the adversary is able to access the data transport between client and server. That could be the owner of a WiFi hotspot or your ISP acting as a man-in-the-middle, who sits in between you and the server. This can be hard to accomplish for a remote attacker, but is particularly easy on a public WiFi.

What HTTPS adds to HTTP is secure data transport. The web application itself can be completely fine - if you are communicating over an unencrypted channel, the attacker will be able to read, modify and inject arbitrary data into your requests and the server responses. With a captured session cookie, it will also be possible to impersonate you for as long as the cookie is valid.

What the attacker cannot do is take over your Google account or reauthenticate with Google at a later point. This is because the authentication with Google always happens over SSL and the granted token expires after a given time.

So the situation is somewhat better than capturing your credentials straight away. However, as you said, an attacker would still be able to take over the session and perform any action on your behalf.

Answer 2

I would raise the following question:

What's the point in having authentication in the application?

If all the page contains is public content and verifiable in an outside way (eg. a debian mirror, where packages are with PGP) and your users don't mind a third party scrutinizing what they visit, the page might not need https. But not a login either.

Common reasons for requiring authentication include:

• There is some data that the user can only read while logged in

• A registered user can send messages to other people

• It allows the user to gain reputation, by maintaining an identity that only used by him

• The account can receive some benefits obtained outside (such as accessing paid content)

All of them are defeated by using http instead of https in the communication, as well as almost any other reason for inserting a login. Regardless of the fact of the password not being exposed (which admittedly would be even worse).

Some time ago, the price of buying the certificates was argued, but nowadays there are several CAs providing certificates for free.

† Nitpicker's corner, there are a few, extremely rare cases where the security isn't compromised by this. An example is Mega, which loaded some common javascripts though http, but a https-loaded script verified their hashes before executing them. Fragile and more complex than setting up https everywhere. Don't try this at home, kids.

Answer 3

Your credentials are safe, but Session Hijacking might happen

One possibility could have been an attacker might have done a SSL Strip attack while acting as the Man In Middle, If that happens the HTTPS website will be served as HTTP to the victim. But as you have confirmed with the website that they have done it intentionally, so this possibility is striked off.

Now, Google uses oAuth2, so the handshake with Google will be over HTTPS & you will be redirected to your website over HTTP after that (it happens the very same way with https://security.stackexchange.com/ while you use your google account). You website would have generated a session token after oAuth. The risk HTTP posses in this case is an attacher can very easily hijack your session and surf the website pretending to be you

Answer 4

You are totally right. Excluding Google login credentials an attacker can perform a MITM attack and intercept all victim's requests. I suggest to you to communicate them the risks an reimplement the SSL protocol.

Answer 5

"What can go wrong": If you do that with an API, then all iOS applications designed for iOS 9 and running on iOS 9 using that API will stop working.

It's called "App Transport Security", and unless the developer creates an exception for your domain, http is not accepted, and https with not sufficiently secure connections is not accepted. Since your API used to use https, existing apps will not have an exception for your domain, so they will stop working.