On the modern web, ISPs are one of your threats (2015)
utcc.utoronto.ca
utcc.utoronto.ca
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.
Unrelatedly: I was very surprised that the GFW lets through Amazon web traffic.
[1] http://blog.zorinaq.com/my-experience-with-the-great-firewal...
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).
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 the parent comment is describing is a script tag which fails to load because its src is served over https instead of http.
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.
TV networks inject a ridiculous amount of ads in and around their content (even natively into the content sometimes), even for content you pay for.
> 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.
[1] https://konklone.com/post/were-deprecating-http-and-its-goin...
Maybe I'm just cynical, but I can't imagine anyone believing that ads are a "courtesy".
Comcast understands that politics works on money and connections, not facts, and had learned to play that game to great profit for themselves.
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.
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).
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.
Also why not just track via the CC name? I guess cash / check users?
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.
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.
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.
Granted, it's really not that difficult, but baking this into existing development environments will become a task many projects will need to repeat.
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.
Just issue a self-signed certificate. How is this not straight forward? All you need is a single, well-known OpenSSL command:
openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout test.key -out test.crt -subj /CN=10.0.2.2 -days 3650Most 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.
Let that sink in.
With "well known" I meant that you can find it quickly on StackOverflow:
http://stackoverflow.com/q/10175812
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.
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.
This pretty much eliminates all the downsides people tend to mention with dropping plain HTTP completely.
* Note that tech users can simply be told that they need to use HTTPS over HTTP explicitly.
More importantly, my proposal does not affect those scenarios, should they exist.
> Especially, there is nothing "local" about them
They're used for local area networks probably over 99.9% of the time.
Really, I am even less sure now what your proposal actually is. Could you explain?
> They're used for local area networks probably over 99.9% of the time.
If you count the global internal networks of companies as "local area networks", sure ...
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.
Is there a system where trust is not necessary, but can still get things done?
An entirely encrypted network of relays where ip addresses themselves are encrypted so no one can snoop traffic.
[1] https://en.wikipedia.org/wiki/Overlay_network
[1] https://twitter.com/realdonaldtrump/status/53260835850816716...
[2] https://www.aei.org/wp-content/uploads/2012/10/-broadband-co...
I believe the only places where you'd use C is web servers themselves.
As an aside, the last CVE (publicly known, logged vulnerability) for MbedTLS that affected server-side code was from January 2015.