Hi Sean,

We're using HTTPS in our live site and I forced https when a user login, so far, I have found ES to have issue with sharing a link with https but that was in the early version. I just don't know if that was fixed in the current version. I'll test it again will let you know.

Aside from that, HTTPS should be fine, also make sure you configure all you addons or scripts that loads data from other websites to auto change to https else you'll get a browser notification that some images or scripts is using non https url.

Thank you LAC Infosys for replying. I am interested to know if the links problem resolves.

Also, I suspect that even using RSS newsfeeds from the core joomla newsfeeds would require being configured to use https in order to not get the error messages?

Sean

We'll be running over SSL too when my site goes live.

On a another site which runs JomSocial I have implemented Yireo's excellent SSL redirection plugin:

http://extensions.joomla.org/extensions/site-management/url-redirection/11326

This allows you to fine tune which pages, menus, components etc. are SSL servered.

Thanks for sharing Mark. As for the issues with sharing links, as mentioned on the other post, there is a known issue if you try to share a non https link on a https site. It's problematic because we wouldn't know if the link that you are trying to share fully supports https and if we explicitly replace http -> https , it could be a problem when the remote site doesn't support https.

I am not sure if this is a safe practice but we could try to create a proxy function where it actually tries to act as a proxy (https) to the target URL (non https). This is what facebook does anyway in order to prevent the mixed content issues. The only drawback that I could think right now is the bandwidth usage for your site.

Hmmm... Mark I got what you mean.

Isn't it will always resolve the link that are being shared and pull contents from it? Or its not always the case? If it does always then maybe return an error if the link has https and it does not resolve.

Thanks,

Jackson

Hello Jackson,

We don't actually pull the contents and store it on site because that would be crazy Your disk space will get filled up in no time. I am trying out a method to serve https method via a proxy call within EasySocial so that if a URL is passed to this proxy, the script will fetch the content and output it (Still experimenting.)

Mark, if you shared a http link that points to a https site, wouldn't that link automatically become a https link? For example: http://www.google.com/ will automatically become https://www.google.com/
Click the first Google link and you will see it automatically change. So couldn't the share link by default be http, then we can let the site/browser (not sure which one changes it to https) change it or not change it depending on what it is.

Hi Josh,

I think, if I understand Mark correctly, he is talking about a Link that has https but does not resolve to https since its not enabled or the site is using self signed certificate. If that's the case I think the link will be an issue.

For bigger sites that can afford to buy SSL cert annually then http or https should work just fine.

So Mark, you're saying the Content from a link are always dynamically rendered every time it loads in a stream? LOL! I'm lost with proxy but anyhow anything that would fix https issue

Thanks,

Jackson

Mark wrote:

As for the issues with sharing links, as mentioned on the other post, there is a known issue if you try to share a non https link on a https site. It's problematic because we wouldn't know if the link that you are trying to share fully supports https and if we explicitly replace http -> https , it could be a problem when the remote site doesn't support https.

What if outbound links defaulted to http instead of https. Let's pretend StackIdeas is the https site with EasySocial installed. So if I share a link on https://stackideas.com that points to http://www.joomla.com , we would be okay assuming that outbound links did not add https. In the same scenario, if sharing a link treated https://www.google.com/ as http://www.google.com/, that should be okay considering that when you are directed to Google's site with a non https url, it will automatically change it back to https.

Hello Josh,

Sharing links are fine, but the assets from the remote site is a big issue. For instance, if your site https://site.com (https) has a content of http://siteb.com/image.png, then the browser will complain about the image. To fix this, in the next version it will be using an "internal proxy" as you can see here, http://screencast.com/t/IWz0iMceZfp so it would be less problematic.

Sounds good. So for us non https folks would the internal proxy still be "running"? Not quite sure how it activates or is it always on?

Nope, it's configurable and even if it is switched on, if your site is not on https mode, this will not take effect because this is actually an (expensive process) . To be honest, I don't have the statistics on how much bandwidth it would use because it really varies on what images are being transferred. Maybe these guys that are on the https could let us know if there's a huge spike in bandwidth usages?

