News for hackers. Stuff that matters.
Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Sunday January 22, 2017 @04:56PM (#13457792)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by Karunamon on Sunday January 22, 2017 @05:55PM (#13458150)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by jaas on Sunday January 22, 2017 @09:09PM (#13459156)
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.
Re:Chrome 56 will mark HTTP pages with password fields as no... by nommm-nommm on Sunday January 22, 2017 @06:03PM (#13458191)
HTTPS is to ensure privacy and integrity for the end user not for the benefit of Google and banks.
Re:Chrome 56 will mark HTTP pages with password fields as no... by no_wizard on Sunday January 22, 2017 @09:40PM (#13459290)
https://certbot.eff.org/

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.

No Excuses. EFF did us a solid

Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Sunday January 22, 2017 @10:43PM (#13459593)
Except the part where if you're using shared hosting and don't have the ability to run this software on your server, it's useless as I said.
Re:Chrome 56 will mark HTTP pages with password fields as no... by protomikron on Monday January 23, 2017 @01:00AM (#13460157)
One might also conclude that the hosting provider is useless.
Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Monday January 23, 2017 @02:37AM (#13460542)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by tortasaur on Monday January 23, 2017 @10:55AM (#13463018)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Monday January 23, 2017 @11:20AM (#13463232)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by icebraining on Monday January 23, 2017 @02:12PM (#13464957)
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.
Re:Chrome 56 will mark HTTP pages with password fields as no... by sofaofthedamned on Monday January 23, 2017 @04:51AM (#13461044)
Then use one of the offline challenges.
Re:Chrome 56 will mark HTTP pages with password fields as no... by icebraining on Sunday January 22, 2017 @07:42PM (#13458732)
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?
Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Sunday January 22, 2017 @08:54PM (#13459068)
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.
Re:Chrome 56 will mark HTTP pages with password fields as no... by stanleydrew on Sunday January 22, 2017 @09:08PM (#13459152)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Sunday January 22, 2017 @10:10PM (#13459424)
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.

Re:Chrome 56 will mark HTTP pages with password fields as no... by Vendan on Monday January 23, 2017 @12:47AM (#13460096)
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"...
Re:Chrome 56 will mark HTTP pages with password fields as no... by rimantas on Monday January 23, 2017 @08:46AM (#13462098)
You should not be responsible for running any of the sites with this attitude.
Re:Chrome 56 will mark HTTP pages with password fields as no... by ocdtrekkie on Monday January 23, 2017 @09:02AM (#13462186)
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.