
HTTPS provides more than just privacy - nailer
https://certsimple.com/blog/ssl-why-do-i-need-it
======
pilif
Especially point 4 («Not having your content modified by carriers») is getting
more and more important these days. Whenever I hear people saying that they
don't need https as they are providing a strictly read-only experience I
always wonder what they will say as their ads get replaced with other ads by
carriers and other "transparent" proxies in between.

And if your site is only moderately complex and using some of the more
advanced HTTP features (pipelining, websockets or plain long polling), you
might be better off using SSL too because by now the likelyhood of any of this
working unhindered by various "security" and "traffic optimization" tools is
approaching zero very quickly.

On the other hand, I wonder how long it's going to take before carriers and
providers in general mandate the installation of a root cert "for your
security" in order to be able to continue messing with the traffic to insert
ads or "increase security".

~~~
developer2
>> the likelyhood of any of this working unhindered by various "security" and
"traffic optimization" tools is approaching zero very quickly.

Except that anti-virus software is now man-in-the-middling HTTPS, and it is
considered "normal". All the security of HTTPS being thrown away for the sake
of scanning all transfers.

~~~
pilif
If it's happening locally (likely) and if it's handling certificate validation
correctly (way less likely), then there's no difference connection-security-
wise between the AV tool running or not running.

Of course, AV tool will still mess with your connections and break them in
interesting ways, but that has been true since the beginning of AV and in case
of local AV you can at least ask to user to try and turn it off. If it works
then, you can blame the AV software.

If you have a proxy server which does, for example, duplicate some POST
requests, accountability is much harder und you will probably have to resort
to adding workarounds for the issue (this has happened to me).

------
nailer
Author here! Surprising thing when researching this was how fast some of the
stuff talked about a year ago is already upon us in the upcoming browser
releases:

\- If you're running Chrome Canary, try visiting
[http://html5demos.com/geo](http://html5demos.com/geo) (which hasn't yet been
updated for HTTPS yet). Geolocation fails, consistently over HTTP

