Implemented SSL / HTTPS Integration

[Ryan Clark]

It would be cool to have SSL Intergration, so if you have an SSL certificate on your website you can allow people to login using that, and view Administrative Areas as well as their User Control Panel through it too.

 

[Puntocom]

I ended up having the entire forum set through SSL. Soon, the entire site will be processed through SSL. There is a little bit of memory consumption to cache the SSL sessions but nothing important.

Please, could you write a howto? just seting the url to https://www.avivo.com ?

 

[Floren]

I'm using Nginx, not sure if you have the same setup. I posted some information in this thread.

 

[rossfudgew]

Well I think it would be a nice feature for users to be able to login to the forums through ssl at least. Many people (despite the warnings) use the same password for a lot of services including forums.

So as a server owner and a forums host I want to do my part in keeping their passwords safe, and add in some sense of security while browsing the site. Now I don't know if xenforo natively salts and hashes passwords, but even if it does nothing says security like a lock in the upper corner to users. So can you make an option (other than .htaccess ) for xenforo just to force people to browse the site under https:// ?

Thank you for reading and considering this

 

[digitalpoint]

If you are going to do that, why not just make the entire site SSL rather than just logging in?

 

[Mike Edge]

If you are going to do that, why not just make the entire site SSL rather than just logging in?

Exactly, you can also use a rewrite rule to always force SSL too.

 

[Luke F]

If you are going to do that, why not just make the entire site SSL rather than just logging in?

Does this not create warnings when stuff like remote images are used?

 

[Mike Edge]

nm.. i just proved myself wrong on that theory Luke.

 

[Mouth]

Does this not create warnings when stuff like remote images are used?

Correct, and also un-necessary performance load on servers.

Well I think it would be a nice feature for users to be able to login to the forums through ssl at least. Many people (despite the warnings) use the same password for a lot of services including forums.

Not just nice, but almost mandatory these days.

 

[digitalpoint]

Correct, and also un-necessary performance load on servers.

Actually not really the case anymore.

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

 

[Mouth]

Actually not really the case anymore.

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

With the disclaimer that Google only uses RC4_128bit encryption on a 1024bit key ... we'll under spec and recommendations for any SSL connection. The content size on a standard google search results page is also around 1/10th the content size delivered by a standard XF thread page. Most SSL certificate authorities and resellers won't even let you purchase such a low key size SSL certificate anymore.

Every latency delay counts and contributes to the 'laggy' user experience and complaints. I wouldn't want to subject my entire site and content delivery to SSL, just to provide protection on less than 5% of content usage.

 

[digitalpoint]

True... no matter what there's going to be *some* overhead for SSL. As far as 128 bit vs. 256-bit, 256-bit is a waste of CPU cycles.. it's why all the big sites use 128-bit (Google, Twitter, Facebook, Microsoft, etc.) for their HTTPS connections.

Where things get interesting is if you have a web server configured to allow users to use SPDY protocol. Part of the SPDY spec is that it only (normally) runs on secure connections, but the other parts of it are made for speed. So a site running HTTPS and the user is using a browser that supports SPDY (Chrome, Firefox or Opera, which for my site make up 79% of my user-base), the HTTPS connection is actually faster than HTTP.

http://en.wikipedia.org/wiki/SPDY

It works especially well when a site has lots of supporting files (images, JS, CSS, etc.)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Mouth]

Right, I'm on a boot-camp learning mission for SPDY Thanks. Does nginx support SPDY?

 

[Deebs]

Right, I'm on a boot-camp learning mission for SPDY Thanks. Does nginx support SPDY?

Certainly does

http://nginx.org/patches/spdy/

 

[digitalpoint]

Yep... I have it running just fine on my dev servers with Nginx/XF.

 

[Jeremy P]

Just FWIW my production site is setup using SPDY (https, via nginx) for all logged-in members. Not many performance issues to report but I haven't closely monitored it or anything. The only reason guests are still served over regular HTTP is adsense won't work over secure connections and I haven't found a good alternative.

It does produce warnings went insecure remote images are used though. I just remind members to upload images as attachments.. it's not really a great solution but it helps.

 

[digitalpoint]

Just FWIW my production site is setup using SPDY (https, via nginx) for all logged-in members. Not many performance issues to report but I haven't closely monitored it or anything. The only reason guests are still served over regular HTTP is adsense won't work over secure connections and I haven't found a good alternative.

Not sure who told you that, but it absolutely does work over SSL.

What happens when you try? Are you getting an error, or?

 

[Jeremy P]

Not sure who told you that, but it absolutely does work over SSL.

What happens when you try? Are you getting an error, or?

http://support.google.com/adsense/bin/answer.py?hl=en&answer=10528

So I suppose it 'works' but it's served over an insecure connection. Latest versions of Chrome don't even load insecure content on secure pages by default. I'd rather just serve guests over HTTP to make sure ads always show up.

Also your image isn't showing for me?

 

[digitalpoint]

Couple of things here... I've never seen Chrome flat out not serve insecure content on secure pages (maybe there's a way to enable it to do that, but it definitely serves insecure content from HTTPS pages, the only difference is the green lock in the URL has a triangle on it to let users know. But all parts of the page load fine. If that's the case for you, does that means any hotlinked image on your site doesn't show in Chrome for you when you are logged in (I believe you said it's SSL when you are logged in)?

Not sure why the image isn't showing for you... maybe your browser is being weird with images in general? It's showing fine for me (latest version of Chrome 23). Here's another copy of it (hopefully this one works?)

As far as not AdSense over SSL, their info is out of date... if your request for the AdSense JavaScript i made via HTTPS, all parts of the ad are served securely.

For example we do it like so:

<script type="text/javascript"><!--
  google_ad_client = "pub-5676236325709660";
  google_ad_slot = "2715707860";
  google_ad_width = 468;
  google_ad_height = 60;
  //-->
  </script><script type="text/javascript" src="//pagead2.googlesyndication.com/pagead/show_ads.js"></script>

Omitting the protocol like that just makes it so it makes the request with whatever protocol the page is using. You can also just make it https:// if you want it to always serve ads via HTTPS regardless of the page's connection.

 

[Deebs]

All my chrome installs do not serve insecure content over HTTPS without changing a setting. Not sure if it was the default when I first installed chrome.

 

[digitalpoint]

All my chrome installs do not serve insecure content over HTTPS without changing a setting. Not sure if it was the default when I first installed chrome.

Weird... I just went through all the Chrome settings I could find and didn't see such a thing in there.

So if you go here: https://forums.suse.com/forum.php the black icon next to search doesn't show (it's served over insecure connection)?