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