There is a good news and sort of a 'bad' news. But the good news first: now it looks like HTTPS is working fine! (Thanks much for your efforts
@ImageMaker!
). You don't have to care about putting the "/xf/" suffix everytime now, because it was a temporary workaround which is not needed any more.
But there is the 'bad' news also, which is related to what windar asked above:
When I log on to the main page, it is secure. But then when I go to a thread, it says not secure. This happens in both Chrome and Firefox.
I'm sorry but I was wrong about one detail in what I posted in this thread. I thought only those resources (e.g. images, scripts, etc) which originate from the main page (i.e.
https://cruxforum.com) that count when the browser determines if the website is perfectly secure. But it turns out that even external resources affect the result, like the case with an externally hosted signature image which is linked using HTTP (not HTTPS) protocol.
That is why the problem windar is reporting happens. But as far as I understand, the actual security 'risk' of mixing passive resources (in a word, images or videos, rather than scripts) is quite marginal at best. Still, it's an eye sore to see that warning message so we can probably take a measure to deal with that problem. There are several approaches we may consider for that:
1. Replacing insecure images used in user contents.
This is the ideal, but probably a bit impractical solution. However, even if we need to take another approach it's still a good practice to follow, so I'll mention it first.
Even though it
may (just 'may') not be
@Barbaria1 who caused the infamous 2013 crash, it turned out it was indeed she who (partly) caused the problem windar reported!
She is using a banner image in her signature which is hosted on an external server. But the problem is that it's using the insecure HTTP protocol, so basically when everytime people see her post in a thread, the browser report the website as partly insecure.
But just hold your pitchforks folks, because it's not only her who's responsible for the message.
@Eulalia also uses such an image, for example, and there might be many others as well. And I only mentioned those names to bring this matter to their attention (the solution to the problem will follow soon, so please read on.)
The same goes for any image a user may embed in one's post. As such, it's probably impractical to track down all those members and their posts to fix such issues one by one, so I'll mention an alternative below. But it's still a good practice to use only secure resources, so I'd like to encourage all our members to follow the below recommendations:
@everyone:
If you use an image in your signature, ensure that the URL starts with https://, not http://. In case it's HTTP, try changing it to HTTPS and see if it works that way. But in case it doesn't (as with Barbaria's case), try uploading the image to a more secure server (e.g. imgur.com) and link it using the HTTPS URL.
The same applies to images you may use in your post. If you are embedding an externally hosted image, ensure that it uses HTTPS using the above mentioned method.
(EDIT:
@Eulalia Maybe we could mention this advise in our forum rules?)
2. Using a Cloudflare magic
Fortunately, it looks like Cloudflare also provides quite a neat feature which may be used to deal with this problem for free. Basically it automatically changes such insecure URLS before it serves the content. But my hunch tells me that it will work probably for 80% of the cases, but not for such a case like Barbaria's where the linked server itself does not support HTTPS.
But as it will be rather impractical to track down all the cases one by one, I suppose it's a much better to let Cloudflare to fix most of the problems while we can deal with the few remaining exceptions.
@ImageMaker Could you try just one more thing to fix this problem? Login to your Cloudflare console and enable "
Automatic HTTPS Rewrites" option as shown below:
(Image hosted on an external host)
3. Using a XenForo magic
It looks like XenForo also provides its own 'magic' to help its users dealing with the problem. It's called "Image Proxy" which is included in
the guide I linked in my previous post. However, I actually advise
against using this measure at this moment because it can potentially increase the traffic directed to the CF's server.
We don't know yet how much traffic the CDN will save for us which may very well be marginal, since we decided not to cache attachments themselves. So, probably it's a bad idea to give up what little traffic we've reduced to remove the warning message which doesn't really pose a significant security threat.
But we
may consider using it, in case the migration to a CDN proves a significant improvement in terms of the reduced traffic, and if those measures mentioned above turn out to be difficult to enforce.
But all in all, I regard the migration to HTTPS is now practically done. Our site is now as secure as most others, so your login information is no longer vulnerable to the man-in-the-middle type attacks.
So, finally:
@everyone:
You can now update the bookmark in your browser to "https://www.cruxforums.com". It's not strictly mandatory anymore, but if you use the old address (e.g. http://www.cruxforums.com") you will automatically redirected to the new site incurring a small amount of delay. So it's a good idea to update it now.
