[2018-07-30] "Not secure" browser warnings, all is normal

Man_Without_Shadow · 2018-07-31T04:16:57.000Z

He didn’t say it was secure, just that it wasn’t necessary to be secure…as we don’t process transactions on the site or share detailed personal information.

Joshk · 2018-07-31T04:54:51.000Z

I understand SB. Thanks.
I vote for SSL though. It’s fast, free, and renews itself. I’d love all sites to use it.

//Install LetsEncrypt//
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

//create certificates
certbot —apache -d example.com

//Test the renewal process. It will keep itself renewed.
certbot renew —dry-run
certbot renew

//See certificates
/etc/letsencrypt/live

everydaysurvivalgear · 2018-07-31T04:59:51.000Z

Its Google they updated the verification process and if a website doesn’t have a SSL its flagged as unsafe they want all servers/websites to use HTTPS. Is the issue only with Chrome?

Henk4U2 · 2018-07-31T07:02:26.000Z

Firefox gives me a warning when I log in.

raccoon · 2018-07-31T07:13:33.000Z

I use a lesser known browser, Opera.

I haven't received any warnings, so far, that I remember.

CrashOne · 2018-07-31T07:29:42.000Z

Joshk:

I understand SB. Thanks.
I vote for SSL though. It’s fast, free, and renews itself. I’d love all sites to use it.

//Install LetsEncrypt//
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

//create certificates
certbot —apache -d example.com

//Test the renewal process. It will keep itself renewed.
certbot renew —dry-run
certbot renew

//See certificates
/etc/letsencrypt/live

The problem is not the installation of a certificate, but all the other services that are only available through http. You will get an unsecure/mixed content loaded message (there is a workaround: Load all external content through BLF server).

But I agree, https is the way to go: https://doesmysiteneedhttps.com

Flashy_Mike · 2018-07-31T07:46:24.000Z

I’d prefer HTTPS at least for log in data.

Barkuti · 2018-07-31T08:04:28.000Z

raccoon city:

I use a lesser known browser, Opera.

…

Opera uses a Chrome engine.

And G00gl€ can $#%& my @#%$ with the security stuff and whatever, by the way. They get bully with sheesh and I hate that. I've posted a few messages in the G00gle help forums and its surprising to see how awkward and @#$% is the code/engine which runs them. Its a unbelievably freakin' mess.

G00gl€, Appl€ and the dimwits feeding them blindly need a flogging.

Off-topic again, sorry.

Cheers ^:)

CRX · 2018-07-31T10:03:22.000Z

Man Without Shadow:

He didn’t say it was secure, just that it wasn’t necessary to be secure…as we don’t process transactions on the site or share detailed personal information.

What about our personal messages?

sb56637 · 2018-07-31T11:58:00.000Z

CRX:

Man Without Shadow:

He didn’t say it was secure, just that it wasn’t necessary to be secure…as we don’t process transactions on the site or share detailed personal information.

What about our personal messages?

In theory there could be personal information in PMs. But when it comes to “web security”, there are a huge number of factors that are often confused:

1. **The risk of malware on your device that logs your personal data and “phones home” to the attacker.** This is by far the most common attack.