\- Firefox nightlies has already started warning for sites that allow POST
over HTTP: [https://www.fxsitecompat.com/en-CA/docs/2015/non-https-
sites...](https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites-
containing-login-form-will-be-marked-insecure/) (for type=password only, see
dsp1234's note below)

PS. since this article has gotten so much attention: does anyone on HN know of
a newer app than Driftnet or Etherpeg for reassembling images from HTTP
traffic? I wanted something newer (that people could install themselves on a
Mac) but couldn't find anything.

~~~
Dorian-Marie
The geolocation demo works on Chrome for Android though.

~~~
dsp1234
_Firefox nightlies has already started warning for sites that allow POST over
HTTP_

only for pages that contain a password input

------
stygiansonic
Maybe a nitpick, but I think this section could be clearer:

" _Except HTTPS traffic won 't show up on Malory's screen: things encrypted
with a website's public key can only be decrypted with the website's private
key. Because the website's private key is (hopefully) only available to the
website, Malory can't decrypt the traffic._"

I know it's just an overview, but this explanation seems a bit confusing. I
mean, it's true that the trust is anchored on the private key but that's only
one part of it.

My (simple) understanding of TLS is that basically, the public/private keys
are used to secure the shared secrets used to derive the symmetric session
keys OR to authenticate something like a DH key exchange that's used to derive
the session keys. In the first case, the client would generated a shared
secret, encrypt with the public key, and then send to the server. In the
second case, the authenticated DH key exchange allows both client/server to
arrive at the shared secrets.

In either case, it's these symmetric session keys which are used to
encrypt/decrypt the traffic.

My understanding is that even if you capture the encrypted traffic and then
later on, you obtain the private key, you wouldn't be able to decrypt the
traffic if the parties used something like a DH key exchange. (This would be
(perfect) forward secrecy?) Of course if you have the private key and no one
knows yet, then you could impersonate the server and MiTM future connections,
I think.

Someone with better knowledge could explain this better.

~~~
bmm6o
You're comments are correct, but I don't think replacing the 1 brief paragraph
in TFA with your 3 would improve the article.

------
Flimm
Here's another reason:

If you're providing iframe or Javascript embeds for people to paste on other
websites, (like YouTube and Vimeo do for their videos), you better be using
HTTPS. If you don't, your embeds won't work on HTTPS sites, as modern browsers
block mixed active content.

~~~
XERQ
If you're concerned about the overhead of an SSL handshake, another option is
simply using '//embed.example.com' so it automatically chooses http/https
based on the main site.

~~~
lambau
Who is rightfully concerned about the overhead of an SSL handshake in 2016?

------
datalist
While the point of the article is not incorrect, I would say the title is

#0 and #1 are intrinsically part of HTTPS

#2 and #3 are just because Google and browser vendors simply limit these
things to HTTPS. It is not like it can only come with HTTPS.

Finally, #4 is a side effect of #0.

So the only thing really provided BY HTTPS is encryption and authenticity.

~~~
JoshTriplett
> #2 and #3 are just because Google and browser vendors simply limit these
> things to HTTPS. It is not like it can only come with HTTPS.

True for "signaling value", but for powerful browser features that the user
grants or denies on a site-by-site basis, there's a critical reason to only
allow those for HTTPS. If you allow those features for HTTP, you allow them
for anyone who can MITM your connection and spoof those sites. Any random ISP,
open wifi, or other entity could trivially MITM a popular site via HTTP and
obtain privileges it should not have.

~~~
theandrewbailey
> Any random ISP, open wifi, or other entity could trivially MITM a popular
> site via HTTP and obtain privileges...

If a user is MITM'ed, it doesn't matter if some features are disabled. The
attackers can do anything they damn well please, like directing the user to a
compromised HTTPS site to access those features, or to a drive by download to
do worse things.

~~~
JoshTriplett
Not true at all. A user's grant of permission applies to a particular site,
and HTTPS ensures that nobody can spoof that site. If the user visits an HTTP
page and an MITM attack redirects that to some HTTPS page elsewhere, that page
will still have to ask the user for permission. But if HTTP pages can ask for
permission to access those same features, then an MITM attacker can redirect
to a spoofed version of a popular HTTP site that asks for that permission.

Concrete example: geolocation permission. You visit some popular mapping site
that uses HTTP, and grant it persistent permission to use your location.
Later, you browse something else via HTTP over a Tor connection. In that
browsing session, if you saw any permission prompt for geolocation, you'd
reject it. However, a malicious exit node could MITM you and use that to
determine your location by pretending to be the mapping site, without a
permission prompt.

Ditto for getUserMedia (webcam/audio), fullscreen, and any other permission a
user can grant or deny on a site-by-site basis.

So, browsers want to drop the possibility to use those features from HTTP, not
just to push sites to HTTPS but because the entire concept of granting
permission only to a specific site doesn't doesn't work with HTTP.

~~~
theandrewbailey
When the user grants permission to a site, how does that permission work? By
domain or resolved IP address? If it's by domain and there's no HPKP for it
(and IP not cached), the MITM can send a malicious IP through DNS for any
domain. The server at malicious IP can fake being whatever domain and the
attack will work.

~~~
JoshTriplett
By domain. However, with a requirement for HTTPS, it doesn't matter if MITM
hijacks that domain and points it at another IP, because the server on that IP
can't present a valid certificate for that domain, so it won't load at all.

Pinning makes that even more secure, but even without pinning, requiring HTTPS
raises the bar from a simple MITM to obtaining a fraudulent certificate from a
trusted certificate authority (risking a blacklist of that CA in all
browsers).

~~~
konklone
I think that instead of HPKP, the parent poster meant to refer to HSTS.

If the attacker MITMs an HTTPS request, then they have to provide a forged
certificate (whether HSTS is set or not).

If the attacker MITMs an HTTP request which would have normally been
redirected (e.g. typing "facebook.com" into the URL bar), then HSTS is
required. Without it, no forged certificate required.

HTTPS and HSTS should have just been the baseline the web shipped with, but
the web shipped before people thought about these things, and arguably before
encryption was stable/secure/fast enough to be practical for the whole web.

I'm very happy that the federal HTTPS-policy includes an HSTS requirement for
federal agencies: [https://https.cio.gov/](https://https.cio.gov/)

~~~
JoshTriplett
Very good point.

However, even if the attacker MITMs an HTTP request that would have been
redirected, for a site that didn't use HSTS, they won't get cookies marked
"secure", and they won't get permissions that require HTTPS. So the browser
mechanism limiting those permissions to HTTPS still works even in that case,
though the user and site both have other problems.

~~~
konklone
They won't get secure cookies [for the site they're attacking], though they
could plausibly redirect the user to a similar-looking HTTPS domain under
their control and get permissions requiring a secure origin.

~~~
JoshTriplett
True, but they won't get permissions that the user grants on a site-by-site
basis, which also means the attack can't silently happen in the background.

------
ultramancool
> T-Mobile degrades video quality

SSL cannot prevent this. The connection can still be slowed down and video
quality will be automatically degraded. They don't reencode streams on the fly
or anything, just degrade bandwidth and let the applications do the rest. The
reencoding and DRM cracking needed to do the former would be an insane
investment of man-hours and CPU resources, even if they didn't use SSL.

Additionally a bunch of these "reasons" are just artificial restrictions
imposed by web browsers. If it weren't for letsencrypt providing free certs
without any ID checks like other free cert places I'd be complaining about it.

~~~
nailer
Yeah, I think in this case T-Mobile was re-encoding anything in HTTP, so the
stream _appeared_ to be full quality but wasn't. Simple QoS would keep the
quality down and the bandwidth low, but hopefully it would be more apparent
that a better quality stream exists but is not being delivered.

~~~
ikeboy
Do you have a source for that? The article you linked doesn't say that, and
[https://www.eff.org/deeplinks/2016/01/eff-confirms-t-
mobiles...](https://www.eff.org/deeplinks/2016/01/eff-confirms-t-mobiles-
bingeon-optimization-just-throttling-applies) also confirms that no encoding
is taking place.

Separately, the article you linked from techdirt has a major misunderstanding
of the EFF piece.

It says "EFF also discovered that T-Mobile's earlier statement that it can't
detect encrypted video is also misleading, as the company now claims it can"

But the EFF part quoted is talking specifically about http, not https, as a
close reading will reveal.

Also, the EFF test is a bit inconclusive, because https might be slower than
http for other reasons. It probably doesn't account for the large differences
they observed, but a better study would have tested http/https on other
carriers, and on a T-mobile phone with Binge On turned off, to isolate the
Binge-on effect.

~~~
fryguy
If you look at the chart about halfway down, the "Normal" (red) is HTTPS, and
the "Binge-on" (blue) is HTTP.

~~~
ikeboy
Exactly. The part about detecting video is specifically binge on/http, and the
techdirt article completely misunderstands it and claims it's talking about
encrypted video.

------
flubert
Where is a good site for getting an introduction on what HTTPS covers. Is the
URL completely exposed? Does your ISP/third-parties know the domain, the
subdomain, the path, and parameters in each URL?

~~~
rogeryu
What I understand is that URL is encrypted, including path and parameters in
URL and in POST requests. However, the IP address is public, and it's probably
quite easy to link an IP address to a website.

There are several websites that offer this service: search an IP and get a
list of all known websites that use that IP.

A link to an article from an authority in this field, that really explains
this, would be really welcome!!!

~~~
comex
This used to be correct, but modern SSL clients support SNI (Server Name
Indication), which involves sending the exact hostname in the clear to allow
vhosts to have different certificates. The path and everything else in the
actual HTTP request is still private, though.

------
ikeboy
>T-Mobile re-encodes videos, degrading quality

The link goes to an article that says T-mobile didn't reencode at all, but was
throttling.

I don't think there's any evidence that T-mobile re-encoded video from non
binge-on providers, so they don't belong in that list. (And if someone's a
partner, they _want_ to help T-mobile do whatever it is they're doing, so
using https to prevent that makes no sense.)

