I look forward to a HTTPS-only world some day to prevent MITM issues like the original article, but we have a ways to go.
I run a service that involves adding Javascript to a site (like you would with Google Analytics). At one point we were serving 100% of scripts / APIs via SSL, but ended up moving to matching the origin host's protocol because customers were complaining of older version of IE that actually block HTTPS requests that originate from HTTP pages.
So now we serve API calls matching the protocol of the domain the script is loaded on.
It's been on our mind to go back and figure out exactly which browsers this affects, implement browser detection logic, and then serve SSL APIs for everyone else. Although it's a bit tricky when supporting customers who have users (still) accessing them with obscure / old browsers.
More broadly, Let's Encrypt has been a great initiative. AWS WAF is also great for generating certs easily (although only inside AWS unfortunately with specific AWS services). Initiatives encouraging people using legacy browsers upgrade to upgrade will also help companies like ours (and others) trying to support 100+ browser versions on various OS's.
For us, China has also been a slight issue. The firewall tends to add extra (unpredictable) latency for SSL requests, even when engaging with firms for $xx,000 specializing in overcoming China networking related obstacles.
"customers were complaining of older version of IE that actually block HTTPS requests that originate from HTTP pages"
What what what? I've never heard of that particular IE weirdness. Do you know which versions have that problem - and is there any documentation anywhere?
What you are describing is correct behavior for Ajax: an "origin" is defined by the domain/protocol/port tuple, and so http://www.example.com and https://www.example.com are the same origin.
What the parent comment is describing is a script tag which fails to load because its src is served over https instead of http.
In Beijing currently. I set up a SOCKS proxy through an EC2 instance and it seems to be throttled after 10 minutes of use -- to the point that Edge on my smartphone is faster.
Unrelatedly: I was very surprised that the GFW lets through Amazon web traffic.
I wish I could. I don't see how CHina could capture SSL traffic in terms of inspection, but my networking knowledge is limited.
Re: higher SSL latency, my best guess is either under-provisioned routing hardware or intentional throttling.
More generally, the network topology in mainland is a lot different than networks in other countries. There are 3 main ISPs that aren't as readily peered together as they are elsewhere. (From what I understand, if you were to run a hosting company inside China for example, you would want - or need - to have deals in place with each ISP).
Can anyone think of other industries where this is the case? Imagine for a moment if grocery stores injected small amounts of lead into the food, or if gas stations injected water into the fuel (for bulking).
I know this kind of thing happens in China (think about toxic products added to baby milk, for example, to cheat protein tests). But that's at the "website" level, not the "ISP" level. I suppose healthcare (at least in the US) is the most likely industry to see attacker behavior.
It's interesting to think of it this way. Clearly, the attackers (being ISPs in this case) don't see it this way or don't want to see this sort of MITM this way. Following one of the links in the article [1], you get some great quotes:
> Comcast injects ads into unencrypted traffic, because "it's a courtesy, and it helps address some concerns that people might not be absolutely sure they're on a hotspot from Comcast".
So maybe someone out there actually feels this way when they find content has been directly injected in their unencrypted browsing session. I sure don't.
Anything can be spun to look more positive, or more negative. But that's BS. There are other ways for Comcast to inform their customers that it's a Comcast Wi-Fi. And even if there weren't, are they even working with the Wi-Fi Alliance to create a "perfect protocol" to do this in a secure way?
Let's assume Comcast really thinks it is a feature that many people will like (I personally rather think it is a feeble excuse, but don't want to completely exclude this possibility). But why doesn't Comcast enable people to opt out of this "feature" then?
A closer analogy would be if grocery stores were giving you reward/savings cards that you have to scan on every purchase. It is advertised as providing you a small discount after a certain number of purchases but really it is meant to track you over time.
Is this in the States? I've always been under the impression that this has more to do with the corn lobby than anything else, with a nod towards the environment in that it's a biofuel so it's renewable. That's offset by using a potential food source for fuel.
Here's a quote from Wikipedia that indicates ethanol (E85) actually worsens pollution:
A study by atmospheric scientists at Stanford University found that E85 fuel would increase the risk of air pollution deaths relative to gasoline by 9% in Los Angeles, US: a very large, urban, car-based metropolis that is a worst-case scenario. Ozone levels are significantly increased, thereby increasing photochemical smog and aggravating medical problems such as asthma.
One could say that non-cash (debit/credit) transactions are recorded by the devices that enable them, and thus recorded and tied to an identity. The information could then be used by matching your card number when you use it online or elsewhere.
> or if gas stations injected water into the fuel (for bulking)
Does this not happen in the US? It may be an urban legend, but in Poland, I did hear from drivers that some gas stations do that (usually non-franchise ones).
When I was visiting India roughly a decade ago, I was told that it was very common for gas stations to bulk gasoline with kerosine. Apparently kerosine is heavily subsidized by the state as it's used for cooking by poor people, so it's a lot cheaper than gasoline.
The problem with this is that it reduces the octane rating of the fuel, and as a result cars in India are apparently commonly detuned in order to avoid knocking when running on low octane gas.
That being said, bulking up gasoline with kerosine sounds like a less bad idea than using water, as I'd guess the water phase separates from the gasoline.
With the creation of Let's Encrypt, there is really no longer any justifiable reason to bitch about the costs of a certificate. We all know the threat model now and if you are going to be interacting with the general public you should absolutely be held to minimum standards to ensure that nobody is tampering or sniffing your traffic along the way.
If you are just doing DIY stuff then you probably don't need the advanced features that are getting moved to HTTPS-only. If you do need those features, you are advanced enough to take the five minutes and generate your own CA certificate and install it onto your machines. Boom, now you can sign your own HTTPS cert. Problem solved and you don't need to destroy the internet for everyone else nor participate in even the minimum of public interaction. DIY to your heart's content.
If you are just doing DIY stuff then you probably don't need the advanced features that are getting moved to HTTPS-only.
Like getusermedia, or service workers, or webrtc?
Speak. For. Your. Self.
Precisely personal projects use these technologies. That's why they're personal projects; because I'm trying out new stuff.
Testing this from a phone emulator the other day i had to resort to inordinate hacks to access a web push test page on the host. How to https://10.0.2.2? It's not straightforward.
Im happy for it, it's worth it. but don't discount the effort it now takes.
Ps: "bitch about the costs of a certificate." --- I prefer to call it a valid complaint about an extortion racket, but I guess opinions differ.
Most dev don't know nothing about setuping SSL. Nothing.
I'm not talking about new commers, students, interns, etc. No, no, no. I'ml talking about what's constitute the majority of the work force of IT.
You are living in a bubble, ignoring most sites out there are not made by experts, but by people that knows a bit of PHP, HTML and CSS.
As a Python dev on Linux that have to live in docker + lastJS fantasy environments, I understand why you think that, it's so tempting to ignore the reality when we are consedering that playing with new toys on HN FP is a way to relax.
Except once a month I train professionals for as a side activity. People that have 20 years on as dev in multinationals, research centers, administrations, etc. And there is no way the command you list can be remotely considered "well known" by them.
At the begining of the month, I just gave a Git training. 2 guys and a girl, working for years for a huge bank on the official website. They were still using CVS before arriving. I said CVS, not mercurial, bazaar, not even SVN. CVS.
2 of them never used the terminal of course (tortoise anyone ?), one never ever worked on a non windows machine in her life.
And yes, I do think that researching and using this command is not too much to ask for - at least for people calling themselves "developers". Also, I'm pretty sure that the concepts behind HTTP+TLS are easier to learn than version control, or learning some new library or API you need for your next project.
With "straight forward" I meant that it is a single command that works on any OS (given OpenSSL is installed), and not some complicated multi-step process involving third-party services etc.
Importing that in an android emulator is far from easy, and even after you manage, for some reason it didn't work for service workers. The page loads fine but the service workers don't.
I had to hack around it with a custom domain, let's encrypt, and then rebinding that domain to 10.0.2.2.
It wasn't straightforward.
Again: a price I'm happy to pay, but a price nonetheless.
> Precisely personal projects use these technologies. That's why they're personal projects; because I'm trying out new stuff.
Again: set up a self-signed certificate and you can do anything you want. It's a test environment, it takes a single google search and less than ten minutes to figure out how to issue a CA cert, import it in Windows, and sign a server certificate. Then you never have to think about it again.
Everyone always talks the talk about how they need to bake in security right from the start. Time to start walking the walk. If you don't use HTTPS-only features then go hog wild, otherwise you need to start thinking about how you are going to structure your application deployment to support HTTPS.
After all - even Google learned the hard way that there's no such thing as a "local network" where it's appropriate to run plain HTTP connections. Remember "encryption removed here ;)"? Just encrypt everywhere, day one.
One-time effort to set up a reverse proxy or a certificate doesn't really concern me that much, any more than the time it takes you to set up a Tomcat installation. Mostly this will be baked into Rails or your Maven archetype or whatever and you won't have to worry about it.
> I prefer to call it a valid complaint about an extortion racket, but I guess opinions differ
There's no "opinion" about it. A Let's Encrypt certificate costs nothing. They have to be extorting something from you before it's extortion.
But it's no less straightforward than being your own CA in your dev environment and issuing a cert to any other name. There's no need to go through the hassle of getting a public cert for this use case.
Interesting to note how important this is for developers to consider now. If we're going to move to an HTTPS only web, we need to both: 1) understand how CAs work (including how to be your own local CA) and 2) make this an easy or seamless process in terms of workflow.
Granted, it's really not that difficult, but baking this into existing development environments will become a task many projects will need to repeat.
Even the "professional" development environments like Visual Studio aren't quite there. I've got a site at work that can only be run locally on one machine because VS won't issue the right certificate, and won't let me disable the SSL config.
That's not correct and would be a terrible idea. There is nothing technically special about RFC1918 addresses, and if your router doesn't have an explicit route for some RFC1918 address, it will forward packets to that address to your upstream provider. The only way that RFC1918 addresses are special is that it's guaranteed that the RIRs (ARIN, RIPE, and so on) won't ever allocate them to providers, that's it. Especially, there is nothing "local" about them, it's perfectly possible to use them on WANs, you can interconnect businesses using different RFC1918 prefixes, say, and some ISPs even assign them to their customers (using NAT to connect them to the public internet).
Communicating over the Internet is like relaying letters with the destination and return address at the top. Anyone in the chain can choose to look at the content, tamper with it, or refuse to pass it on.
A giant web that relies on trust. Is there a system where trust is not necessary, but can still get things done? Although I can't think of a use-case for this.
Donald Trump has stated his opposition to net neutrality [1], although it is unclear to what extent he intends to pursue this issue. Trump's picks for his FCC transition team are both supportive of permitting differential pricing models [2].
If TLS/HTTPS was easy to use from userspace C, HTTP could probably phase out very soon. Node, Go, Python, and other web tech actually makes this easier, because I don't have to call OpenSSL myself. So, even though I really love C, it's not in the best place for the modern network.
I run a service that involves adding Javascript to a site (like you would with Google Analytics). At one point we were serving 100% of scripts / APIs via SSL, but ended up moving to matching the origin host's protocol because customers were complaining of older version of IE that actually block HTTPS requests that originate from HTTP pages.
So now we serve API calls matching the protocol of the domain the script is loaded on.
It's been on our mind to go back and figure out exactly which browsers this affects, implement browser detection logic, and then serve SSL APIs for everyone else. Although it's a bit tricky when supporting customers who have users (still) accessing them with obscure / old browsers.
More broadly, Let's Encrypt has been a great initiative. AWS WAF is also great for generating certs easily (although only inside AWS unfortunately with specific AWS services). Initiatives encouraging people using legacy browsers upgrade to upgrade will also help companies like ours (and others) trying to support 100+ browser versions on various OS's.
For us, China has also been a slight issue. The firewall tends to add extra (unpredictable) latency for SSL requests, even when engaging with firms for $xx,000 specializing in overcoming China networking related obstacles.