Plain web text offenders: sending my location over HTTP when HTTPS was possible | Hacker News Reader

Plain web text offenders: sending my location over HTTP when HTTPS was possible

blog.jgc.org

92 pointsjgrahamc34 comments

'Perhaps "This app would like to use HTTP for its API" should be a permission that the user has to explicitly give.'

Good idea.

Chances are the app is doing a NSURLRequest and the OS can't tell if it's an calling API some other HTTP(S) request.

Unless internet access is segregated into the following it's fairly meaningless:

  This app would like to use HTTPS
  This app would like to use HTTP
  This app would like full internet access

From a security point of the view the app realistically should also pin it's certificate as well - the app developer knows the certificates that the app should expect to prevent Charles proxy working.

It needs to be more obvious than this... the average non-technical user isn't going to understand the ramifications of this verbage without training - even as minimal as that training may be.

- This app would like to transmit secured data over the internet.

- This app would like to transmit unsecured data over the internet. Transmitting unsecured data could result in it being intercepted by unauthorized third parties for unintended purposes such as monitoring or tracking of your communications or identity theft. This information could also be used to gain unauthorized access to your devices or accounts.

Of course, even if it is secured... it could still be used for such by anyone who can acquire the private key of the server, then you're pretty much hooped.

I guess ultimately, it just needs to warn the user that data is being communicated with the internet. It's probably being tracked and monitored by someone and probably not for the purpose the user intended. Use with caution.

I suspect it is unlikely that the average user would understand the ramifications of agreeing to that request though. How about "This app would like to send your location to its API insecurely"?

The OS does not know what data the app is sending to its API, so it couldn't provide this specific of a warning.

An average user doesn't know what an API is.

Or better still:

"This app would like to send data over the internet insecurely."

There would be a nice stampede to get SSL coverage for API endpoints if we called it what it really is.

Wait until people find out how many of their emails travel in plain text.

Yup. I wrote about this for CNET in 2013:

http://www.cnet.com/news/how-web-mail-providers-leave-door-o... "A survey of top mail providers shows that Google is alone in using strong encryption, known as SMTP-TLS... Facebook, Hotmail, Yahoo Mail, and AOL Mail do not accept incoming e-mail in SMTP-TLS encrypted form..."

I hope things have improved since. (Some enterprising journalist might want to do a followup.)

One issue is that HTTPS is one more thing to manage (no, it's not a complex thing to manage, but it is something). It's too easy for certificates to expire; it's psychologically irksome to pay the CA tax. I've seen many, many SSL expirations over the course of my career; far more than there should be, of course. Somehow we've ended up with a business culture which can track the number of left-handed albino Eskimos in middle management positions, but can't track certificate expiration dates.

I don't know off the top of my head if it's possible to package two certs into one, so that one could have a certificate signed by one's own trusted root for one's own API client to trust, and a certificates signed by a CA for web browsers to trust, but that might make folks feel better about using it for an API endpoint: the own-trusted-root might have a different expiration period (risky), or an automatic renewal, or whatever. At the least it'd be self-managed to the point that the technical staff could handle it, rather than having to work through purchasing.

This is a problem because the certificate handling is not in the hands of process managers, but in the hands of the sysadmins, who do not generally work on a rigorous business-cycle type of schedule, and who don't already have tools in place to keep track of such things, and have a hard time justifying creating a tool that would, assuming they just have one or two certs to manage, be used only once every two years (and thus would probably take four years to troubleshoot, by which point something about the assumptions would have changed, meaning the reminders/warnings would probably fail and the cert will get overlooked).

It does make me wonder, though... why don't web servers have options to warn their admins (via logging or email or what-have-you) that the certs they are using are near expiration? Or do they?

Alternatively, some good samaritan could set up a service to scan the known SSL web for near-expired certs and email webmaster@ or other scraped addresses of the issue.

I'm sure that there's quite a few companies who can do the same using only your IP address (hence also via https) and getting your location at the accuracy of real world coordinates.

And no, I'm not talking about using geoip information, I mean using data bought through 3rd parties selling location data collected through $yourfreeinstalledapp.

Humble opinion: It is easy to block apps from sending sensitive information over the internet by running your own DNS cache and root along with a packet filter.

Humble opinion: If someone really wanted to send sensitive information over the internet, they could do better than HTTPS. Moreover, in the event the user is curious what is being sent, doing an experiment like the one here with a proxy becomes unnecessarily more complicated when the app is using HTTPS.

Humble opinion: Anything that makes it more difficult for the user to see what information an app is sending is not in the user's best interests.

Fact: Are there any alternatives to the scheme used by HTTPS for transmitting and receiving sensitive information? en.wikipedia.org/wiki/NaCl_(software) works pretty good and the code can fit in a Tweet. Suprisingly, its use seems to be spreading; unlike SSL, it does not encourage reliance on untrusted commercial third parties such as SSL cert vendors, "secure" content delivery networks, etc.

Fact: Incidentally NaCl compiles without using make. It requires only /bin/sh and (opinion:) the short scripts are easier to edit than makefiles.

SSL doesn't require relying on any third-parties, any more than NaCl does - you can use a pinned self-signed certificate, and you don't need any CDNs.

CA issued certs are only used in websites, because you don't have a secure channel with which to transmit the pinned cert, but they're redundant for apps.

"SSL doesn't require relying on any third parties"

The word "require" was in quotes for a reason. I have changed the sentence to say "encourage".

In practice many people using SSL do rely on third parties. In my opinion this is where many problems arise.

My opinion is that most people are not aware SSL can be set up without using third parties, and even among those who are, the whole scheme is so cumbersome and error-prone that such persons are content to pay untrusted vendors, or to allow browser authors, to manage their "security".

"... they're redundant for apps."

OK, that's a fair point. My comments on third party vendors are only applicable to websites. My comments on the other problems with OpenSSL apply to both apps and websites.

My comments on third party vendors are only applicable to websites.

But NaCl can't be (securely) used on sites at all, so there's no alternative to SSL there anyway.

I run CurveCP servers on my computers and they can serve encrypted HTML.

It is possible.

See curvecp.org/httpcurve.html

If you want a working example, see curveprotect.org

Of course it's possible to transmit encrypted HTML over other channels; I can also zip my HTML files and put a password on them. I was talking about serving a website that can be securely accessed using standard software, not special tools.

Did you see the other thread that made the HN front page shortly after this one? It was regarding "deprecating" plain text HTTP traffic. It seems some readers believe there is a "requirement" to involve third parties where SSL-"secured" websites are concerned.

TLS and NaCl are entirely different beasts. NaCl is a nice piece of technology, but TLS isn't just a technology solution; it's fundamentally a policy solution. TLS solves (or tries to, at least) both the "who am I talking to" problem and the "are we talking securely" problem.

NaCl can only replace the second one, which is a nonsensical idea to propose because it's not an issue (and it's the easier problem to solve anyway)

