Full SSL

[Bluto]

I haven't setup a 4.0 testing site yet and wanted to find out if site-wide SSL was going to be an option 4.0.  Right now, using 3.4.6, I have a redirect in my .htaccess file to make sure that everyone is redirected to https when they come to my forum.  There was a thread on the forum which outlined how to setup full SSL using the .htaccess file.

I know there is an option to use SSL when signing up, etc. in 3.4.x

Does anyone know if full SSL is an option in 4.0?  If not, I hope IPS adds this feature.

[Tripp★]

As far as I could tell from my testing IPS4 works on Site-Wide SSL I think it auto-detects it as well because the setting under use HTTPS for Login was greyed out for me because I had site-wide SSL. So if you have SSL for everything you can't disable it - which I thought was nifty.

So it shouldn't be a problem. If you don't have Site-Wide SSL but do have SSL I assume the button works as normal. If you don't have it at all I assume the button will be greyed out stating you don't have SSL activated. I'm not sure though. What I do know is IPS4 - Works with SSL (Site-Wide). Been using it since Beta 1.0.8

[starboymario]

If there's no setting in AdminCP. You can do it by going to "conf_global.php" file.

Then find:

$INFO['board_url']            =    'http://example.com'; 

Then replace it with:

$INFO['board_url']            =    'https://example.com'; 

That's it. What you did was added https:// to the board url. This will allow ever page to have SSL.

[joelle]

Will the site traffic automatically redirect from "http:// to https://" whenever a user loads an old topic URL?

[Bluto]

If there's no setting in AdminCP. You can do it by going to "conf_global.php" file.

Then find:

$INFO['board_url']            =    'http://example.com'; 

Then replace it with:

$INFO['board_url']            =    'https://example.com'; 

That's it. What you did was added https:// to the board url. This will allow ever page to have SSL.

I have that setup like that already.  But I believe it still allows people to access the forum using http / Non-SSL.  Which, I believe, was the reason I had to add the redirect in the .htaccess file.

I don't want this thread to get off-track as a support question for SSL in 3.4.x (and moved to another forum) My question was if support for full site SSL was going to be made available in 4.0. 

[Bluto]

As far as I could tell from my testing IPS4 works on Site-Wide SSL I think it auto-detects it as well because the setting under use HTTPS for Login was greyed out for me because I had site-wide SSL. So if you have SSL for everything you can't disable it - which I thought was nifty.

So it shouldn't be a problem. If you don't have Site-Wide SSL but do have SSL I assume the button works as normal. If you don't have it at all I assume the button will be greyed out stating you don't have SSL activated. I'm not sure though. What I do know is IPS4 - Works with SSL (Site-Wide). Been using it since Beta 1.0.8

​Super.  Thanks for the info.  I need to setup a testing site on my server... I just have so much other stuff to do!

[Thomas.]

If you're going to serve your entire website over HTTPS, you should be using HSTS. This will also take care of the 'redirecting'.

I serve all my own websites and forums over HTTPS as well, which is working perfectly fine on both IPS 3 and IPS 4.

[Bluto]

If you're going to serve your entire website over HTTPS, you should be using HSTS. This will also take care of the 'redirecting'.

I serve all my own websites and forums over HTTPS as well, which is working perfectly fine on both IPS 3 and IPS 4.

​Never even crossed my mind.  Thanks for the info!

[Makoto]

HSTS only works when the client makes an initial HTTPS connection however, so it's not an alternative for permanent redirects.

Optimally, you should have your web server 301 redirect the user from HTTP pages to HTTPS pages, not just IP.Board. This will cause all static resources to be redirected as well. HSTS is added protection that will prevent the client from accepting connections over HTTP after a secure connection has already been established, HSTS headers are ignored over standard HTTP connections.

Add the following line to your Apache configuration (or root .htaccess file) to force HTTPS redirects,

RewriteEngine On
# This will enable the Rewrite capabilities

RewriteCond %{HTTPS} !=on
# This checks to make sure the connection is not already HTTPS

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
# This rule will redirect users from their original location, to the same location but using HTTPS.
# i.e.  http://www.example.com/foo/ to https://www.example.com/foo/
# The leading slash is made optional so that this will work either in httpd.conf
# or .htaccess context

Or if you're using Nginx,