I want to thank you all for your time and help with this question. I knew it would be a good idea to ask here! :-)

Another issue I just thought about is that I was using Amazon S3 for the images and so I am imagining I would have the same problem with their links unless I maybe got a separate SSL certificate for the Amazon S3 bucket as well?

Thanks again, Sean

You can actually choose if you want items to be served via https or http in Amazon S3

Thanks Mark, I found that out looking in your back-end settings AFTER I had asked the question. It works great. I am mostly only concerned now about the bandwidth issues and what will happen if one of our users tries to share a url to a web site that is NOT HTTPS. That will certainly happen a LOT. So, I am hoping the solution you are working on with the proxy, etc... will solve that. I certainly do not want to confuse the users but would like to make it so that sniffers can't grab the content of their messages.

You are most welcome Also, remember to check your site against the latest HeartBleed bug http://filippo.io/Heartbleed/ . Stay safe

Well, now I have taken the step to make the site at http://starch-smart.com converted to https. It all seemed to work well in that nothing 'broke' on the web site. It also passed the heartbleed test just fine! :-)

I find it interesting that some browsers seem to find problems with the certificates and others do not. Firefox definitely puts up a warning that some items are not secure (like images). I had CloudAccess.net do the installation for me and am waiting to hear what suggestions they might have but I now have to absorb what was previously written in this thread to wrap my brain around what might need to be done in order for the entire site to be https. All I have done so far is allow CloudAccess.net to do the install for me and then turn on the Global Configuration to force SSL on the entire site.

But, somehow I think that Mark's idea of the proxy server for the non https asets like images makes a lot of sense. I suspect that would solve our problems. Mark mentioned it would be in the next version. I am assuming that means EasySocial 1.3? I will be hoping it happens sooner rather than later! :-)

Sean Carney

Hello Sean,

The proxying of images would be available on 1.2.8 By the way, to test out the site's padlock issues, you could use this little useful tool, http://www.whynopadlock.com/

Mark,

When I saw your message last night about the proxy being available in version 1.2.8 I exclaimed to my wife "I love these guys" (meaning StackIdeas) and she told me to tell you that she loves you all too because you make her husband happy. So, consider the message delivered.

Thanks for the link to http://www.whynopadlock.com/

I ran it and discovered my problem is simply two images on the page. Interestingly enough I assumed they would have to be images from another web site but they are actually images hosted on my own web site. So, I will ask my host if there is someway for me to change those URLS to secure those:

Number of insecure items: 2

Insecure URL: http://starch-smart.com/images/background/PoleBeansWithStarchSmartLogo_750x400.jpg
Found in: https://www.starch-smart.com/

Insecure URL: http://www.starch-smart.com/images/background/PoleBeansWithStarchSmartLogo_750x400.jpg
Found in: https://www.starch-smart.com/

Anyhow, I knew that those images were called out in my Splash Image URL field in the EasySocial Quick Registration module. So, I changed the url to be the secured copy of the image. And, then it my report went from two instance of that image to only one image that was not secured.
I then disabled the Community Registration module (EasySocial Quick Registration) and ran the test again and this time the padlock is GOOD for all tests.
I also enabled the Community Registration module (EasySocial Quick Registration) and set the option Enable Splash Image to NO and then ran the test again and this time the padlock is GOOD for all tests.
So, the extra image call is somehow hard coded or cached in the EasySocial Quick Registration module.

Any idea why this module is calling TWO instances of the image?
I am using version 1.2.4 of the EasySocial Quick Registration module.

Sean

Hello Sean,

I believe there are some redirection rules set in your htaccess or probably through the redirection plugin? Looking at the net request, there's a redirection from https: -> http: for this particular image as you can see here, http://screencast.com/t/jRjDEnFhL

Interesting. I am unable to find anything in my .htaccess file and there are no redirects with this in them. I am asking my host if they have another idea.

Also check your redirection component and also sh404 if you do use them

