SoylentNews is people
SoylentNews
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: 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.