------
lambau
HTTPS is especially important for Tor users. With tor, all HTTP requests pass
through a random exit node, who may be malicious. If the site is not using
HTTPS, then the exit node can inject malicious javascript into the page. By
deploying HTTPS, you are also helping tor users to browse the web more
securely.

------
smegel
> This is effective enough to the point where nefarious carriers have asked
> users to install configuration profiles to add the carrier's root
> certificates, which are used to modify and inspect what should be private
> traffic.

It makes me wonder if the NSA isn't also whispering "that would be nice" into
the carriers ears.

------
SFjulie1
Let's imagine I am the swimming pool around the corner or the guy wanting to
go to the swimming pool.

Why would we need https?

Who is gonna tamper the "advertisement less" schedules of the swimming pool
from rue st Hubert (montréal)? Why would they?

Why would the swimming pool care to pay X$/month for this? And why could I
care that anyone knows I am looking at the opening and closing of my swimming
pool?

I am an old man, I don't watch porn or pick up on girls anymore or think of
revolutions.

I clearly need no https ... Why should I pay directly or indirectly for it?

~~~
dragonwriter
Who is going to tamper with nonsensitive pages? People injectibg, e.g.,
malware-loading "your computer has a virus" popups.

------
overcast
Also provides heartache and headaches to get working properly.

