The operator of a website that accepts subscriber logins only over unencrypted HTTP pages has taken to Mozilla's Bugzilla bug-reporting service to complain that the Firefox browser is warning that the page isn't suitable for the transmission of passwords.
"Your notice of insecure password and/or log-in automatically appearing on the log-in for my website, Oil and Gas International, is not wanted and was put there without our permission," a person with the user name dgeorge wrote here (the link was made private shortly after this post went live). "Please remove it immediately. We have our own security system, and it has never been breached in more than 15 years. Your notice is causing concern by our subscribers and is detrimental to our business."
Around the same time this post was going live, participants of this Reddit thread claimed to hack the site using what's known as a SQL injection exploit. Multiple people claimed that passwords were stored in plaintext rather than the standard practice of using cryptographic hashes. A few minutes after the insecurity first came up in the online discussion, a user reported the database was deleted. Ars has contacted the site operator for comment on the claims, but currently Ars can't confirm them. The site, http://www.oilandgasinternational.com, was displaying content as it did earlier at the time this post was being updated.
As a member of the Mozilla developer team pointed out in reply to the complaint, both Firefox and Chrome routinely issue warnings whenever users encounter a login page that's not protected by HTTPS encryption. The warnings became standard earlier this year.
The site in question appears to be completely offline at this time.
Source: ArsTechnica
(Score: 2) by urza9814 on Wednesday March 22 2017, @10:08PM (2 children)
I'd much prefer if it was by email actually. At least as an option. The problem I have with LE is so far I haven't found a way to get it working that doesn't require reconfiguring my NAT, reverse proxy, firewall, and DNS resolver. Of course, I haven't actually sat down determined to solve that yet, it's more of a "What do I need to do to get it renewed this time...?" But the problem I have is that, for example, there's no way to get the mail server approved unless there's also a web server on the same subdomain. I don't WANT web servers running on the mail server, I don't want port 80 open at all. And the scripts to renew the certs seem to throw an error if it can't access the server locally even if it can be accessed remotely -- so while external requests have to hit the firewall box and therefore could be routed through the reverse proxy to my main webserver for approval, the internal clients don't use that reverse proxy, they use the local DNS settings, so I have to reconfigure my DNS resolver to point the mail subdomain to my webserver or I get an error. I've considered configuring EVERYTHING to use the reverse proxy but the pfsense docs advise against it. I could maybe use a hosts file but I hate using those...I'd rather configure the software than the system it's running on and I want to keep all routing logic at the routing layer rather than spewing it across various host files...
(Score: 2) by theluggage on Thursday March 23 2017, @01:41PM
But the problem I have is that, for example, there's no way to get the mail server approved... I don't WANT web servers running on the mail server, I don't want port 80 open at all.
Well, there's also the option to validate by adding a token to the DNS record for your server, which doesn't require a web server. However, you have to remember the primary purpose of Let's Encrypt:
From the Let'sEncrypt website:
The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention
...i.e. the goal is the point-n-drool "enable https" checkbox on your web service control panel (probably next to the "create Wordpress site" button, so moderate your expectations of security!) so if you're not using it to enable HTTPS on a webserver then it's not surprising that it doesn't suit your purposes. Other certificate providers are available.
(Score: 0) by Anonymous Coward on Friday March 24 2017, @06:38PM
You can automate the whole process of port opening, running the web server and firing up the certbot script and finally closing the port again, with a cron job.
This way, you minimize the time that port is open, therefore the risk taken is only for that period of time (seconds?)