The first problem can be addressed by the CurveCP prototype, which uses NaCl.

tinysshd (see tinyssh.org) coupled with curvecpserver is a working example.

This does not mean that SSL is available for the app. It means that the app currently happens to have an HTTPS endpoint that appears to work. This could be an accident on the BBC's part. As in, the app team requested HTTP and got a confirmation of HTTP, and due to a deployment quirk, also got HTTPS, but can't rely on that since next deploy might "fix" it.

Possibly.

Submit to http://plaintextoffenders.com/ maybe ?

You blacked out your location in the Charles Proxy screenshot, but not in the chrome screenshot. Just an FYI.

I know.

If the location is passed as part of the url get request, wouldn't it still be visible if the request was through HTTPS? I mean it's in the url, isn't that always going to be public, just not the resulting data returned?

No. That's not how HTTPS works.

Could you elaborate - I genuinely don't know the process involved. When an HTTPS request is processed, does the client first directly contact the host and negotiate the secure session, THEN pass the URI request along?

That's correct. The conversation, as seen by an eavesdropper will be:

  - Client makes DNS request to example.com.
  - DNS server (we hope the legitimate one) sends IP addr in response.
  - Client connects to server IP.
  - TLS negotiation including certs.
  - Bunch of bytes that look like noise.
  - Disconnect.

In the case of SNI ( https://en.wikipedia.org/wiki/Server_Name_Indication ) the attacker will see which virtual host you contacted (it's probably the same as the one seen in the DNS lookup).

Exactly. TLS is, as the name implies, at the transport layer (TCP). (TLS is the same thing as SSL, the "S" in HTTPS, unless someone wants to be pedantic.) Everything that is at the HTTP level gets encrypted. The only exception to this is (sometimes) the hostname through a process call SNI (Server Name Indication), which sends the hostname as part of the TLS setup before an encrypted session is setup so that the server knows which website's certificate it should be using. This is the only way that you can host more than one website on a single IP address (unless they all share the same wildcard certificate or a single cert has an alt-name for each).

The answers you have already to this are good enough to give you an idea of what's going on. If you want to dig further and actually have a look at what's going on when an http vs. https session is established, grab a tool like Fiddler or Wireshark (or Charles(?) on the Mac) to actually have a look at the traffic as it's transmitted and received. I'd suggest starting off easy with Fiddler or Charles as you won't have to trawl through a bunch of raw TCP traffic to figure it out, they're nicely filtered to HTTP/S traffic. Once you've figured out Fiddler, then dig further with Wireshark. Both tools are invaluable for debugging web traffic. There's a couple of tutorials that allow you to act as a man-in-the-middle on your own connection to sniff the SSL traffic and figure out what's going on: http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/Fire.... These tools are really useful in helping you understand further exactly what's going on.

Only the hostname could be visible, not the entire URL.

Reply on news.ycombinator.com