You’re thinking of an old-school SSL certificate. LetsEncrypt is totally free. Besides, you can find SSL certificates from top providers for dirt cheap.
That’s just called self-certification, is it not?
Does that still show the green address bar?
EDIT- ok so apparently it gives DV, which is the green padlock, but not EV, which is the green bar.
It’s different to self-certification because LetsEncrypt functions as the CA. Self-signed certificates don’t have CA’s recognised by browsers, and thus come up as untrusted.
LetsEncrypt certs will still show the green address bar, they’re considered domain verified.
Another trivia when running an SSL sites is you have to make sure all resources (media, javascript, css) are provided over SSL too.
So if ANY members posted image from non https page, the padlock will be broken.
Yup so unless we start dealing wtih banking details and making money transactions on here there seems little point in rushing to SSL. The added overhead in CPU resources and the extra cost - no matter how trivial are still something that needs to be considered.
I’d usually push people to SSL and turn off TLS1.0 etc but considering what data is on here I’d be more concerned about my username/email/password combo getting leaked. Apart from that I don’t really give a hoot.
New forum update, check it is SSL compliant.
Any funky scripts, re-write for SSL compliance.
Someone posts a link to imgur via standard http, SSL broken.
Sure the traffic to the site will still be good but the non techy people will see a ssl warning and worry.
Ah yes, very good point, I forgot about this. And that will definitely be the case here with externally hotlinked images all over the place.
I really hate how the browser makers (Chrome and Firefox especially) try to force the hand of webmasters with their scary icons about an “insecure” site just because there is a password input box on an HTTP:// page. I also think it creates a false sense of security when they add that nice green “Secure” padlock icon on HTTPS:// pages. SSL doesn’t magically make a site more safe. It does mitigate the possibility of snooping and man-in-the-middle attacks along the route between the web browser and the destination server. But it doesn’t protect against bad server administrators, bad server-side coding, or bad PC (and now mobile) security practices. A compromised server via an un-patched vulnerability or insecure configuration at the core server operating system level or the web services level (web server / server-side scripting language / database / cache mechanism) can be extremely insecure. Take Yahoo! as an example of that… and yet it’s still blessed by a nice green padlock in the browser’s URL bar. Or think of the damage that can be done if you have malware running a keylogger on your PC— no amount of encryption will prevent it from logging your keystrokes and ex-filtrating your nice complex password to the attackers as you type it into the trendy SSL secured site with its green padlock. There are even highly specialized malware that keep track of how much money they’ve siphoned out of your bank account and are capable of modifying the HTML that your (SSL secured) bank site spits out at a browser level in order to add back the stolen amount to the balance totals and hide transactions from the history so you don’t realize what’s going on. Or simpler yet: a single phishing email or social engineering slip-up could lead to you revealing your password to a scammer so that (s)he can enter it into the SSL secured site. The brutal truth is that the private encryption keys and the raw passwords and the raw data must exist somewhere, so if the hackers can’t get to your data while it’s “on the wire” during transmission, they’ll get the keys and/or the raw password at whatever level they exist at, even if it’s in your brain, via social engineering (i.e. “tricking you”).
So as far as BLF is concerned, I do take security very seriously at the server OS, web services, and forum software level. I always try to keep the entire software stack patched for security vulnerabilities, and my resistance to migrating to the popular proprietary/commercial forum software offerings (vBulletin et al.) is largely due to their deplorable history of security vulnerabilities. But as was mentioned earlier in this thread, BLF is not a financial institution, so I don’t see a lot of value in SSL, which is mainly useful to mitigate the risk of password snooping and modification of the final web page content during transmission. Just be sure to NEVER use your BLF password for any other web site or service that you care about, and in general ALWAYS use strong and unique passwords on all important sites, especially those significant to your financial and reputation/personal integrity. And don’t use insecure operating systems or devices to log into any online account or service that you care about.
OK, I’ll get off my soapbox now. 
Have fun!
There is absolutely no point in encrypting anything other than the login, and that should be doable without using https. The data is accessible to anyone. Encrypting the transfer only uses more resources for no reason. Well, ok it does prevent someone intercepting your communication and spoofing the web site, well assuming the user doesn't do what we usually do and click "yeah whatever" when the security warning pops up. I don't see it as a big risk though. If it is desired just for key verification, it should possible to do it without encrypting all the data transfer.
I checked, it actually shows a green padlock, not the green addres bar. You need EV to get the green address bar.
That’s still good though, I’m gonna use this on my site, thanks 
EV is much more pricey. Hundreds up to thousands dollars for sure.
And you won’t need that. EV is for company or entity which should be validated.
Personal can’t get EV. For your own website(s) you can use DV, more than enough.
And yes, it’s easy to set, especially if you run your web serve under *nix OS.
Just use their own command line and you’ll done in minutes.
Best thing is you can generate (ask) almost hundred certificate for your own domain name.
And it’s not limit to only www, but other sub domain will do. And, it’s free.
[quote=sb56637]
I can live with that… :sunglasses:
But, Yahoo surely is another story, isn’t? Doubt that’s about ssl… LOL.
Yep, absolutely. But that was my point: they use SSL but still had bad security practices, resulting in some of the largest data ex-filtration in history.
I’m glad the forum Admin knows his stuff :+1:
I’m a web developer, and, while I generally advocate for SSL, I don’t think it’s necessary for this site. The biggest risk comes from users who use the same password for multiple sites.
All of the users just really need to use a unique password and a password manager to keep track of their unique passwords. Keepass, Lastpass, and 1Password are all potential options.
We have used Keepass for many years. It is a truly great way to keep track of all one’s passwords. Then all you need is one very random, mixed character, 16+ character master password.
Well, I’d have to disagree with you there, it really is trivial actually…
Not sure if I see any reason to switch though, although Google might punish you for not having it - both in search hits and soon (?) in Chrome as well I think.
Pardon my apparently stupidity, but exactly what are we trying to protect? Anyone who wants to see what is on BLF can simply register and presto, it is all visible. You use encryption to hide things from prying eyes that otherwise might be up to no good. I regard anything posting on the BLF as essentially public, since there are no fees or other restrictions on membership that I am aware of. If you want to hide something, then don’t post it on a board!
Above all, it would be to protect the password you type in to login. But then again, it’s not a banking website, so I don’t see that as an imminent risk if it’s not encrypted.
The other use of encryption is to prevent some middleman from intercepting the connection and changing what comes from the server before it reaches you. So for example a site that gives the current state of alert for a certain threat could be intercepted while it’s “on the wire” in transmission and the attacker could change the threat level to give false information. Or somebody could intercept the contents of a news site while it’s in transmission to make it say that a certain country has initiated a nuclear attack on another state. Again, given the topic of flashlights, not really a risk.
I actually already set up LetsEncrypt once for a temporary project on this site. It wasn’t extremely hard, but it also wasn’t easy, due in part to the fact that I use a non-standard higher performance server stack (Nginx + PHP-FPM) that requires special configuration to integrate with this forum engine.
Well, I’ve never used LetsEncrypt so I don’t know about that part. I was thinking of a regular SSL setup in Nginx, which is not very complicated if you have a working non-https already. Either copy existing virtual host config to a new file, change port and add a few lines of ssl-config, or make a clean ssl config and use the http site as proxy server. I can barely remember how to configure apache nowadays as all servers I manage are on nginx, just so much nicer to work with.
While https MAY give users the impression of security, it may be prudent to remember the panic and consequences of the heartbleed bug.