Full SSL Support?

[quest]

I'm interested in buying XenForo, but i'm unsure about the SSL support. I've read that many people had big problems with SSL and XenForo because it is loading much content from other sites (javascript and so on). I had the same problem with IPB so i had always only partially encrypted ssl. So is it possible to encrypt my whole board with SSL, without having a "partially encrypted" SSL-Connection? I don't want only the ACP or Login encrypted, it should be the whole board. Is this possible with XenForo? How can i do this? Only with htacces? Or is there a configuration for this in the ACP? Is there a documentation for this when i buy it?

And yes, i've read all the SSL threads here already. It doesn't answer my questions. All people are talking various things about the ssl support. I want to know this before i buy it.

 

[Deepmartini]

Xenforo works out of the box with https, as my site uses complete https. You do have to add a simple .htaccess command to force it, that is the only thing required.

I'm sure XF could incorporate that option in the ACP without much difficulty, to automatically force https or not.

Just add: (mine is installed in folder /c/ with nothing at root)

RewriteCond %{SERVER_PORT} !443
RewriteCond %{REQUEST_URI} c

The options are all there to not use external sources, which doesn't affect the validity of extended certificates, being what is used on my site.

So XF is fully compatible with extended https. I have run this from 1.0.2 and it does nothing to server load with 4000+ daily traffic on a single core hybrid, RAID 10, 3Gb RAM.

Here is the server load of the above stats, XF with extended validation https and about 20 odd mods installed, flashcoms chat, so forth:

View attachment 22747

Is there a mod to do this or will it be in the core soon? I'm not a developer or too technical minded so don't even know where to begin.

 

[SneakyDave]

If you have an installed certificate and SSL configured with your web server, your XenForo installation should work with it. For starters, change your "Board URL" information from "http://myxenforo.com/community" to just "//myxenforo.com/community".

The only thing issue outstanding for me is how to get the url bbcode working to allow relative local links like the rest of xenforo.

 

[Markus]

If you have an installed certificate and SSL configured with your web server, your XenForo installation should work with it. For starters, change your "Board URL" information from "http://myxenforo.com/community" to just "//myxenforo.com/community".

The only thing issue outstanding for me is how to get the url bbcode working to allow relative local links like the rest of xenforo.

Thanks for the url pointing info, you just made my day

 

[Anthony Parsons]

You're still better of to force it, as changing the ACP board URL to https still allows a person to view the site as http or https. It would only be relative links that will change to https through the software, which uses the board information URL data.

 

[SneakyDave]

You're still better of to force it, as changing the ACP board URL to https still allows a person to view the site as http or https. It would only be relative links that will change to https through the software, which uses the board information URL data.

Yes, that's right, I think it could work both ways SSL and non-SSL, but links generated in posts with the URL bbcode are always generated as http://, and it doesn't appear relative paths are supported by the URL bbcode. I made a suggestion that that bbcode be improved.

If I forced SSL, which I still may do, I'd get a lot of questions about mixed content warnings, particularly on IE it seems. I know it's easy enough to turn those warnings off, but I don't think my visitors want to mess with all that stuff, even if it is for better security.

 

[Anthony Parsons]

Yes, I found that for unvalidated certificates... I use an extended certificate, so validated, thus the green bar, so users don't get warnings about the SSL and it actually allowed some software programs that didn't work before with the site, to then work with the site. Seems extended validation is the best method for SSL... providing you have a business to do that with.

 

[SneakyDave]

I'm confused by what you mean by an "extended certficate". That won't solve problems with mixed content will it? Such as an embedded picture or video from a non secure URL being viewed through the site's SSL location? Are you meaning an unvalidated certificate as an "unsigned certificate", and an extended certificate as a normal signed cert you'd buy from some place? Or is your definition of an extended certificate something else?

 

[Anthony Parsons]

Extended validation is the better word. It means, the green bar. I found that validated SSL seems to function better with less issues than cheap SSL. For some reason, many softwares will accept extended validated certificates, but not unvalidated.

In other words... green bar has less issues with external viewing and software access, such as readers, etc, than normal SSL.

A page with a video or linked image was showing a break in the SSL before. With green bar SSL, it doesn't. It only breaks the pages SSL when you play the video, thus being unsecure content then.

I didn't know there was a difference in how they got handled, but it seems there is.

 

[SneakyDave]

I don't know why anybody would have SSL without having it signed by an authority, unless you were just testing out your SSL configuration.

SSL is SSL I guess. I don't know any provider that charges more for the same thing, providing any features that are more secure.

 

[Anthony Parsons]

Well... as a majority, they sell different SSL, ie. http://www.namecheap.com/ssl-certificates/comodo.aspx, which all are just normal SSL... you can see the extended validation tab if you want the green bar if you're a business. Godaddy used to, though they have cut it down to SSL or Extended Validation options only.

