Don't you need to use type = "password" to get the -for-every-character treatment?
I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways.
I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend:
- Create a font such that every character shows up as a * and use it for a text input.
- make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div.
- implement the text box ground up from scratch using div's and JS, like google docs does.
- implement a HTTPS password field in an iframe and communicate with it over post messages.
- the name of their tool was changed form "letsencrypt" to "certbot", breaking my cronjob
- for daemons that try to access the cert/key as non-privileged users, additional fiddling with permissions is necessary, which may even be overwritten on cert update if done incorrectly
- when the certs are renewed, daemons need to reload them. This means that ideally, you need to detect when a renewal actually happens (as opposed to an attempt), keep an up-to-date list of all daemons that use the certs and possibly completely restart them, dropping all existing connections (some daemons just don't support a live reload)
I'm not saying these problems are unsolvable, but may take way more than 5 minutes and I, for one, opted to renew my startcom certificate for another 3 years instead.
I just followed the instructions on their website, and it took me less than 5 minutes, including setting up the cronjob.
The cronjob correctly renewed the certificate at least once on multiple servers, with no issues whatsoever. I was also warned that the certificates were expiring via email, which I thought was awesome.
> I, for one, opted to renew my startcom certificate for another 3 years instead.
Wait really? When did you do this? I thought all certs signed by their root after sometime in October or November are all considered invalid due to their shenanigans with WoSign. Not so?
If the only thing you host is a small blog without ads on a server that you have complete control over and spun up last month or something, sure it's 5 minutes.
In the real world, for many commercial operations, and especially for legacy code, there can be significant hurdles. For example, it took the NY Times 2 years to move to HTTPS, significantly more than 5 minutes, and they haven't even migrated 100% yet. https://www.thesslstore.com/blog/new-york-times-moves-websit...
>unless you’re reading this in the future, you’re reading it on my blog over an insecure connection. That wasn’t such a big deal in 2009 when I started it, but it is now and there’s nothing I can do about it without investing some serious effort and dollars. I run on Google’s Blogger service which ironically given their earlier mentioned push to SSL, does not support it. Whilst Google doesn’t give me a means of directly serving content over SSL, I could always follow my own advice and wrap CloudFlare’s free service around it, but that won’t work unless I update the source of every single image I’ve ever added to almost 400 existing blog posts… and there’s no find and replace feature. This is the joy of SaaS – it’s super easy to manage and good at what it’s specifically designed to do, but try and step outside of that and, well, you’re screwed.
Another real world example, that I've encountered - your software is an intraweb site running on your customer's server and you have to play by their rules and policies on what your customers can put on their servers and when. And it's on exactly nobody's priority list.
It can indeed take some time to switch over, but why would you intentionally suppress a correct warning in the meantime? There is no good reason to mislead users here.
I do my job but there's only so much I can do if the owners of the servers who are serving my software tell me "before we can change this server's configuration we need approval from another office, it will be a few months until they can get back to us."
(This is a hypothetical situation, for me, because I eventually got all my customers on HTTPS back around 2012 or so. There was some push back and it did take a long time and we had to be very persistent with some customers... But it was well worth it!)
We are talking about the world of corporate IT and pointy haired bosses. I don't implement a social network, or email, I don't accept payments - I make intraweb sites that non-technical corporate paperpushers use to do their job. They are only interested in getting their work done; they are happy when they can get their work done without scary warnings they don't understand. If my software is giving them errors they are going to believe that it's my software that's the problem, and that doesn't look good for us. And we have to field support calls and explain ourselves.
...Or we could put a quick and dirty stopgate in to avoid something that makes us look bad and we can't do anything about.
Have you ever been on a team at a large company? Tons of bureaucracy. You're correct that Let's Encrypt is the path of least resistance in a shop where you control everything. In many large companies the path of least resistance is tweaking whatever is in your immediate control (e.g. the text inputs / javascript you're writing).
also u have to do the request over port 443, and the alternative dns validation is not supported in in the official client.
so its 5 min only in ideal case.
Let's Encrypt is great, but completely useless for... Actually every single website I host. No wildcard certs, the rapid rotation that requires software to renew it regularly, etc. The cost of implementing HTTPS for dozens of sites with no sensitive data is simply not worth it.
When companies like Google and Mozilla decided how to handle HTTPS, they decided based on their needs and their perception of everyone else's needs, like banks and major corporations. This led, IMHO, to a complete failure to recognize a lot of other uses for the Internet, and so their solutions fail to adequately account for them.
HTTPS is for the user's benefit, not the site owner's (barring legislation, of course). Also, HTTPS prevents hijacking, not just sniffing, of content by a MITM. That includes malware injection.
This has been coming for quite a long time. The time for excuses is over. If you think the safety of your users is "simply not worth it", well, I'd like to know what your websites are so I can block them at my firewall. I'm not saying this to be a dick, I'm saying this because this is an attitude of callous disregard on display, and it's downright odious given the modern security climate.
LE is not that hard to use, and I seriously question whether you can't make an API call once every 90 days per subdomain. The requirements have never been lower.
HTTPS is very much for the site owner's benefit as well. If your site is not HTTPS then you can't be sure that your users are seeing what you intend them to see. Ads, malicious script, whatever, can be injected or replace your content.
This. This this this. Automates everything so easily. I have helped someone personally deploy HTTPS for over a dozen sites and they all auto-renew without a hitch every 90 days.
Or the expectation that everyone take a huge cost burden to appease El Goog is a bigger burden than the startup industry realizes. There's really no solution for HTTPS that does less than double my hosting costs, either I have to buy expensive certs or move to another hosting provider which would support Let's Encrypt. Either way it's a couple hundred dollars a year to maintain hobby sites, which don't pay for themselves to begin with.
Of course, it works in Google's favor to make it unfeasible to maintain a website outside a cloud platform. It's amazing here people are so opposed to the democratization of the Internet, and so supportive of the death of it, over security provisions that will, in retrospect, be considered largely ineffective.
What are you talking about? There are plenty of low-cost VPS providers that give you full root access on which you can easily run certbot. That's what I'm doing now, and my hosting provider costs a whopping $20/year.
Say what you will, but pushing for passwords to be transmitted securely isn't Google fighting against the democratization of the Internet. They're doing that in other ways, sure, but promoting encryption isn't one of them.
Encryption could be offered without certification authorities that charge huge sums for certs. And there's a link on /new right now about Symantec which continues to reinforce how relying on CAs is a broken concept.
So, right now, I have 24/7 American-based phone support (this is a must-have), 99.9% uptime guarantee, WHM/cPanel software licensing included, 60 GB disk space, 600 GB bandwidth included. By all means, if you have a VPS service that can offer all of this at less than $30 a month, I'd love to consider it. I haven't changed hosting providers in a while, but I haven't found a company capable of meeting the requirements.
Have you thought about using that 24/7 phone support to ask them to upgrade cPanel? Since August it comes with LE support in the form of the AutoSSL plugin.
If there's not sensitive data, then there's no password field (passwords are by definition sensitive), and Chrome won't show a warning. So what's the problem?
Passwords are NOT by definition sensitive, and this is the sort of absolutist nonsense that I'm complaining about. Passwords are only as sensitive as the data they access.
This is false. Passwords are only as sensitive as all the data they access. Given that it's impossible for you to know what other data the user is protecting with the same password, you must assume all passwords are as sensitive as the most sensitive data a user might reasonably secure with that password.
Do I wish things were different, and that everyone on earth used unique passwords for every site? Of course. But I think you know that's never going to describe reality.
As someone who runs like a roleplaying site for like ten people (or several of them), I cannot be responsible for other people's bank passwords, nor should I be punished for daring to host websites without the huge added burden of cost of HTTPS.
The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.
Then really, Google's done you a solid. Now everyone using your site will know it's not as secure as their bank, and therefore, when their creds for your sites are stolen, and they get their identity stolen as a result, you can just say "Hey, everything told you it wasn't secure, not my problem"...
Again, this is not a productive or useful security attitude to take. We've made some grave privacy missteps with poor security advice time and time again, so simply saying "HTTPS is better and everyone should use it" is not inherently accurate. Especially when it's completely impractical with the tools available.
But what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?
Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections...
There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
I haven't heard of this bug, but regarding the decision to mark all HTTP as insecure:
Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling…
Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.
...for now. Marking all non-secured HTTP as insecure (duh) is in the pipeline - it seems.
This is actually a Good Thing - with HTTPS-friendly CDN and/or Letsencrypt, rolling out sites that are secure-by-default is now easier and cheaper than ever before.
You can avoid this by using `autocomplete='off'`. Most browsers will still allow you to autocomplete the field because many were abusing that attribute, but they won't save what you put in it.
That's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable.
Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.
My previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.
More broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days.
So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about?
You certainly can't get away with just wiring keystrokes to a field.
You can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)
CodeMirror has figured this out. When you type it's actually into a hidden input, and it updates a separate display.
Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
+1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.
you can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low<sarcasm/>...
> I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site.
Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?
I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways.
I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend:
https://www.cloudflare.com/ssl/