~~~
jrapdx3
I can only add to the chorus here. Recently used LE to generate certs for my
servers running on FreeBSD, which to date is really only semi-supported by LE.

To my surprise, getting certs was quite easy. Just needed to run the LE
utility, answer a few questions, like the domains to be included, and that was
it. Took a few seconds at most.

The only other task was pointing nginx servers to the LE certs location,
edited the config files in a minute or so. Of course that only needs to be
done one time.

Using the early-stage LE tools is already quite painless, I expect fully
automating the process will be developed in the coming months. But even with
the "primitive" tools available now, it's hardly a burden spending a few
seconds every 3 months to get the tremendous benefit provided.

~~~
rogeryu
And you can (should) probably set up a cron job to do that every 2 months!

------
jimwalsh
Funny that this article about HTTPS gets a Red X on the https in my Chrome.

~~~
nailer
Hi Jim! We're confident the site is properly configured
[https://www.ssllabs.com/ssltest/analyze.html?d=certsimple.co...](https://www.ssllabs.com/ssltest/analyze.html?d=certsimple.com),
but if you email me mike@certsimple.com with details of any errors I'll
happily check it out.

------
Grue3
Yeah, it also provides stable profit to certification "authorities".

~~~
narrowrail
As _ikke_ mentioned, it's as if you entirely missed the HN discussions about
LE.

[https://en.wikipedia.org/wiki/Let's_Encrypt](https://en.wikipedia.org/wiki/Let's_Encrypt)

You can also search HN and GitHub to discover the numerous features and tools.

~~~
Grue3
Let's Encrypt is essentially shareware. The basic features are available for
free, but if you want something better than that, such as wildcard
certificates, you must pay up. Not to mention that it's cross-signed with
IdenTrust, a commercial CA, and since _everyone_ on the web _has_ to use this
service to get HTTPS (there aren't other decent alternatives), this is a good
way for IdenTrust to boost its numbers and be able to claim it's "the biggest
CA in the world" or something. There's no way to choose a different CA with
Let's Encrypt.

~~~
matt4077
\- Why should I care about the backing CA as long as all browsers accept it?

\- You can register up to 100 subdomains in a certificate and up to 5
certificates per domain/week. With their certificate expiry set at 3 months,
that comes out to about 6,000 subdomains you can register. I know there are
some setups where every user gets a subdomain. But I'd wager that less than 1
in 10000 LE users would run into these limits. (which may actually be lifted
when the beta period ends).

\- LE doesn't offer any paid certificates so it's really hard to spin this as
a shareware-style incentive to spend money with them.

~~~
Grue3
>Why should I care about the backing CA as long as all browsers accept it?

[https://en.wikipedia.org/wiki/DigiNotar](https://en.wikipedia.org/wiki/DigiNotar)

>You can register up to 100 subdomains in a certificate and up to 5
certificates per domain/week.

What if I want dynamic subdomains for my website? These limitations are
absurdly low.

>LE doesn't offer any paid certificates

They don't, but their partners do. If HTTPS becomes ubiquitous and necessary
to host a website, they stand to gain a lot.