SSL (https://) does NOT protect against this risk.
As the administrator of BLF, I can’t do anything to protect users from this risk.

2. The risk of somebody tricking you into revealing your password(s) and/or financial information by pretending to be somebody else. This is also a common attack vector.

SSL (https://) does NOT protect against this risk.
As the administrator of BLF, I can’t do anything to protect users from this risk.

3. The risk of somebody hacking into the web server and installing something malicious that infects visitors. This is also relatively common.

SSL (https://) does NOT protect against this risk.
As the administrator of BLF, it is entirely my responsibility to protect my users against this sort of attack, and I take it very seriously. There are a huge number of best practices for administrating a web server that I adhere to to keep the server as secure as possible. Usually if there is a sudden unplanned maintenance window for BLF, it’s because I’m applying security patches.

4. The risk of somebody hijacking the webpage data while it’s in transit “on the wire” between the web server and the visitor and modifying and/or stealing the data. This is not common.

This is what SSL (https://) is designed to protect against.

So I don’t see any imminent risk for BLF users by not immediately implementing SSL. I’m sure I will eventually, but it’s not a priority. A frequently overlooked downside of implementing SSL is that it requires significantly more server resources to encrypt and decrypt all the traffic. The BLF server is already under rather heavy load most of the time, and SSL would surely push it over the edge, requiring another server upgrade or even a migration to a different host.

atbglenn · 2018-07-31T12:21:48.000Z

I use a unique password generated by Lastpass for each and every website. That said, I don’t give out personal information on websites that are not secure. Plus, I use a VPN. I’m no expert, but I think I’m a couple of steps above the average Joe.

Joshk · 2018-07-31T14:07:38.000Z

My home ISP injects advertising into web pages that are not encrypted.
My cell ISP severely reduces the quality of the video clips I text out if they can process them. (non iMessage encrypted deliveries)

If they have the balls to do that, they have the balls to profile me based on comments I post on BLF. For that reason I wish BLF had SSL.

Barkuti · 2018-07-31T14:53:00.000Z

Joshk:

My home ISP injects advertising into web pages that are not encrypted.

My cell ISP +severely+ reduces the quality of the video clips I text out if they can process them. (non iMessage encrypted deliveries)

If they have the balls to do that, they have the balls to profile me based on comments I post on BLF. For that reason I wish BLF had SSL.

I'd tell your ISP to lick my @#$%.

With regards to advertising I have it blacklisted by default on Android thanks to AdAway (root). It can also be done by other means on Windows (done it) or Linux machines.

Adverts are an unnecesary pester illness in my honest opinion. I never buy based on advertising alone (if at all), but rather on my own needs and objective reviews.

Cheers :-)

Joshk · 2018-07-31T14:56:30.000Z

I have NO choices for ISP. If I want home internet, there is only one choice.

bmengineer · 2018-07-31T14:59:40.000Z

sb56637:

Since BLF doesn’t process any sensitive information

That’s just not true. At very least, BLF processes email addresses during registration. If my contact information doesn’t fit your definition of sensitive, what more do you want?

It’s not good practice, but I’m sure enough users also use a generic password for this site as well - that could definitely be considered ‘sensitive’, depending on what else it’s used for.

Joshk · 2018-07-31T15:04:13.000Z

How much money would you need to raise to add more processing resources to your system SB? I would chip in yearly. Many would. I would like to see BLF grow.

ToyKeeper · 2018-08-02T23:14:33.000Z

Joshk:

//Install LetsEncrypt//
add-apt-repository ppa:certbot/certbot
…

If I recall correctly, BLF runs on a SuSE-based platform. But I might use your cert tips for a project I’m doing… thanks!

(mostly, I just need ssl for a bit of a toy project, to enable secure cross-site data transfer)

I would also find it useful if BLF acted as an oauth2 (or similar) identity provider, which requires ssl, so I could slave other sites/services off it using a single sign-on. I’ve been tempted to add some kickstarter-like features to make community projects easier for everyone. But even if BLF had identity provider features, I’m not sure I’d actually have enough time and motivation to do the rest. Too many projects.

CrashOne:

The problem is not the installation of a certificate, but all the other services that are only available through http. You will get an unsecure/mixed content loaded message (there is a workaround: Load all external content through BLF server).

This would create a whole lot of warnings and/or break a lot of image links. Like, I’d probably have to add https to my site (finally) and edit every post I’ve ever made with images. Which isn’t really all that much of a problem for me personally, but in a site-wide sense it would be pretty disruptive.

The server-passthrough workaround could reduce disruption, but it’s even more complication and more server load for sb to deal with. And some of the sites I’ve seen with that method end up breaking half the time anyway.

sb56637:

The risk of somebody hijacking the webpage data while it’s in transit “on the wire” between the web server and the visitor and modifying and/or stealing the data. This is not common.

This is what SSL (https://) is designed to protect against.

So I don’t see any imminent risk for BLF users by not immediately implementing SSL. I’m sure I will eventually, but it’s not a priority. A frequently overlooked downside of implementing SSL is that it requires significantly more server resources to encrypt and decrypt all the traffic. The BLF server is already under rather heavy load most of the time, and SSL would surely push it over the edge, requiring another server upgrade or even a migration to a different host.

It’s certainly an open attack vector, but it hasn’t been a problem here that I’m aware of. There are probably people in the NSA and KGB quietly collecting our login data and stuff. Large-scale route hijacking attacks have been found in the wild for at least the past five years, ever since people noticed BGP attacks routing traffic through Iceland in 2013.

But if they were to ever actually use that data, we’d have much bigger things to worry about. And in the mean time, ssl is a significant cost and complication for BLF.

…

TL;DR: What sb56637 said. Https should probably happen eventually, but it’s a major PITA.

Joshk · 2018-08-02T23:50:44.000Z

ToyKeeper:

This would create a whole lot of warnings and/or break a lot of image links. Like, I’d probably have to add https to my site (finally) and edit every post I’ve ever made with images. Which isn’t really all that much of a problem for me personally, but in a site-wide sense it would be pretty disruptive.

You don’t have to force https. Just answer “no” to the force https option at install and nothing changes as far as the public sees. Leaving SB and some users free to doddle around with the https.

Joshk · 2018-08-03T00:28:43.000Z

As the very title of this thread makes clear, browsers are on the verge of out-right blocking users with a red screen and scaring them away if the site is not https. Requiring SSL really is something that is going to happen soon. There are been years of marching, and some companies are now pushing hard.

ToyKeeper · 2018-08-03T00:51:13.000Z

Joshk:

You don’t have to force https. Just answer “no” to the force https option at install and nothing changes as far as the public sees. Leaving SB and some users free to doddle around with the https.

Oh, cool. That certainly helps.

(in case it wasn’t obvious, I’ve been dragging my feet about https for a long time and haven’t really dived in yet… last time I really looked at it was before it was compatible with name-based vhosts, so I didn’t implement it then and haven’t gotten back to it since)