Piano World Home Page Forums Our Most Popular Forums Adult Beginners Forum https

I do IT as well, currently, and I know a little about all this but not enough to comment about it here and certainly not in respect of PHP, which is not my area. But at the end of the day it's a piano forum, so anyone who understands IT can also assess the risk, surely, and realise that this application is extremely low risk?

When I first joined PW, I was a greenhorn (I'd only just bought my first computer - in 2010) and stupidly used a password that anyone could think of within a few seconds. And PW sent me back the password I'd chosen to my email address to confirm my membership. Then someone hacked into my email address to send spam from it to all my contacts......

After which, I changed all my passwords (yes, I stupidly used the same stupid password for PW as for my email address - this post is full of 'stupids'...... ) to very long obscure ones using every symbol and letter and number and case on the keypad, which I calculated would take the most powerful current computer about one million years to hack into, and which only I can remember (which is clever ). They're not written down or printed or recorded anywhere, except in my grey cells.

Since then, everything has been safe, but I still periodically get sent spam from friends' email addresses, when I then smugly send them emails to tell them that they've been hacked into and need to change their passwords ASAP into something gibberish that only they can remember. Which from a computer greenhorn is clever advice, even if I, a greenhorn, say so myself......

I know it's low risk, and you know it's low risk. But almost every browser now warns you when you go a site that is not secure. My browser puts a red "Not Secure" message to the left of the address bar and a big red X. How many people will be scared off by that? How many will think that PW is some kind of scam or will steal their info?

Sam

Frank, here's a different suggestion:

Just convert the forum to HTTPS but leave all the existing image references as they are.

Yes, that will generate "mixed content" warnings, but those warnings (as long as the only mixed content are HTTP images embedded in HTTPS pages) are much less intrusive now than they used to be. Long gone are the time of Internet Explorer 8 (and older), where the mixed content warning actually popped up as a dialog that would disrupt the user.

I just tested with Chrome, FireFox, Edge and Internet Explorer on Windows. All of them show the mixed content only as a subtle difference in the icons in the address bar, as you can see here (images on the left are with normal HTTPS content, images on the right are with mixed content):


(BTW, IE shows this on the right of the address bar, the others on the left. All of them also log a warning to the development console.)

I don't have a Mac or Linux to test, but in Safari on my iPhone, the difference is only in a missing lock-icon in the address bar. (You can try this out yourself at https://www.mixedcontentexamples.com).

So there really is no need to fear mixed content warnings, like one had to in olden times.

Therefore I suggest to simply move the site over to HTTPS and leave the original HTTP image URLs as they are. Users will likely not even notice the mixed content warnings but the login will finally be encrypted (just make sure that the login page itself does not contain any mixed content, so that it is shown as fully safe).

Yes, anyone who has the silver, gold, platinum, etc under their name has paid.

I used to do a small bit of hosting on the side before I decided to give my customers notice that I was going to retire and helped them move to other hosting providers. I found that switching the the NGINX web server was more efficient, but it also has what is known as the proxy_pass module.

You can set a configuration up so that it processes all incoming requests as https, but for certain urls that match you can collect the requests and convert them to http (for instance your images - provided you can tell from the url that it needs to go to the image server)

These days, you can also get FREE SSL certificates from Lets Encrypt (see https://letsencrypt.org/). I have these set up along with fully automated renewal every 90 days (or rather just under - certificates expire after 90 days) on my personal web site.

Why would anyone get annoyed, SP? I’ve worked in IT for close on 40 years, and I was offering my professional opinion that the procedure that Frank described seems straightforward to implement.

It isn't a question of the costs, it's a question of the viability.

There are way too many variables here.

I checked with our IT guy from our hosting service, Ken is very knowledgeable, especially with server environments and databases.

His reply...
This ignores the fact that many many sites fight against auto-downloading by
other sites (ie scraping).

Try posting an image from somewhere to facebook - quite often you dont get
what you want at all, just a link to/logo from the site's main page or
something else. Quite often they dont even expose the image url, you cant
right click on the image to do "copy image location", they've hidden it in
javascript so that it 'constructs' the image display dynamically after the
page is loaded, making it very hard to figure out where the image is being
loaded from (the raw url).

Furthermore, user agents and cookies will be tested and what not to ensure they match,
or even that your previous requests were from a page related to the image for eg.
We used this principle to defeat russian scrapers for a client once who never downloaded
things in order, but from multiple different pages/sources randomly over time.

It might work for 50 or even 80% of the sites out there, but the rest will
be broken images.

The best solution is what most sites do, force the user to upload the image they
themselves downloaded from the website in question. If they need to be exceedingly
clever to get that image they want, good for them -- that's very hard to code into
automatic code.

He's right that for some subset of websites (25%? depends on which sites, large
social media sites or just a random personal website?) a proxy will work but it
wont work for all sites, not even close. When it doesnt work you and I have
to support it.

And...
I approached the developers who work on the UBB about this. Here is their answer:
=====================================================
Development on UBB.threads was abandoned in 2009 when Rick sold UBBCentral and UBB.threads to UBBSystems, SD had been hired on to contribute security fixes and some feature additions, but until Isaac and I started development on 7.5.9+ in 2015 the product had seen little activity (there was a 2 year gap between 7.5.8 and 7.5.9).

Currently, a proxy to masquerade 3rd party non-HTTPs image attachments as a local HTTPs URL isn't planned at all; the time to develop, test, test security, and maintain a database would be quite cumbersome and would push the focus of what development time we have towards UBB.threads in directions that would be better focused elsewhere (such as compatibility with newer builds of PHP and MySQL, furthering web standards, UI cleanup, etc). A new tool would require parsing the database for 3rd party links, building a database of these links, writing a script to process new requests to those links, updating all previous posts for the parser, etc. Not to mention, a large (your forum is huge) forum would end up with a sizable database table to hold this additional content.

Our official stance on the matter is that the existing links in the database need to be updated, and 3rd party content reigned in (such as having users upload their images directly into their posts vs using 3rd party services, and forcing them to not have images in their signatures and to upload their avatars to your site vs hosting externally). If the 3rd party resource doesn't offer an HTTPs option, its their shortcoming.

Isaac's guide (the original post in this thread) was created to provide forum owners (who know what they're doing) with directions towards converting their forums to 100% HTTPs, anything outside of UBB.threads (such as user submitted content from 3rd party websites) falls under Step #6 of his guide:

