Implemented SSL / HTTPS Integration

This suggestion has been implemented. Votes are no longer accepted.
Yes, they can still sniff the packets, but when its encrypted they will not be able to de-crypt any of the packets. I tend to have a lot of intelligent hackers in my communities, some have tried to gain control of my servers in the past, but they have failed to do so yet.
 
Built in SSL support would be a very good standard to have available and working for Xenforo before it reaches gold status. I would recommend making it stand out as something admins can enable from the control panel along with a brief description of SSL and how it can help benefit users. This way an admin can enable SSL for the entire site, only during login and viewing private messages and private forum sections.

As the benefits of having SSL fully supported out way not having it not fully supported by default along with making sure all cookies are HttpOnly so they cannot be modified by the client to help mitigate most XSS attacks.
 
With CPU speeds these days, SSL comes with minimal overhead. For what SSL protects against (man in the middle attacks), you really should retrieve every page over SSL. (See this article, where Tunisia is allegedly modifying pages on the fly to steal credentials.) XF shouldn't have any issues when using the whole site in SSL, though if you find a problem, please do report it.
 
I think the main issue here is "forcing" SSL authentication if you have that available. It is not much about configuring the server itself, but having the software check and force a SSL connection if one is configured and available.

In a typical scenario, I would login with SSL, then set the session cookie and fallback to regular HTTP to reduce server overhead. Even with modern day processors I wouldn't force an SSL connection if I absolutely do not need it.

Of course falling back to regular HTTP could mean your session could potentially be stolen, but at least your password would not be compromised (or the hashed md5 password in the worst case scenario).

This means that if I have both an HTTP and HTTPS for the software available, I don't want users bypassing the SSL login and just using the regular HTTP to login, I would want that anytime a user wants to login they are redirected to the HTTPS page, logged in, then back to the regular one. There is some implementation that is needed from XenForo to accomplish that, if that were the goal.

Switching all the instance to HTTPS is trivial, just buy a certificate and configure your server with HTTPS, but the SSL support only for login and not for the rest of the page is less trivial.

This is however an advanced scenario, and I am not sure the target market for XenForo would deal with the burden of getting a certificate and configuring everything properly. Even with that, it would be nice to have some support built in.
 
Of course falling back to regular HTTP could mean your session could potentially be stolen, but at least your password would not be compromised (or the hashed md5 password in the worst case scenario).
Well, your session and if you use it, your "remember me" value, which would allow them to login as you. Though it wouldn't get you into the ACP, unless they could steal an ACP session. (Sessions are tied to IPs BTW.)

However, if we're talking about MITM attacks, why could they not manipulate the non-SSL login page to include JS that sniffs your login details? That's allegedly what the Tunisia issue is about.

I know I'm talking about an advanced attack here, but the workaround is really to just force SSL all the time.
 
Well, your session and if you use it, your "remember me" value, which would allow them to login as you. Though it wouldn't get you into the ACP, unless they could steal an ACP session. (Sessions are tied to IPs BTW.)

However, if we're talking about MITM attacks, why could they not manipulate the non-SSL login page to include JS that sniffs your login details? That's allegedly what the Tunisia issue is about.

I know I'm talking about an advanced attack here, but the workaround is really to just force SSL all the time.

Although I do care about a MITM attack, that is pretty much advanced as the attacker needs to pass as the gateway the connections are going through. The first one I am concerned about is just plain sniffing. I am always a little uncomfortable these days going through public networks (Starbucks, etc) just because of the sniffers. More now after Firesheep became wide knowledge.

Someone stealing my session is bad.. someone having my password is even worse. And, for the public WIFI spot scenario the IP address protection is just not enough. I should not be login to the admincp on a public network anyway, I guess.

Even with all of that I don't feel that I am ready to move to an all-SSL solution. With gmail having switched to always-SSL and leading the way, I might reconsider. I just need to test the overhead, I guess. It's not so much about the configuration but about upgrading my server (or adding a load-balancer that does the HTTPS translation).

I use public wifi spots and (to my knowledge) I have never had problems. Maybe my forum is boring or maybe the hackers are busy elsewhere.
 
Greetings.

I would like to request a setting that would allow administrators to enable using SSL for all user personal information that is captured. (logging in, editing profile, etc) This should be a setting that other plugins could query and optionally adhere to if enabled.

While it may not be a necessity in the community space, our clients require it for any consumer campaigns we do and we can not launch sites without it. (there is an audit by Price Waterhouse Cooper to verify we conform beforehand) We are looking forward to leveraging the xenForo platform and hope this feature can make it into future releases.

Thanks!

--Ed
 
Nowadays, the overhead of SSL is quite small (as a percentage of request/CPU time), such that if SSL is something you want, it's probably quite reasonable to apply on every page. (Only submitting logins through SSL but not the page that has the login form leaves man-in-the-middle attacks open.)
 
Valid point. I would agree with you from a technical side, but all of the major sites (Facebook, twitter, LinkedIn, etc) keep their site on the unsecure port except for transmitting personal data. Is this just a legacy practice or is there a benefit to do so that we are overlooking?

--Ed
 
Facebook is rolling out SSL to all pages - it's a user option currently. You can see the details of the MITM issue that I was referring to here: http://www.theregister.co.uk/2011/01/25/tunisia_facebook_password_slurping/

Strictly speaking, there is still overhead to SSL. However, it is becoming a smaller amount of each request (especially at scales where a load balancer can offload this to more specialized hardware; at smaller scales as well, it's probably not a big deal). If you're considering SSL, you're more than likely fine doing it for everything and that does have some advantages.
 
When you are as enormous as Facebook, every tiny amount of processing power used to generate a page costs a fortune, so it makes sense for them to optimise as much as possible, which could be a reason for them to limit their use of SSL. However, for most of us, until you have tens of millions of daily visitors, SSL is a valid option.
 
Top Bottom