Sharing links are fine, but the assets from the remote site is a big issue. For instance, if your site https://site.com (https) has a content of http://siteb.com/image.png, then the browser will complain about the image. To fix this, in the next version it will be using an "internal proxy" as you can see here, http://screencast.com/t/IWz0iMceZfp so it would be less problematic.

Not only does browser complain about image of https -> http it also have problems with https -> https

Even tried the site http://www.whynopadlock.com/ and it shows everything as good. The ES dashboard shows the correct image when inserting link but it become broken after submit.

Very frustrating. Hopefully the proxy will solve this issue but where is the proxy pointing to? Same as site domain or external site?

Same as your site domain with https

I figured this thread is pretty much complete and if so I wanted to finish it by saying thank you to everyone who joined in the discussion. It helped to to get our https site launched at https://www.Starch-Smart.com with EasySocial, EasyDiscuss and EasyBlog as well as YooRecipes. :-)
I am very grateful....

Thanks for updating, glad that your issues are resolved now Congratulations on your recent launch !

Mark wrote:

Hello Sean,

The proxying of images would be available on 1.2.8 By the way, to test out the site's padlock issues, you could use this little useful tool, http://www.whynopadlock.com/

Hi Mark.
Just out of curiosity, where would I configure the proxying you mention above (you said in an earlier post it can be switched on or off). Considering making my site https but had issues in the past, so proxying might fix it.
Dave

If you are building a site that require payment or medical content then SSL is the option you should use! when it comes to google you should always remove the http:// from your link! Leaving the http:// in the link generate the insecure warning. And when it come to Proxying be very careful! The is an option hackers like to use when trying to get into your system.

You can easily setup your system to have all you images be pulled from your https:// instead of http:// if you have a SSL Cert.. When you are creating you articles simply add the full link to your image:

https:// your-site.com/images/photo11.jpg

most people just use the following option and this is where the insecure warning come in...
../images/photo11.jpg or images/photo11.jpg

You can also force Joomla to use SSL or you can add it to your htaccess file. By adding it your htaccess file it give you a bit more control and can patch up holes in most of your Joomla Components, Plugins, and Modules! You also place a htaccess file in your image directory in order to prevent a hacker from running anything in this folder. You can also have create a htaccess file to keep an eye on Easy Social especially when it comes to posting!

Always remember Easy Social is just a Component that runs on top of Joomla and any holes you don't plug up gives a hacker a way into your system! The one thing you have to do if you don't do anything else and that is control what your are able to upload and post in your system! It only takes one file in order to give a hacker control of your system...

And you can also use your htaccess file to control all your redirects when you are working from a https to http or http to https... you don't need to buy a plugin thats limited to Joomla!

Dave, most hosting companies only place a basic htaccess file in your root directory. It is up to you to slowly build your htaccess file. Admin Tools creates a basic htaccess file for you. But you will have to play with it, in order to get what you need! And Nick is always available to help... I tell my clients every chance I get to Think Like A Hacker, if you really want to protect your website.

Hello Dave,

The settings is located in Applications > Links

charles wrote:
And when it come to Proxying be very careful! The is an option hackers like to use when trying to get into your system.

Hi Charles, do you have any more info on this?

Mark, maybe you have a viewpoint?

I was going to enable Serve image urls via internal proxy, but now I'm a bit cautious!

Hello Mark,

I guess what charles was mentioning about is browser proxies and not image proxies. The image proxy which we use simply serve images to the browser

Ah yes, caveat emptor with those proxy sites!

Haha, but don't worry much on this

Mark wrote:

Hello Dave,

The settings is located in Applications > Links

Got it... of course, I've just discovered that EasyBlog and EasyDiscuss doesn't have the same internal proxy solution, so when pages with those components used, there is a mixed content problem! Any plans to introduce the internal proxy into them?
Dave

Hello Dave,

Those are rather tricky because we need to do a "search" and replace for huge amount of data as opposed to link sharing because we already captured the image when you chose the image when you shared the link.

Imagine if your blog post is 30,000 characters long and in between each paragraph, you embedded an external image. Doing a search / replace / match would definitely use tons of memory on the site and it will be pretty suicidal