
Plain web text offenders: sending my location over HTTP when HTTPS was possible - jgrahamc
http://blog.jgc.org/2015/04/plain-web-text-offenders-sending-my.html
======
nodata
'Perhaps "This app would like to use HTTP for its API" should be a permission
that the user has to explicitly give.'

Good idea.

~~~
grabeh
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"?

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

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

~~~
skywhopper
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.

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

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

~~~
icebraining
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.

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

~~~
rakoo
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)

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

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

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

------
Sarkie
Submit to [http://plaintextoffenders.com/](http://plaintextoffenders.com/)
maybe ?

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

~~~
jgrahamc
I know.

------
snorrah
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?

~~~
jgrahamc
No. That's not how HTTPS works.

~~~
snorrah
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?

~~~
azdle
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).

