Full SSL support

[Bluto]

I have both of those set to 'yes'. Had them set to 'yes' when he did the test.

I removed this whole line, but I'm still allowed to access a non-https page.

RewriteRule ^(.*)$ https://cryptocointalk.com/$1 [NC,L]

When I do a test for the page http://cryptocointalk.com/forum/people (example not an actual page) I can get the page non-https. I was assuming that when I entered that address it would re-direct to the secure page instead of allowing me to access the http version of the page. All my links and everything on the site is fine for https. It's when I manually enter an address that I'm allowed to see the http page. This is what I'm trying to prevent. I want someone to enter a non-https page into the browser and it re-directs to the https version. Is this possible?

[Peter Parker]

I see what you are saying. When I browse your website I can see that you do infact thave the board_url set correctly because the rel=canonical tag is https:// even though I am on an http page.

What you want to do should be possible, and it used to be! I used to do it when I enforced https globally a year ago. I have no idea why its not working anymore. I even made a post about using 301 redirects from http to https! '?do=embed' frameborder='0' data-embedContent>>

I will mess with it some tommorow and see if I can't find a solution to the issue.

[Bluto]

Thanks! I appreciate your help in trying to resolve this for me and the others who would like to run full https for their boards.

[Peter Parker]

Thanks! I appreciate your help in trying to resolve this for me and the others who would like to run full https for their boards.

add this to initidata.php. works on my board to redirect all traffic to https. can't access an http page. :)

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();
    }
}

[Bluto]

Works perfect. Thanks for creating this and resolving this for me and the others who want to implement full https. It would be great if they added this as an option to activate this code or not in the ACP.

Thanks again!

[Peter Parker]

Works perfect. Thanks for creating this and resolving this for me and the others who want to implement full https. It would be great if they added this as an option to activate this code or not in the ACP.

Thanks again!

hopefully that will stop any man in the middle attacks for you :)

[vpsBoard]

add this to initidata.php. works on my board to redirect all traffic to https. can't access an http page. :smile:

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();
    }
}

You're the man!

[Peter Parker]

You're the man!

Glad it helped!

[Makoto]

For what it's worth, if you have to put that into your initdata.php file, you're doing something wrong, because that should not at all be necessary.

