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: 4, Informative) by Anonymous Coward on Wednesday March 22 2017, @08:49AM (15 children)
We've been looking at letsencrypt at work and went with Verisign, because Verisign is cheaper. The thing is, with Verisign you get a certificate and can forget about it for a year or two, where as letsencrypt certificates expire so fast that you either have to hire someone just to update certificates, or use their horrible, root-requiring software that would make anyone who cares about security run away screaming.
And the protocol behind is just as horrible as the software, making it pretty much impossible to create a KISS letsencrypt client.
(Score: 5, Informative) by The Mighty Buzzard on Wednesday March 22 2017, @10:43AM (9 children)
Yeah, that's an exceedingly foolish statement. It's astoundingly simple to write your own cron job that can be run as any user to update your cert. If you are incapable of writing half a dozen lines of shell script, you should not be administering a server.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday March 22 2017, @03:16PM (6 children)
please post an example, for those of us that do not use your OS of choice.
(Score: 2) by tangomargarine on Wednesday March 22 2017, @03:43PM
If you are incapable of writing half a dozen lines of shell script, you should not be administering a server.
please post an example that is incompatible with my OS of choice.
FTFY ;)
Although now Bash On Ubuntu On Windows is somehow a thing. And Cygwin has long been around.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Touché) by Anonymous Coward on Wednesday March 22 2017, @03:48PM
if you're not using linux or bsd on your server you need to get off the fucking internet with your bullshit.
(Score: 0) by Anonymous Coward on Wednesday March 22 2017, @06:21PM
Windows Scheduler
powershell script
cygwin shell script
new linux subsystem with ubuntu flavored bash script
bat file script
OSX Timed Jobs
shell script
(Score: 2) by Justin Case on Thursday March 23 2017, @01:12AM (2 children)
Also, I know your request is not serious, but if it were, accepting a script from some random stranger in the Internet for maintaining https on your website is a sure sign of gross incompetence, the type that should get you fired and lifetime blacklisted.
(Score: 2) by The Mighty Buzzard on Thursday March 23 2017, @10:22AM (1 child)
You need to blacklist yourself then because I guarantee you have done this for your system init jobs. Unless you think sending in a pull request to $distro somehow makes them not a random stranger anymore.
Being able to read the script makes its origin irrelevant. Not being able to read a dozen or two lines of straight-forward shell scripting, now that should get you blacklisted from ever admining anything.
My rights don't end where your fear begins.
(Score: 2) by Justin Case on Thursday March 23 2017, @03:01PM
I hear your point but I don't consider a well known, long established, peer vetted signed code repository "some random stranger".
Yes, sometimes they do screw up, and it is widely discussed, and those who are paying attention know what to watch out for.
It is like buying a sandwich from the sandwich shop vs. eating one you found lying on the sidewalk.
(Score: 0) by Anonymous Coward on Wednesday March 22 2017, @08:27PM (1 child)
That only works if your service is one of a small handful of common services that listens on the standard ports or your DNS provider offers a remote access API and you're stupid enough to leave the keys to the kingdom on a remotely accessible server so that your script can access that API.
How would I use LetsEncrypt for the SSL cert on an IRC server listening on a non-standard port (there are no standard ports for an SSL IRC connection) when my DNS host provides no API for automated access to add/modify a TXT record? (If your answer includes something like "get a better DNS host" I'll take that as a "It can't be done and I'm full of shit" answer from you. Note the "stupid enough" section above.) I can find absolutely no way to make this scenario automated to work with LetsEncrypt. It will require manual verification of the host through a manually created DNS TXT record every three months, whereas I could pay for a cert and only have to worry about it every 3 years. One of these is a production-ready solution, the other is a toy useful for little more than testing use.
LetsEncrypt looks really good on paper. It would actually work if everything could be automated. In practice it's a bad joke. Perhaps in a few more years they will have dropped their 3 month expiration stupidity and it will be an actual workable solution. (I know, I know, don't hold your breath as stupidity tends to be forever and the LetsEncrypt administration got a 2for1 deal on their supply.) As it stands right now there are a number of things that just can't be automated.
(Score: 2) by The Mighty Buzzard on Thursday March 23 2017, @10:36AM
In fact, no. You don't even have to have a working service at all to get a cert. You only need access to run a script on the box the cert is for.
You seem to think the port of the service matters. It does not. The certbot script, for instance, will run its own tiny web daemon as necessary during installation/renewal if you don't have a web server already running on the box. The retrieved cert doesn't give a happy damn what service it is for.
As for adding records to DNS, it may be desirable but it is absolutely not necessary to get an IRC server up and running with a valid and verifiable cert.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday March 22 2017, @01:47PM
LetsEncrypt's certs are intentionally short-lived to discourage manual setups. It's not that difficult to setup a user that only has permissions to communicate with the LetsEncrypt servers to verify ownership of the domain and update the keys. Then you just set that up and forget about it.
(Score: 2) by theluggage on Wednesday March 22 2017, @01:54PM (3 children)
where as letsencrypt certificates expire so fast that you either have to hire someone just to update certificates, or use their horrible, root-requiring software that would make anyone who cares about security run away screaming.
The whole point of LetsEncrypt is to make it usable by people who maybe don't know much about security, and certainly couldn't set up groups and permissions on their server that would enable LetsEncrypt to do what it needed without root (chmod -R o+rwx /var/www anybody?). Having the client run as root is one of those trade-offs that happen in real life. In the age of virtualisation and containers, "root" on your webserver shouldn't be able to do much more than delete your website, anyhow.
Anyway, the "official" LetsEncrypt client is more of a proof-of-concept. The real target audience of LE is people who run their wordpress sites on point-and-drool webserver managers like Plesk, CPanel etc. the latest versions of which already have add-ons implementing the LetsEncrypt protocol, making turning on https a check-the-box option.
If you're smart enough to run your own server without crutches, then you're probably smart enough to tweak one of the available LetsEncrypt client scripts to work with your security model. Or, as you say, pay for a 2-year "traditional" cert... People really seem to be expecting to get something for nothing when it comes to SSL certs...
In the past, I've used free, 1-year StartCom certs - frankly, even using LetsEncrypt manually is easier than that. For one thing, you don't need to be able to receive mail on "webmaster@yourdomain.com" and fish out the verification email from the spam trap...
(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?)