Look how many different types Verisign offer: http://www.verisign.com/ssl/buy-ssl-certificates/compare-ssl-certificates/index.html

I agree... its stupid. Its either secure or secure with validation of business entity.

 

[meos]

Why my last post was deleted?

I talked with my hoster again and he checked my board and found out why SSL was not working correctly on my XenForo board (it always generated a "http" href in the html code).

External download scripts doesn't download any content from your page because you have selfsigned certificate. You need to use certificate which is signed by authorized CA.

If you want to use XenForo with SSL, you need a signed cert by authorized CA. SSL will not work correctly with a self signed certificate with XenForo. It works perfectly with a signed certificate by authorized CA though. It would be really great if this prolem will be fixed in the future. I'm sure there are many people out there that can not afford a valid certificate. If you ask me, this is a very bad point for XenForo. I never had such problems with IPB for example. IPB works without any problems with a self signed certificate and always generates the right "https" href in the html code of every site.And if this is works with IPB why it should not work with XenForo?

This problem was really frustrating fo me and i lost much time to find out the reason for this problem.

 

[Paul B]

Why my last post was deleted?

The posts were moved here: http://xenforo.com/community/threads/unable-to-get-https-working.28013/#post-328797

You said you had a licence and were going to associate your account.

I can see you still haven't done so.

At this point it appears you are using nulled software.

 

[melbo]

A page with a video or linked image was showing a break in the SSL before. With green bar SSL, it doesn't. It only breaks the pages SSL when you play the video, thus being unsecure content then.

I didn't know there was a difference in how they got handled, but it seems there is.

Anthony, this is just a question since I'm currently exploring full site SSL.

By forcing and 'masking' external (mixed) content, aren't you tricking the browser into thinking that the site is full SSL when it really isn't? I thought that (as annoying as they are), those warning were there to let someone know that the non SSL content was getting unecrypted cookies, which invalidates the very reason for using full SSL. Thinking of the public wifi sniffer scenario.

When I visit your site, I am looking at mixed content. I'm not sure if that compromises my secure connection to your site or not although from my reading, I tend to think that it does and IF it does, that green bar could be misleading.

I'm sure I'm not getting this entirely correct but this is where I'm at after a few weeks of research. The ultimate problem I have is that I cannot exclude external content from the site. Unless I actually proxy serve that external content from a second server behind my xf server, it will be mixed which = insecure as unencrypted cookies will flow from the browser before completing the requests for external images, links, videos, etc.

Thoughts?


http://arstechnica.com/business/new...y-everyone-needs-to-use-it-so-ars-can-too.ars
Annoyances aside, mixed mode is still a problem to be avoided. Annoying as the warnings are, they also potentially subvert the entire purpose of encrypting traffic in the first place. A nefarious hotspot operator can not only read unencrypted traffic, he can also alter it as it crosses his network. A “secure” page that includes insecure JavaScript makes it relatively easy to hijack session tokens (again). In many cases, JavaScript in a page has access to the same cookie data the server does. The HTTP spec does define a “HttpOnly” flag for cookies that instructs browsers to keep the value out of the DOM. It’s extremely rare to see that set, though.

Lastly, we would have to find a way to handle the user-embedded-content scenario. Images in comments or forums can come from any domain, and these hosts almost universally support SSL poorly or not at all. One solution is to prohibit user-embedded content (which we don’t want to do), or proxy it through a separate HTTPS server that we control. Github has implemented this using a product called camo and Amazon's CloudFront CDN. When every page is rendered, its front-end application rewrites all image links specified with the ‘http://’ protocol to be requested from its camo server, which requests and caches the image and serves it over SSL.

 

[Anthony Parsons]

My site has nothing to really do with how SSL is handled. An unverified SSL certificate is handled by browsers differently than a verified SSL certificate. I am not tricking anything on my site with any type of SSL manipulation. The only thing my site is doing with SSL is forcing the url from http to https, that is my only URL manipulation.

With unverified SSL a page with video was instantly showing as being non-SSL, however; the moment I got verified SSL, the page showed correctly as verified with a video on it because the video is not actually being loaded UNTIL you push play. The moment the page goes to play the video by connecting to an external site, that is the moment verified SSL seems to break in the browser, not before.

It has nothing to do with my site, it seems to be more to do with how browsers interpret verified vs. unverified SSL certificates.

Site users who used accessibility software, their software stopped working with unverified SSL, though worked again the moment the SSL changed to verified (green bar), regardless of the pages content. I think its more to do with how the different levels of SSL are handled by browsers based on verification of the entity.

 

[melbo]

Thanks much for the info - be interesting to test it with wireshark or firesheep to see if anything is leaking because of the mixed content. If you've managed to solve it all with Verified and a one line rewrite rule, that's super!

I suppose I need to set up a mixed content SSL xf demo and have my sec guys unleash a storm of tests...