Configurable SSL Setting Still Needed?

[Harald Ponce de Leon]

Hi All..

 

Is the configurable SSL setting to enable or disable https links still needed in 2016?

 

If SSL is available on the server, would it not be best to use it globally?

 

If this option is removed, it would allow to have just one set of urls/paths/domains in the configuration file, instead of two sets for http and https.

 

This would still work for shared servers with shared ssl certificates - all files would just be served through the shared ssl certificate directory.

 

Thoughts?

[azpro]

@@Harald Ponce de Leon

 

.. First of all - Thank you for your hard work lately -  Lots of commits and sensible changes! :thumbsup:

 

I believe it is good practice to serve every page through SSL ... SO for me YES use SSL globaly.

 

Best Regards,

 

Arjan

[Jack_mcs]

@@Harald Ponce de Leon What would happen if the shop didn't have an ssl and couldn't use a shared cert? If the urls would then default to http, how would this change be different than how it works now?

 

While the web seems to be moving to full ssl, it is not required. So while the core code may work with full ssl, changes a shop owner may want to make to the site, like including a link to some other site, won't work. Would there be a way to allow non-secure links on a page that doesn't need a secure link, like the home page?

[Harald Ponce de Leon]

@@Harald Ponce de Leon What would happen if the shop didn't have an ssl and couldn't use a shared cert? If the urls would then default to http, how would this change be different than how it works now?

Either http or https would be used for all links, so if https is available, all links would then use https. There wouldn't be a need for a ENABLE_SSL configuration parameter, just change the www address from http://your-shop-url to https://your-shop-url and the whole site would then be served over https.

 

Normal http links would still work, however it would be best for the web server to then automatically forward the request to be served over https. (We could do this as a poor-mans-solution as well)

 

While the web seems to be moving to full ssl, it is not required. So while the core code may work with full ssl, changes a shop owner may want to make to the site, like including a link to some other site, won't work. Would there be a way to allow non-secure links on a page that doesn't need a secure link, like the home page?

That's the problem now with the SSL, NONSSL, AUTO parameter in tep_href_link()/OSCOM::link(). Using just one www address (http or https) allows tep_href_link()/OSCOM::link() to form all links accordingly.

 

If a hardcoded link to an external resource is added, the same problem would occur regardless if https is requested and the resource link uses http. There is nothing we can do here - the external resource must be loaded through https.

[MrPhil]

1. External links should not force an override of HTTP with HTTPS, or vice-versa.

Take care that embedded content (CSS files, JS files, images, etc.) doesn't end up with HTTP on an HTTPS page. Drop "procotol" from URL in most cases?

If a shopowner doesn't want SSL, everything should be HTTP except for explicit external links (1), without complicated setup and overrides.

The Web is moving towards SSL for everything, so HTTPS by default is good (so long as it doesn't trap you if you don't have SSL).

Provide clear instructions on how to set up to use shared SSL services (possibly include a notice on each page that URLs look odd, and are not the expected domain, because of this).

Provide URL redirection (in .htaccess and possibly in PHP) to force HTTP->HTTPS for customers who forget the "s" and for old bookmarks on upgraded shops.

[Harald Ponce de Leon]

• External links should not force an override of HTTP with HTTPS, or vice-versa.

External links should not use tep_href_link()/OSCOM::link() so this problem has always existed and will always exist. If your OSCOM installation has ENABLE_SSL enabled, then all (hardcoded) external links must be https otherwise browser warnings will popup when a https page is requested.

 

Using // instead of http:// or https:// is a solution, but this is outside our control.

[burt]

The way forward (according to Google-god) is to SSL everything.

 

SSL slows down requests, but this is being actively looked at in the next iteration of HTTP.

