HTTPS provides more than just privacy
certsimple.com
certsimple.com
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".
Yesterday I called them and agreed to pay their $35 extortion fee to get "unlimited" data along with being removed from their proxy system. :/
It really feels like websites should know what transport they're operating on (secure vs unsecure) and present what information they can reasonably with unsecure. Though turning every website into a "modal" thing is also a pretty high order.
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.
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).
- If you're running Chrome Canary, try visiting 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... (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.
only for pages that contain a password input
https://codereview.chromium.org/1530403002/
And here is the Firefox feature request, filed in 2014:
"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.
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.
#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.
E.g, you run an online video company, and (for some silly reason) you don't care about privacy. You still don't want T-Mobile turning your great HD content into a low resolution blocky mess.
Edit: actually, thinking about it, you're right. I've updated the article to use the word 'privacy' to better separate it from the other aspects on encryption. Thanks datalist!
Seems like a pretty real and legitimate reason to me.
Sure, but HTTPS doesn't provide it. I mean, not really. HTTPS is the flag by which browser manufacturers have toggled the behaviour.
This is just pedantic.
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.
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.
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.
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).
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/
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.
The cynic in me is thinking "hey, funny that a company selling SSL Certs wrote an article about how great SSL Certs are which doesn't do much more than state side-benefits to one primary benefit of having SSL"
HTTPS gets you privacy, tamper-resistance, and authenticity for the end-user.
This is the one that I often forget: just because something is encrypted doesn't mean it can't be meaningfully manipulated without knowledge of cleartext.
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.
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.
- The SNI extension can tell you the hostname you're connecting to even over SSL, just like the Host: http header they're already using. This is visible in the clear during the SSL handshake. SSL connections do not mask what you're connecting to at all, nor do they attempt to.
- They selectively pick the video service's CDN IPs and slow them down
also the ip...
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!!!
So no web traffic should traverse in the clear - the URL, domains, GET data, POST data, headers, etc are protected.
however that does leave a surprising amount of info. Your IP address, the IP address you're connecting to, the host domain you're connecting to if your browser just did a DNS lookup (99% likely it did), how long you communicate with that site, the traffic shape, etc etc.
As a crude example: your ISP sees a DNS lookup to pornhub.com, followed by a connection to the IP address associated with that name, followed by 3 hours of fairly large packet sizes in regular repetitive patterns. It's highly likely they can extrapolate what's in your browser.
Also, usually (almost) everything is exposed on the first request, before the server has got the chance to redirect to the encrypted version. At that point, the ISP/interceptor could just replace the redirect...
> The hostname is (usually) exposed through DNS, and is required for the server to know which certificate to send.
SNI solves this problem.
> Also, usually (almost) everything is exposed on the first request, before the server has got the chance to redirect to the encrypted version. At that point, the ISP/interceptor could just replace the redirect...
Admittedly, this is somewhat of a culture issue. I haven't read the DNSSEC spec, but it'd be cool to be able to specify redirects using DNS or smth. But at the end of the day, after that first connection (or preferably, it's already setup with HSTS preinitialized in your browser) you're never not going to be using HTTPS without scary warnings (assume the site admin has set up TLS properly).
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.)
It makes me wonder if the NSA isn't also whispering "that would be nice" into the carriers ears.
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?
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.
https://en.wikipedia.org/wiki/Let's_Encrypt
You can also search HN and GitHub to discover the numerous features and tools.
- 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.
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.
First off, it's free software and it's an open community. LetsEncrypt is trying to get wildcard certificates, but just because they haven't yet convinced CAs to allow them to have wildcard certificates doesn't make it anywhere close to shareware bullshit.
> 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.
This is FUD. Why do you care about IdenTrust beating their chest? Why do you want to use another backing CA? What possible benefit does that provide? The whole CA thing is fucked anyway (in terms of the massive centralisation), so changing the backing CA won't do much.
Also, to be fair, they did pull the trigger on LE, so it's not fair to get all pissy when they take credit for their decision.