server {
       listen         80;
       server_name    example.org www.example.org;
       return         301 https://$server_name$request_uri;
}

 

[Bluto]

I have it setup like what is below.  It was actually in the initdata.php not the htaccess file.

/**
 * FORCE SSL FOR ALL PAGES
 */

if (!isset($_SERVER['HTTPS']) || $_SERVER['HTTPS'] !== 'on') {
    if(!headers_sent()) {
        header("Status: 301 Moved Permanently");
        header(sprintf(
            'Location: https://%s%s',
            $_SERVER['HTTP_HOST'],
            $_SERVER['REQUEST_URI']
        ));
        exit();
    }
}

 

[Thomas.]

HSTS only works when the client makes an initial HTTPS connection however, so it's not an alternative for permanent redirects.

​While it is indeed a good idea to always force a server-side redirect, your analogy is a bit off. It could be used as an alternative, if it weren't for the reasons mentioned below.

In both instances (with and without HSTS) the client will initially try to connect over HTTP. In case you have both HSTS and a redirect, the client will first attempt to connect over HTTP, only to be instantly redirected to HTTPS, after which the HSTS header is received. In case there's only HSTS, the client will instantly 'redirect itself' as soon as the Strict-Transport-Security header is received (which at this point is of course also over HTTP).

Both instances allow for MitM attacks during the first visit. Therefore, a permanent redirect does not mitigate a potential attack (but it's definitely still a good idea - primarily to act as a fallback for older clients which do not support HSTS - despite the fact that these stone-age clients should really be updated - and possibly for SEO purposes as well.)

[Makoto]

I have it setup like what is below.  It was actually in the initdata.php not the htaccess file.

​You have your server misconfigured then. You're adding a hack to initdata.php to have IP.Board, the web application, perform 301 redirects, and you're using a really cumbersome method to accomplish it in PHP on top of that.

The best and most efficient method is to have your web server perform the redirects for the reasons I stated above, not IP.Board. The method you are using will not force redirects on static resources not served by IP.Board. If you have your server configured correctly, it will work.

​While it is indeed a good idea to always force a server-side redirect, your analogy is a bit off. It could be used as an alternative, if it weren't for the reasons mentioned below.

​It wasn't an analogy, I was stating a fact. It is not an alternative and if you are trying to use it as such you're plainly using HSTS improperly, there's no arguing this. HSTS is also not supported in older browsers, which you are already aware of, and for this reason alone you should not be using it as a lazy alternative to proper HTTP redirects.

Please don't try and create arguments over nonsensical things. If you're using HSTS but still openly accepting HTTP connections on your website, you don't know what you're doing and your web server is misconfigured.

[Bluto]

​You have your server misconfigured then. You're adding a hack to initdata.php to have IP.Board, the web application, perform 301 redirects, and you're using a really cumbersome method to accomplish it in PHP on top of that.

The best and most efficient method is to have your web server perform the redirects for the reasons I stated above, not IP.Board. The method you are using will not force redirects on static resources not served by IP.Board. If you have your server configured correctly, it will work.

​Thanks for the info.  I'm going to fix all that up tomorrow.

[Thomas.]

​It wasn't an analogy, I was stating a fact. It is not an alternative and if you are trying to use it as such you're plainly using HSTS improperly, there's no arguing this. HSTS is also not supported in older browsers, which you are already aware of, and for this reason alone you should not be using it as a lazy alternative to proper HTTP redirects.

Please don't try and create arguments over nonsensical things. If you're using HSTS but still openly accepting HTTP connections on your website, you don't know what you're doing and your web server is misconfigured.

​I never claimed you should only use HSTS, quite the contrary actually. I only tried to get across that the end result is basically the same (in the sense that the client will be redirected to use HTTPS in both instances), as I thought there was a misunderstanding there (as you stated "HSTS only works when the client makes an initial HTTPS connection", seemingly implying that the client is the one that has to connect over HTTPS first before HSTS will have effect). No need to get rude. Yes, your post sounds quite rude.

Hence why the word could is written in italic. I tried to emphasize my point, not that you should actually see it as an alternative. That may have been confusing and is therefore an error on my part.

[Makoto]

​Thanks for the info.  I'm going to fix all that up tomorrow.

​If you're having trouble, feel free to post your .htaccess configuration here.

(as you stated "HSTS only works when the client makes an initial HTTPS connection", seemingly implying that the client is the one that has to connect over HTTPS first before HSTS will have effect)

As I said above, HSTS headers are completely ignored over HTTP connections, so unless you force the client to a HTTPS resource at one point or another, HSTS headers will do literally nothing for you or your users. This is why you need to have your web server permanently redirect to HTTPS, HSTS is not some type of alternative to HTTP redirects, it's a completely different thing and it's only meant as a security feature that takes effect after the user establishes an initial secured connection connection to your website.

So, no, it could not be used as an "alternative", ever. I'm sorry if you found my comments rude, but what you're saying is simply wrong, and I can only point that out so gently when a subject involving internet security is being discussed. Such information needs to be provided bluntly to make sure people clearly understand what should and should not be done.

Maybe you meant to imply that since the user will "eventually" click through to a HTTPS page on your forum you don't need to force any redirects. Even if this is what you meant, this is still a really bad thing to do for many reasons and definitely shouldn't be suggested.

Again, not meaning to be needlessly rude to you, but I think you're possibly misunderstanding how HSTS works. HSTS does not work over HTTP connections. If the user connects to your website over HTTP and receives a HSTS header, they will ignore it completely, they will not recognize it. That's how it works. HSTS will not be recognized unless the header is sent over an existing HTTPS connection, not HTTP. You can not send it over HTTP to have the client "redirect" to HTTPS, it won't work.

[Bluto]

​If you're having trouble, feel free to post your .htaccess configuration here.

​I got everything fixed up last night.  Along with the initdata.php there was some code in the .htaccess file.  So, I removed the code from the initdata.php and the .htaccess and added your code in the .htaccess.  Works perfect.  Thanks for your help.

[Makoto]

No problem, glad you got it working.

[kysil]

If my license is actual for connection http if I can not support a request to use a secure connection for my domain?

[Makoto]

It doesn't matter if your license is for http or https, it will work the same either way.

[Rhett]

It doesn't matter if your license is for http or https, it will work the same either way.

​

With our new license changes, it must match exactly, so if it's https via http, it would make a difference in my testing with IPS4..specifically for a re-install etc.  If this is the case for anyone, please file a ticket and we can adjust the url for you without having to reset the url etc since it's not actually a url change. 

[kysil]

That is, if I want to get my domain working through https, I must send a request for a change? I understand you correctly?

[Rhett]

That is, if I want to get my domain working through https, I must send a request for a change? I understand you correctly?

​

If you have any trouble doing so, you can let us know by submitting a support ticket once 4.0 is released as final.  Currently the ulr must match exactly is what I was noting, so if you are having trouble with your license, and you think it may be due to the licensed url being http and you are using https, please file a ticket and we can adjust this for you if needed. 

[tppn]

Do note that IPS 4 has minor issues with Full TLS, including YouTube embeds. 

[Makoto]

​With our new license changes, it must match exactly, so if it's https via http, it would make a difference in my testing with IPS4..specifically for a re-install etc.  If this is the case for anyone, please file a ticket and we can adjust the url for you without having to reset the url etc since it's not actually a url change. 

​How does that work for users who only have SSL enabled on login pages then? What would break if your URL didn't match exactly, out of curiosity?

(And you say currently, is this something that's going to be changed/fixed at a later date? Since I don't think there's a reason the schema should need to match on your license, and there are people who may want to offer both as options for their users.)

Do note that IPS 4 has minor issues with Full TLS, including YouTube embeds. 

​These are issues with the stock media tag configuration that can be easily fixed. See my post here regarding YouTube embeds,

[Rhett]

​How does that work for users who only have SSL enabled on login pages then? What would break if your URL didn't match exactly, out of curiosity?

(And you say currently, is this something that's going to be changed/fixed at a later date? Since I don't think there's a reason the schema should need to match on your license, and there are people who may want to offer both as options for their users.)

​These are issues with the stock media tag configuration that can be easily fixed. See my post here regarding YouTube embeds,

​

In testing, so far with ips4, I'm referring to the licensed url and the url the board is setup to run under, ssl for logins would not be effected though.  For example if I install under https, then later change to http, the license may not work properly as the full license url is matched currently.   Re-installing the software in my case for many many test setups has triggered this, so if it matches perfectly, all is well.