66

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?

  • 97
    The people running that site are extremely incompetent. – André Borie Apr 18 '16 at 18:14
  • 54
    "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"." - an example of security by buzzword compliance? – user253751 Apr 18 '16 at 22:00
  • 1
    Glad they didn't use HSTS.. – Rubber Duck Apr 19 '16 at 2:35
  • 11
    @RubberDuck If they did that it might have forced them to keep HTTPS support. ;-P – Ajedi32 Apr 19 '16 at 14:39
  • 8
    as a side note, there really isn't much good reason to still use plain http for anything, these days. – njzk2 Apr 19 '16 at 15:34
94

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.

  • It's a hijack for sure - no doubt! Try to verify it via Tor and/or I2P - try to connect via theese tunnels. If there will be a HTTPS as usual - then start investigating but fortify your connection first, try to set up a Tor router – Alexey Vesnin Apr 20 '16 at 14:20
23

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.

  • 1
    Even paid certificates can be had for nearly nominal amounts, if for some reason you want to pay (if only to have someone to yell at when things go wrong). It isn't difficult to find basic DV certs in the sub-$10/year/fqdn range, or tack on maybe an extra zero if you want something like a wildcard cert, and for anything where you'd even consider HTTP, DV HTTPS is perfectly sufficient. – a CVn Apr 19 '16 at 12:15
  • 2
    Using http:// rather than https:// can make things more convenient for users behind captive portals. A public WiFi gateway can redirect the first http:// request from a given MAC address to a terms-of-service page, but an https:// request will simply go to an error screen without indicating to the user the need to agree to the terms of service before using it. – supercat Apr 19 '16 at 16:53
  • MEGA "hash verification" is pointless: it load everything via HTTPS, as loading HTTP resources from HTTPS is blocked or, at least, raise warnings. Just desktop clients and extensions do HTTP requests, and just to download the encrypted files, as those don't need to download JavaScript files. – Gustavo Rodrigues Apr 19 '16 at 18:48
  • I can make an educated guess what website(s) inspired you to the third item (reputation collecting) - but they still at least allow the use of HTTP, don't they? – Hagen von Eitzen Apr 19 '16 at 21:20
  • @HagenvonEitzen I was actually thinking in a classical forum, but that page is indeed affected. In fact, any page where users register and communicate between them is. – Ángel Apr 19 '16 at 22:59
8

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

  • Stack Exchange offers HTTPS for all non-meta sites. (Meta is more complicated because of the domain name structure; should have gone with security.meta.stackexchange.com rather than meta.security.stackexchange.com because then it could have been handled largely by *.stackexchange.com and *.meta.stackexchange.com.) I think EFF's HTTPS Everywhere gives you HTTPS by default for all Stack Exchange main sites. – a CVn Apr 19 '16 at 12:18
6

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.

0

"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.

  • Well, I was asking for "what could go wrong" in security terms. If this web service stops working that is not really a security problem. But yes, of course clients and third party applications may stop working (don't know what iOS has to do with this, though xD). – Peque Apr 21 '16 at 10:00

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.