I read a very good report a while back, but now cannot find it :(

 

My thoughts; 

Force SSL if SSL is available.

Raise an error message (but allow to continue) if SSL is not available (perhaps as part of the installation process).

[Harald Ponce de Leon]

Force SSL if SSL is available.

This isn't about forcing it ;) If ENABLE_SSL is enabled, that means the OSCOM installation supports https links. But tep_href_link()/OSCOM::link() has a NONSSL/SSL parameter to make only certain pages load through https (eg, the checkout pages). If ENABLE_SSL is enabled, then why not use https for all links.

 

If ENABLE_SSL is disabled, then nothing changes behaviour wise.

[burt]

Google says we should use it.  I think they give some weight in their search engine to sites that force SSL.

 

I'm trying to find that report I read...it was good.

[frankl]

This isn't about forcing it ;) If ENABLE_SSL is enabled, that means the OSCOM installation supports https links. But tep_href_link()/OSCOM::link() has a NONSSL/SSL parameter to make only certain pages load through https (eg, the checkout pages). If ENABLE_SSL is enabled, then why not use https for all links.

 

If ENABLE_SSL is disabled, then nothing changes behaviour wise.

 

Google has been recommending moving to SSL for over 2 years now, and offers a boost in the rankings for sites that do so (especially for transactional sites i.e. ecommerce). With SSL certificates to be had for free, there is no reason not to move an entire site to SSL apart from, as Gary mentioned, a neglible speed decrease; that is far outweighed by better security in an estore.

 

Google is proposing browsers "warn" users if their connection to a website is insecure, in effect penalizing non-SSL sites. Better to build SSL features into osCommerce now, and be an innovator, rather than being forced to down the path later.

[♥bruyndoncx]

i went full ssl over summer, but lost my site history in the search console going from http://www.domain.com to https://domain.com

so there is a little bit more to consider.

[greasemonkey]

i went full ssl over summer, but lost my site history in the search console going from http://www.domain.com to https://domain.com

so there is a little bit more to consider.

I've been considering this (forcing https site wide) for some time - decided not to for this exact reason.

 

However, not to get to far off topic, shouldn't there be an easy htaccess or the like fix - to 301 redirect http links to https????

[frankl]

@@bruyndoncx @@greasemonkey

 

How did you lose your site history in Google search console? They are considered as 2 seperate sites so both sets of data would still be there.

[Dan Cole]

 

@Harald Ponce de Leon

 

.. First of all - Thank you for your hard work lately -  Lots of commits and sensible changes! :thumbsup:

 

@@Harald Ponce de Leon

@@azpro

 

Couldn't agree more.  Harald has been grinding it out the last couple of days.   I can hardly keep up deleting the github notices as fast as he is generating them.   Thanks for pushing things forward Harald. :thumbsup:   I sense the release of 2.4 is just around the corner. :) :) :)

 

Regarding the SSL issue.  I think using SSL site wide makes sense.  With Google pushing it I been thinking about doing that anyway so it would definitely give me the kick I need.  It should also simplify things and avoid those occasional surprises when you find out that a browser is throwing those warning messages.  Besides I can't think of a good reason not to.  (w00t) 

 

Dan

[ArtcoInc]

Regarding the SSL issue.  I think using SSL site wide makes sense.  With Google pushing it I been thinking about doing that anyway so it would definitely give me the kick I need.  It should also simplify things and avoid those occasional surprises when you find out that a browser is throwing those warning messages.  Besides I can't think of a good reason not to.  (w00t)

 

FWIW ...

 

http://www.oscommerce.com/forums/topic/396632-shipping-quote-in-cart-2334-support-thread/?p=1731387

 

Malcolm

[azpro]

@@bruyndoncx @@frankl @@greasemonkey

 

 

i went full ssl over summer, but lost my site history in the search console going from http://www.domain.com to https://domain.com
so there is a little bit more to consider.

 

 

I've been considering this (forcing https site wide) for some time - decided not to for this exact reason.

However, not to get to far off topic, shouldn't there be an easy htaccess or the like fix - to 301 redirect http links to https????

 

 

Same here - I want to go ASAP to SSL site wide ... but also decided not to rush before all possible effects were tackled. Still not clear to me how to do it "safely" ...

[Jack_mcs]

@@Harald Ponce de Leon I think I misunderstood what you were originally saying. Thanks for the explanation. It sounds like what you are planning is a better approach.

 

For those wanting to switch to full ssl, there's no proof, except anecdotal, that switching to ssl will help with rankings so I wouldn't suggest doing it for just that reason. If you do switch, it is important to check all around the site to make sure all of the pages are secure. If one isn't, it could give your visitors the impression that your site is not secure and cost you a customer.

 

If do decide to switch, I suggest you do the following:

 

1 - Change the configure files to use ssl.

2 - Issue a 301 for http to https.

3 - Create a Property Set in your google search console (webmaster tools).

4 - If you have a sitemap, recreate it to make sure the links use https.

[greasemonkey]

@@Jack_mcs there is no question google is using SSL as a ranking indicator... it is clearly layed out here.

 

https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html?m=1

 

The only question is how significant of an indicator... as suggested above... I thinks it is small - but in this competitive world I'll take any advantage I can get.

 

As long as it doesn't make a duplicate content mess (hence the questions on the redirect).

 

Maybe you could give us an example of the redirect (keeping in mind most of us also use a URL rewritter)? I've seen many examples... but I just don't have the experience to know if they are correct.

[Jack_mcs]

@@greasemonkey I wasn't clear in what I said. To clarify, yes, google is using ssl as a ranking factor but there isn't any proof that it makes much, if any, of a difference. They originally said that the ranking of only the part of the top 1% of sites, or something like that, would be affected. They have never changed that, that I am aware of.

 

For redirecting, use any or all, of the first three lines along with the fourth line. Be sure there is a RewriteEngine On command before them.

RewriteCond %{SERVER_PORT} 80
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} ^www.domain\.com
RewriteRule ^(.*)$ https://www.domain.com/$1 [R=301,L]