(This also won't really do anything to stop man in the middle attacks.)

[Peter Parker]

For what it's worth, if you have to put that into your initdata.php file, you're doing something wrong, because that should not at all be necessary.

(This also won't really do anything to stop man in the middle attacks.)

this is what is having to be done at this time. something changed in one of those updates (I guess?) to the board and the old way of doing this through .htaccess was not and is not working for any of us. I was having the same redirect loop issue on my board as well, and had to work around it. it works though, and that's really what matters to most of us.

[Makoto]

I'm running boards on 3.4.5 and 3.4.6, I do not have to use any such hack on any of them. Feel free to see one of my forums in development here as an example. Running 100% HTTPS with no problems.

You shouldn't even need to use .htaccess/web server redirects. You should configure your web server to redirect anyways, but there shouldn't be any obvious need to do this (such as scripts or content on your website being loaded insecurely, this means you haven't properly IP.Board. Forcing 301 redirects on every request for static content is wrong and just really bad practice.)

If you were getting a redirect loop, that means you most likely misconfigured something somewhere. It's the same case for everyone else here. You're probably making a simple mistake somewhere. You shouldn't rely on a hack to try and get around it.

[Peter Parker]

The thing about that, it was the same config it had always been, then updated and the redirect loop occured. I wont disagree it is probably something simple, and I could just submit a ticket, sure. You can't really say it's our fault, and it actually have any meaning though, we didn't code the board. At least it's not an IPS staff member saying that. IPS has made many fumbles in coding, some even allowed skilled individuals to hijack admin accounts, so if that happened using the same logic it was the customers fault too?

Basically what I am saying is some people, like me, are not coding professionals, and we just want our product to work. I don't floss my teeth three times a day either, and that's bad practice too according to some statistics, but most people don't do that either and they get by just fine. This is the same thing. Not everyone actually cares, or has time to learn every detail about everything. I get that this kind of stuff is your passion, and that's cool!

I don't know how to fix it any other way than what is already working. If you can figure it out, in a way that is good practice, that would be awesome, and I am sure people would be most grateful.

[vpsBoard]

For what it's worth, if you have to put that into your initdata.php file, you're doing something wrong, because that should not at all be necessary.

(This also won't really do anything to stop man in the middle attacks.)

Actually, you're right. IPB has some instances of 'http' hardcoded in the DB. Example: Twitter images. What he suggested worked fine and fixed -some- pages, but not all. I see on profile view pages that http:// is still being used in some places.

IPB staff suggested the following, after making a backup of your DB, of course:

UPDATE profile_portal SET pp_main_photo=REPLACE(pp_main_photo, 'http://', 'https://'), pp_thumb_photo=REPLACE(pp_thumb_photo, 'http://', 'https://');

[Peter Parker]

^ nice. When i first started using ssl back in version 3.2 I had an issue like that. I did not do the above, I believe I just updated my paths and cleared cache.

Also you might want to look at this post by kirito. He suggests modifying the youtube tags to prevent the https warning in browsers. I'm not sure if that is still valid or not. http://community.invisionpower.com/topic/388060-ssl-and-ipb/?p=2410922

[zatzllc]

I tried using SSL across the board for a long time... now I make it optional, as in if people specify it manually, they can have it. There were just too many problems with images and such from third parties, not all of which even support SSL, resulting in scary warnings.

It would be nice if browser makers had a better way of dealing with mixed content, esp when the only nonsecure content is images.

[Makoto]

The thing about that, it was the same config it had always been, then updated and the redirect loop occured. I wont disagree it is probably something simple, and I could just submit a ticket, sure. You can't really say it's our fault, and it actually have any meaning though, we didn't code the board. At least it's not an IPS staff member saying that. IPS has made many fumbles in coding, some even allowed skilled individuals to hijack admin accounts, so if that happened using the same logic it was the customers fault too?

Being that I've been running the latest versions of IP.Board for more than a year with HTTPS enabled and I've never had issues, I think it's very unlikely to be a problem with IP.Board. You could also have a 3rd party hook or application that's causing you problems. I can name a few off the top of my head that can cause loop errors simply because they're hardcoded to redirect to HTTP URL's. They're almost always a very simple fix.

As for your last statement, no software is completely immune to security exploits. Do you know how many vulnerabilities have been reported for PHP and Apache over the years? Lots. They get patched, you upgrade, and life moves on.

Basically what I am saying is some people, like me, are not coding professionals, and we just want our product to work. I don't floss my teeth three times a day either, and that's bad practice too according to some statistics, but most people don't do that either and they get by just fine. This is the same thing. Not everyone actually cares, or has time to learn every detail about everything. I get that this kind of stuff is your passion, and that's cool!

If you "just wanted things to work", why are you bothering with SSL support to begin with? IP.Board "just works" without it. If you're going to do something like this, you should do it right, not half-ass it with hacks and blame IP.Board when everything isn't working the way you'd like it to.

I'm no "coding professional" either. But I don't try and administer forums and say "I don't have the time" to learn how to configure or run them properly. If you really don't have the time, you should be hosting with IPS, not managing your own VPS. I hear this same excuse from people who run chmod -R 0777 on their forums too. They don't have the "time" to set up proper security permissions. When they get one permission error, they blame the software and give every directory and file public read/write access to "fix" it.

What are are doing with initdata.php is nothing but an ugly hack. You are ignoring whatever the real issue is. I am firmly stating no one else should be using this either. Using hacks like this just asks for more problems later down the road.

I don't know how to fix it any other way than what is already working. If you can figure it out, in a way that is good practice, that would be awesome, and I am sure people would be most grateful.

I can't say what your specific issue is without inspecting your server configuration myself. If you want me to tell you what's wrong, you're free to PM me your server details and I'll take a look. I can tell you what the problem is for free, but if you want me to fix it for you, you're going to have to pay a fee, because my time isn't that cheap.

Actually, you're right. IPB has some instances of 'http' hardcoded in the DB. Example: Twitter images. What he suggested worked fine and fixed -some- pages, but not all. I see on profile view pages that http:// is still being used in some places.

That's not going to cause any real problems though, so it's irrelevant to what's being discussed.

I tried using SSL across the board for a long time... now I make it optional, as in if people specify it manually, they can have it. There were just too many problems with images and such from third parties, not all of which even support SSL, resulting in scary warnings.

It would be nice if browser makers had a better way of dealing with mixed content, esp when the only nonsecure content is images.

There are no "scary warnings."

In Chrome, when you're viewing a page with mixed inactive content, here is what you see:

That tiny little icon in your address bar changes. That's it. Everything on the page still loads and renders without issue. Mixed inactive content doesn't matter. Avoid it when you can, don't worry about it when you can't.

I've been running my main board that gets hundreds of thousands of visitors a month entirely under HTTPS for over a year now and have had no issues and no complaints from anyone.

If you want a more in-depth explanation on this, see my post here.

Also you might want to look at this post by kirito. He suggests modifying the youtube tags to prevent the https warning in browsers. I'm not sure if that is still valid or not. http://community.invisionpower.com/topic/388060-ssl-and-ipb/?p=2410922

Yes, it is still valid.

An example of a working post with YouTube videos embedded,

https://www.anime-social.com/topic/5-youtube-test/

And again, the above site, while only an inactive development board at the moment, is living proof that IP.Board and all of its associated applications are fully capable of running entirely under HTTPS without issue.

[Dmacleo]

IE (I have not checked on IE11) gives "scary" (to some) warnings. 8/9/10 do it through a popup.

7 did too but anyone using 7 deserves to be scared.

real browsers handle it a lot better.

[Makoto]

IE (I have not checked on IE11) gives "scary" (to some) warnings. 8/9/10 do it through a popup.

7 did too but anyone using 7 deserves to be scared.

real browsers handle it a lot better.

I'm running Linux right now and can't test with the latest version of IE, but I asked someone I knew to test in IE10 and he said he didn't see anything.

In older versions of IE, it would give you a popup the very first time and then you generally set it so you're never reminded again. Most people don't even think about it, because mixed inactive content isn't that uncommon. Most people have probably visited a site that has mixed inactive content before.

[Dmacleo]

been meaning to check 11 but I know 10 CAN do it.

the issue was 7/8/9 (I am not positive on 10 on this) would often not actually remember the settings (depending on other security settings) and people would freak out.

think anyone thats ever run a sharepoint site (MOSS2007 seemed the worst to me) is all too familiar with that settings not saving issue.

edit: and those on an AD domain with an intranet/extranet setup may see it more than others.

of course real browsers don't have the issue :)

[Tripp★]

So there's no way of making it optional it's either all for or not at all? - To make it so members have a choice (Click for Secure Version)?

It should be possible - http://stackoverflow.com/questions/19372594/preserve-http-https-protocol-in-htaccess-redirects

[Makoto]

So there's no way of making it optional it's either all for or not at all? - To make it so members have a choice (Click for Secure Version)?

I'm sure IP.Board could be modified to allow this functionality. When I started this thread over a year ago, I would have had no idea where to start to implement such functionality myself. But today, I think I could do it quite easily.

It might require some core modifications to work, or it might not. But I'll see about creating a hook to accomplish this.

[Tripp★]

Ah; awesome. Thanks Kirito.

[Clover13]

I've been reading this thread as I've been looking to convert my site to full HTTPs.
What I noticed immediately is there were a lot of embedded http:// references to various resources that would subsequently fail to load.
Looking at others, I saw they were protocol agnostic using just // without http: or https:

Example would be using the jQuery lib hosted on ajax.googleapis.com

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>

So my question is, would it be good practice to just make all srf, href, etc (i.e. all linked content) to be protocol agnostic and use // as in the above code sample? Or would this have some adverse effect, either from a security perspective (doubtful if Google is doing it) or from a browser support level?

I'd imagine to a degree, this might also may protocol switching (if one wanted to support both HTTP and HTTPS) much easier to implement/toggle between?

[Clover13]

So as I learned, using // everywhere isn't a good idea as you can't guarantee other external entities will serve via HTTPS as well as HTTP.
Internally to your site, it's just fine, external not a good approach :smile:

Everything else on full SSL appears to be working OK thus far. Few minor corrections.

[Wielebny]

As we said - full SSL support is already available

1. Change the URL in conf_global.php
2. Go to Admin CP --> Look & Feel --> Template Tools - click "Recache Skin Sets"
3. Change the "Upload URL" under Admin CP --> System --> System Settings --> General Configuration

Except that users can still use to attach images from http:// sites, which gives warning in many browsers, and currently we don't have any mechanism to block this.

An option to 'block images from unsecure sites', would be everything that we'll need to enable full-ssl support.