Originally Posted by isaac
6) Update all external plugins to ensure they are HTTPS compliant (Sharaholic, Twitter, Facebook, YouTube, UBB Custom Tags, and, if your website contains non-UBB.threads content, all those internal site links - trust me you won't find them all in a single pass)

I guess there’s a question of how much that matters, but it would be frustrating for users browsing old threads. As I said, I’m not an expert by any means, but this came up with a site I’m involved with and it was possible to make a change to the headers that means it can now handle images over http. CSS coming from connected services running as http is still blocked, but images are now OK. But like I said, I know very little about PHP. Ours is ASP.NET, and I don’t know if that makes a difference.

Crossed posts. And I don’t think you should be having to explain your reasoning for decisions taken on your site in such depth in order for people to accept it.

The thing I don't get from Ken's response is that if sites block 3rd party linking, that's already "broken" on the forum. Nothing changes there. We are already in the situation where there are very few 3rd party image sites that are easy to link in to forum posts. A proxy isn't going to solve that problem, it would purely be to allow insecure links to not show up as mixed content.

As to UBB's response, I think I agree, if you go to HTTPS, just don't look back. If people have broken image links to 3rd party sites in old posts, so be it, will anyone really care? I personally think the benefits of HTTPS outweigh breaking some old image links (login security and direct message security specifically, as well as not scaring away potential new users.)

Anyway, I'm not going to rage quit the forums or anything, and I realize there is work involved in switching to HTTPS so I'll shut up after this post

And then there is this from one of the UBB developers....



The serious downside to a simple proxy approach is that you are routing all external resources through your own server/systems. Which is not only a liability, but also can get rather costly. It adds complexity to the page for no good reason. It also defeats any CDNs which are suppose to route to near servers or balance to idle ones.

With simple proxy script, anything can be included and will be delivered from your domain.

EXAMPLE:
http:// www .THEIRSITE. com/virus.jpg
WOULD BECOME:
https:// www .YOURSITE. com/?imgsrc=http:// www .THEIRSITE. com/virus.jpg

The security now becomes even worse than without the use of a pseudo-SSL proxy script. With this, your site could appear to be hosting malicious files.

Expanding on that, if a random user would copy that new SSL link with "your domain url + malicious file link" across the web, you get the "site credibility ding" for "hosting" the malicious file, even though you are only passing it through as a third party. The random user could also apply any link to the proxy tool they wanted to add.

Real-time tracking of all HTTP URLs and requesting them again if SSL connection failed is highly inefficient and overall sounds like a bad idea.

Its highly unlikely that there are going to be any core workarounds of this type written for UBB.threads, especially because the vast majority of websites today use SSL anyway, and the rest can either get on with the program or have their content treated as a second-class citizen. UBB.threads 7.7.2 provides a optional forum setting to replace hotlinked insecure embedded images with a plain URL that the end user can click through to view if they choose to.

That said, nobody is going to stop you from adding any sort workaround with custom code or server modules. good luck.

OT here, but just wanted to mention the main PianoWorld page is giving off this error:

The security is not worse, it's better

* others can't see I'm downloading the virus
* Others can't see my passwords
* Others can't track me
* I maybe able to use Tor browser for added security
* Both the old and new situation allow download of virus.jpg so it does not make a difference in that respect
* if the browser takes virus.jpg as a EXECUTABLE, then the browser is really rotten anyway, both in the old and new situation

I'm not quite following. Are you answering a specific question here? Can we add custom code to the server modules? How?

Thanks Tyrone, just got back into the office, working on this now.

Computer security is only a hobby for me but didn't TLS replace SSL in like 1999?

TLS first arrived in 1999 but SSL2 and SSL3 were't deprecated until 2011 and 2015 respectively. However they are vulnerable and deprecated so you shouldn't be using them and, if you do, there will be lots of difficulties with browsers complaining.

That said, when folks just say 'SSL' without being specific they are usually referring generically to either SSL or TLS, which after all is itself based on SSL3 and therefore not so very different.

Frank does avoid some issues by staying with plain http :-)

If non-https is the road-blocking and insurmountable issue for a secure forum then I'd rather see that insecure content blocked. Just show the insecure link and then the user can decide to follow (click on) it