[♥bruyndoncx]

SSL is a requirement for google shopping, going full SSL seemed to make more sense to me, than the split in SSL/non-Ssl pages, but I might be wrong.

in search console it is 2 different properties, so you loose the continuous reporting, and need to setup some sections again to avoid duplicate content.

I also had to make some script and css call protocol agnostic ("//xyz.domain.com"), so i could switch between http and https easily.

I actually setup my beta site to keep on using one or the other, just as a safety fallback measure if things really went wrong and I couldn't resolve things going forward with pure SSL.

[Jack_mcs]

@@bruyndoncx I'm not aware of google requiring ssl. Are you sure about that? I know they may disallow if the checkout is not using ssl but regular links are still allowed, as far as I know.

[Harald Ponce de Leon]

Here is a HTTP -> HTTPS redirect that can be done with PHP in application_top.php (this is for v2.4b1):

 

  if (($request_type === 'NONSSL') && ($_SERVER['REQUEST_METHOD'] === 'GET')) {
    $url_req = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

    if ('http://' . $_SERVER['HTTP_HOST'] === OSCOM::getConfig('http_server')) {
      $url_req = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

      HTTP::redirect($url_req, 301);
    }
  }

It only redirects GET requests - POST requests would require a form with javascript that submits it. As HTTP requests would still work (even linking to HTTPS resources), the POST request can continue through with HTTP.

 

If the webserver does a redirect already in the configuration (Apache htaccess, nginx conf) then that code will never run and will also take care of POST requests.

 

The "301" in the HTTP::redirect() call sets the header to 301 Moved Permanently.

[MrPhil]

 

google is using ssl as a ranking factor but there isn't any proof that it makes much, if any, of a difference. They originally said that the ranking of only the part of the top 1% of sites, or something like that, would be affected. They have never changed that, that I am aware of.

 

 

My understanding of what Google said several years ago, was that near term, SSL usage would not count for much, but over time they would start weighting it more and more in their search rankings. Have they officially changed this position since then?

 

In general, yes there is a performance hit when using SSL, but in a site where you need SSL in some places, it may be easier and cleaner overall just to go full SSL and not have to worry about switching back and forth. Only on a site where nothing could be considered sensitive information (including why you're looking at certain material in the first place!) would the performance hit possibly be considered a problem.

[Jack_mcs]

@@MrPhil They never officially changed that statement, at least that I am aware of.  If going full ssl doesn't affect the site (test it both ways with sites like gtmetrix) and none of the pages give unsecure warnings then switching to full ssl may be a safe bet.

[Harald Ponce de Leon]

SSL performance hit. Has anyone actually measured this? Can it be labelled as a "penalty" when it comes to the privacy of your customers? Which do you value more?

With so many cores in your servers CPU there shouldn't be a performance hit, and it should be considered a "feature" (LetsEncrypt :heart: ) and not a "penalty".