How can I change all links in the store to be https if the site accessed via https?

I looked at the thread https://www.zen-cart.com/showthread....SSL-in-my-site and read the linked manual, then implemented the edits to the configure.php files, but still when opening my site using https:// protocol, the links remain http://

define('HTTP_SERVER', 'http://www.vintageelectronics.ca');
define('HTTPS_SERVER', 'https://www.vintageelectronics.ca');
define('ENABLE_SSL', 'true');

What am I doing wrong?

The instruction that you read relates to how to enable SSL for the pages that are to be considered SSL which include but are not specifically limited to, login, checkout, contact_us, etc...

In order to enable the full site (all pages) to be SSL, then your HTTP_SERVER address should be changed to include https:, and then ENABLE_SSL should be set to false instead of true. When set to true, then the system determines what page(s) should be presented with https: and will use that setting/option instead.

Now, that said, you also need to arrange for visitors to your site to go directly to an https: page, no matter what page they have entered in their URL. That requires either a change in your control panel with your host, or manually adding code/information into an .htaccess file that is at the root of your site. ZC does not require nor provide such a file because it is not seen as necessary, so you may want to work with your host or perform additional research either using the ZC forum search, an outside search engine (that may guide you back to this forum or to another site). There are multiple ways to implement the change with some working "better" than others.

Do be sure before you do all this changing that you can successfully access whatever page(s) you wish to access by typing in https: as part of the page load. You want to be sure that there are no web browser related errors where mixed content would exist on any loaded page (ie. if you have hard coded links that include src="http:... then access the page using https: a browser will typically indicate such mixed content exists).

Ohh and be sure to read/apply the information that DrByte posted about... Very useful and informative.

Quote:

---

Originally Posted by one tall man

but still when opening my site using https:// protocol, the links remain http://

define('HTTP_SERVER', 'http://www.vintageelectronics.ca');
define('HTTPS_SERVER', 'https://www.vintageelectronics.ca');
define('ENABLE_SSL', 'true');

What am I doing wrong?

---

Change this:
define('HTTP_SERVER', 'http://www.vintageelectronics.ca');

To this:
define('HTTP_SERVER', 'https://www.vintageelectronics.ca');
(both config files)

That is all.

Note: You will find a bit of debate as to whether define('ENABLE_SSL', 'true/false'); should be true or false. Fact is, with both HTTP_SERVER & HTTPS_SERVER being defined as 'https' this ENABLE_SSL setting becomes a moot point as all pages will be SSL enabled anyway.

Cheers
RodG

Quote:

---

Originally Posted by RodG

Note: You will find a bit of debate as to whether define('ENABLE_SSL', 'true/false'); should be true or false. Fact is, with both HTTP_SERVER & HTTPS_SERVER being defined as 'https' this ENABLE_SSL setting becomes a moot point as all pages will be SSL enabled anyway.

Cheers
RodG

---

... except that having ENABLE_SSL also set to true forces extra session regeneration and different cookie handling. In many cases this won't be problematic, but in some bizarre server configurations setting it to false resolves those odd issues.

Quote:

---

Originally Posted by DrByte

... except that having ENABLE_SSL also set to true forces extra session regeneration and different cookie handling.
In many cases this won't be problematic, but in some bizarre server configurations setting it to false resolves those odd issues.

---

Although I don't quite understand how this could be without having similar issues when an *actual* switch between SSL/NonSSL takes place (IOW, while the HTTP_SERVER' is not 'hhtps') I'm not going to argue about it, at least not with you <g>

It's just counter intuitive (to me) and I'd have expected that if there were going to be problems due to 'bizarre server configurations' it would be when all is set for SSL, but the ENABLE_SSL was set to false.

I shall keep your apparent observations in mind with any future comments I make in this matter.

Cheers
Rod

PS. Would I be wrong in assuming that a future update will do away with the http_server and the enable_ssl setting (and all the associated code) since its just a matter of time before we have no choice other than SSL everywhere anyway?

Quote:

---

Originally Posted by RodG

PS. Would I be wrong in assuming that a future update will do away with the http_server and the enable_ssl setting

---

In v1.5.5 that's already happened in the Admin: https://github.com/zencart/zencart/b...figure.php#L19
Further, in v160 there's no admin configure.php at all, since it simply uses the main /includes/configure.php
It's not fully done-away-with catalog-side yet, but refinements there are anticipated.

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

Quote:

---

Originally Posted by mc12345678

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

---

Very good questions. I can't wait to see the answers :)

Quote:

---

Originally Posted by mc12345678

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

---

This did also cross my mind, especially since it is about the only way that I can think of that would make the OP's request possible,

I wouldn't try it in a million years though - The security implications are *huge*. Just consider the case when (not if) a hacker tries to access the site using "ftp://domain.name:80"

The response will be from the server (port 80), but the FTP client won't render the html/php like a web client - it will show the 'raw' data , and since all URI's will now also be 'ftp' it wouldn't be difficult to have the ftp client load and display the config files complete with DB login details - all in plain text. (normal apache directives and .htaccess rules will no longer apply) ,

Game over.

Admittedly, I've almost certainly oversimplified things here - but the point I'd like to make is that *without* the http/https protocol specifier the opportunity for abuse by other protocols is both huge and unpredictable, so even though what the OP is seeking is possible (using this method) they really *shouldn't*.

Cheers
RodG

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.

---

This is something that many of us don't want.

Unfortunately, this is no longer really our choice - Google is demanding 'SSL everywhere' - and although I object to being dictated to in this manner (and our business can survive without Google), most ecommerce sites can't - So to survive - the future of eCommerce is 'SSL everywhere' regardless of what you and I want.

Quote:

---

Originally Posted by one tall man

All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Yes, it is possible, and yes you are correct about inheriting the protocol - but as I just wrote in a previous post, the security implications of this inheritance are huge.

mc1-8 has suggested how it would be possible (at least in theory) to do what you are seeking, with very little effort or changes, but if this is something that you would like to achieve *without* those risks, things become a lot more difficult. I *know* that this *should* be possible (without the risks). I've even had a few ideas how to make it so, but for each idea I've had so far, a little more thinking has me rejecting the approach as being unworkable for one reason or another. The more I think on it, the more complex the solution becomes (perhaps I'm over thinking it?)

Anyway, possible or not, easy or difficult, as I stated, we don't really have much of a choice these days - it's going to be 'SSL everywhere' - or a store that can't be found, and if it could be found, the warnings about 'insecure' is a nail in the coffin anyway.

Sorry to say, but IMO, you should give up on this idea, bite the bullet (as I have done), and do what Google is demanding us do (even if it is only for the benefit of Google, 'cos they sure aren't doing it for *our* safety).

Cheers
RodG

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Is that possible? Yes

Is it worth the effort? No

Bite the bullet and go SSL for all pages. I will disagree that SSL everywhere is a Google thing, although it may look like it at the moment. Once servers make the upgrade to using HTTP 2 (which is much better than what is used now), SSL for all pages becomes mandatory anyway regardless of whether the site is eCommerce or not.

Quote:

---

Originally Posted by Website Rob

I will disagree that SSL everywhere is a Google thing, although it may look like it at the moment.

---

Believe what you will. I prefer sticking to facts myself. <shrug>

For those the seek the truth, it can be found. Example:
===================================

Google has a phase it likes to use: “HTTPS Everywhere.” In fact, that’s what they named this year’s I/O Conference. The idea is that if every site implemented HTTPS, the web would be that much more secure; but, it’s a red herring. Here’s why:
HTTPS only protects against a very limited number of site vulnerabilities, specifically wiretapping and man-in-the-middle type attacks — in other words, spying. It makes the NSA’s job of tracking and spying on internet users more difficult, but it doesn’t protect against hackers, denial-of-service attacks and scripting, server or database exploits.
Essentially, HTTPS is useful for sites that collect and transmit personal information. Banks, e-commerce sites, even social networks need to have HTTPS in place to make sure consumers’ sensitive information is protected.
For all the blogs, news sites, brand brochure-type sites or any information site that doesn’t require a member login, HTTPS is useless. It’s like the post office telling you to that all your mail needs to be written in secret code. That’s fine for the military, but do your Christmas greeting cards really need to be written in unbreakable secret code? Probably not. It’s just as pointless to require HTTPS on sites that do not transfer sensitive information.
That’s why it doesn’t make sense for Google to consider using HTTPS as a ranking signal for the majority of sites and queries. If used at all, it will always be a very lightweight signal used on a very narrow set of queries, acting only as a tie breaker between two identically ranked pages.
No, this announcement is not about search quality. It’s about Google trying to get back at the NSA for making it look bad during the PRISM scandal, and it is doing this under the guise of a social cause — internet privacy under the “HTTPS Everywhere” banner.
It’s a classic “greater good” story. Google says HTTPS will be a ranking signal so that everyone runs out and switches to HTTPS. What they’re not saying is that this change will only affect a minuscule number of sites. For everyone else, they’ve wasted time and energy switching to HTTPS for no reason — but that’s okay, because it serves the greater good of improving privacy for the internet as a whole.

Ref: http://searchengineland.com/google-s...-really-201058

This is one of 1000's of references that can be found. Alas, I was unable to re-locate the one I was really looking for (It was something written by Google themselves in one of their own blogs, and I suspect that it has since been removed because it gave the *real* reason for their push for SSL everywhere - but to paraphrase what was written it was something along the lines of
"The increase of mobile applications that have the capacity to access all data on the device has changed the landscape for advertising potential that is giving our competitors valuable insights that is currently not available to us. In order to keep up and compete we need access to the same kind of data on a desktop computer that our competition has on mobile devices. Due to the sensitive information of some of this data we feel it our duty to ensure this data is kept 'secure', therefore we will be taking steps to ensure that all data transmitted be SSL encrypted"

So, reading between the lines here - They are, or have, made changes to their web browser (Chrome) that enables it to 'spy' on you and view any file on your system - even though there is no technical reason for it.

Needless to say, if they just came out and told people that they plan to spy on us in this way, there would be an uproar, so what they've done, is in addition to 'securing' the data they have no right to access in the 1st place, they've taken the route of pushing the 'SSL everywhere' to distract us from the fact that they only really need it to protect *themselves*. It is easier to hide a tree in a forest than an open field. Their plan has worked, people have fallen for the 'we are doing this your your security' , hook line and sinker - To the extent that almost everyone on the planet now equates 'SSL as being the end all and be all of 'security' - and that is *FAR* from the truth. As this article (and I) have been saying for many years "HTTPS only protects against a very limited number of site vulnerabilities".

What is more important to to me, and should be to others, is that *authentication* provides far more in the way of security than any amount of encryption. Give me an authenticated site *without* encryption over an encrypted site *without* authentication any day of the week. Hackers and scammers have zero problem setting up a fake site with encryption these days - and that alone make SSL *useless* - but we aren't being told that are we?

Prior to Googles' push for 'SSL everywhere' and their *massive* funding to provide free SSL certificates (Lets encrypt being the largest recipient of this funding) to make this possible, SSL certificates had to be purchased, and a part of the cost for this is because to obtain the certificate, the purchasers had to *prove* they were who they claimed to be (authentication) , so when folk visited a site with SSL they could be assured that they were on a *legitimate* site and not a 'copy' of the site that had been set up to steal your confidential data. The encryption aspect is/was or far less importance due to it only being 'protection of a limited number of vulnerabilities)

We no longer have this authentication. We no longer have the protection that SSL was designed to provide us. What we have instead, is encryption where it isn't needed, and the false belief that encryption protects us against things that it doesn't.

The internet (and our data) is less secure today with its SSL nearly everywhere than it was before Google decided that we need their 'protection'.

I really miss those days when SSL actually had *meaning*. I miss the fact that with the current Chrome releases I can't even click the 'secure' icon to even see who the certificate was even issued to. I no longer have an easy means to determine that a site I'm on is the site I *think* I'm on. I can no longer trust SSL to protect me from anything other than a rogue employee in a data center (or ISP), because that is the only possible place that my data can be 'sniffed' anyway. (assuming I'm not using WifI, which opens the possibility of MITM attacks).

I'm disappointed that many people that *should* know better (that authentication is more important than encryption) have either forgotten this, or never knew it in the 1st place. I get very frustrated that no matter how much I try to teach these things, I get tend to shot down because it is easier to believe the Google spiel than the many *experts* that have been fighting this trend for many years.

Sadly. The experts have lost the war - They (Google) have, with their injection of millions of dollars to provide SSL certificates to all and sundry, free of charge, with no authentication checks whatsoever, have made the internet less secure now than it ever has been, while at the same time, convincing most that it is more secure. It's a freaking joke, and we are all the worse of for it. :(

The war may be lost, but some of us continue the battle - Authentication will never return, but the battle to convince people that SSL != Security continues.

Cheers
RodG

Rod, I agree with you about Chrome which is why I refuse to install it on any of my devices. You might want to study up on HTTP/2 though, to see what's coming down in the near future. Although HTTP/2 itself "does not require" SSL, it is the Browsers that are forcing it to be used.

Quote:

---

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).

Although the standard itself does not require usage of encryption, most client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

---

May 14, 2015 Publish HTTP/2 as RFC 7540


Note also that later this year, PCI Compliance will require TLS 1.2 or better. The higher powers that be (ie. Credit Card Companies) are demanding more 'n more tighter security.

Overall, I'm sure you'll agree that faster loading websites is a good thing. With HTTP/2 they will be and noticeably so. It won't be long before HTTP/2 is the norm and that means using SSL.

Rob, i fear that this is getting to the stage where the mods are going to close the discussion, but before they do, you speak as though Ive never heard of http2 ???? dont know why you would think that. Secondly, you speak about its improved performance. I dont what this has to do with SSL or this discussion.
Where you did make a relevant comment (the bit about PCI) you appear to have ignored the fact that SSL is just one of many requirements, and TBH, I dont know of any website owner that complies with many of the other requirements, most of which are more important than SSL, but due to their nature wont be picked up by any PCI scans or any other software. This lack of compliance can only be determined by an onsite audit. .... but most importantly, how many times in my post did I stress the importance of *Authentication* ... in fact I stressed several times that this is/was a key issue in regards to security, and it this lack of Authentication that has negated the effectiveness of SSL and has made the WWW less secure now that it has ever been. How many times did *you* mention Authentication? ZERO. That both saddens and sickens me, because, running a hosting business you should know better. Encryption without Authentication if fcking useless. Heck, I even stated *why* (bad guys can and do encrypt Authentic looking websites). The original design of SSL was to *prevent* this. That is why we had CA's. Now that anyone can get an SSL cert without Authentication has made the CA's about as useful as an ashtray on a motorcycle. Basically, you appear to have ignored everything I wrote and all the important points I was making. You are still trying to push the SSL == Security line, When that couldnt be much further from the truth. SSL *used* to equal security, but all it offers today is encryption. It is not the same thing and those that promote it as such are promoting and propagating Google's lie.

Encryption is now a way of life, even where there has never been a need for it. No avoiding that, Authentication ... gone. Never to return. Google has ensured that.

Security is as important (or more imortant) today as ever, but as long as people are being constantly deluded into thinking that SSL today provides the same security as it did when it was created then we have a serious problem on our hands.

To re-iterate/stress a point from my previous post. *I* feel far less secure shopping online these days than at any time in the past (and I've been shopping online for nearly 30years). I have an advanced diploma in network security (nationally recognised). I undergo further training each year (Aust govt department of defence. Intelligence and security, or ASD as it is now known) ... but hey, lets ignore all that.... You're the real expert here, after all you run a hosting business, and that clearly makes you more qualified than I am on the topic. If you say SSL equals (or is essential) for security then it must be true. I dissagree.

PS. Since you broached the subject of http2 and urging me to read up on it, It may interest you to know that all of the sites we host have been (nominally)supporting this for quite some time by virtue of the CDN provider we use. All the the sites we host are also SSL enabled, by virtue of the same CDN (no ssl cert required). I'm not under any delusions that the sites are "secure" as a result of this. We use them for the significant speed improvements it provides, and a *huge* reduction in bandwidth used by our servers. I dont know how many sites you host, but if it is more than half a dozen you will be doing youself and you clients a huge favour by considering doing the same. The perfomance benefits and bandwidth reduction (also less server load) alone could make this worthwhile for you, but as a fan of SSL just think of the headaches it could save ... the ability to provide your customers free SSL without you needing to do a single thing on your servers to make it happen. How cool is that?

Whats even cooler, as that fact that it even brings a degree of Authentication back into the picture, 'Cos unlike a shared SSL (still the most common implementation), the CDN provided SSL actually matches the domain names on which they are used. Can it really get any better?

I know I've mentioned the CDN we use several times over the last few years, but for those interested (including website owners, not just hosting providers) the CDN provider is "cloudflare" - costs nothing and can be setup and working in just a few minutes

.... From the same wiki that you probably read about http2.....

CloudFlare supports HTTP/2 using nginx with SPDY as a fallback for browsers without support, whilst maintaining all security and performance services.[73] CloudFlare are the first major CDN to support HTTP/2 Server Push.

Highly recommended. I have no other association with them other than being a very happy user.

Quote:

---

Originally Posted by RodG

Very good questions. I can't wait to see the answers :)



This did also cross my mind, especially since it is about the only way that I can think of that would make the OP's request possible,

I wouldn't try it in a million years though - The security implications are *huge*. Just consider the case when (not if) a hacker tries to access the site using "ftp://domain.name:80"

The response will be from the server (port 80), but the FTP client won't render the html/php like a web client - it will show the 'raw' data , and since all URI's will now also be 'ftp' it wouldn't be difficult to have the ftp client load and display the config files complete with DB login details - all in plain text. (normal apache directives and .htaccess rules will no longer apply) ,

Game over.

Admittedly, I've almost certainly oversimplified things here - but the point I'd like to make is that *without* the http/https protocol specifier the opportunity for abuse by other protocols is both huge and unpredictable, so even though what the OP is seeking is possible (using this method) they really *shouldn't*.

Cheers
RodG

---

I'm staying on this topic for the moment.

I did in writing my previous response attempt to consider such "alternate" attempts to reach the site. But am/would be somewhat perplexed at how such abuse would function... I think at the moment that my head cold is limiting my ability to see it, but at any time one could attempt to load the site using such a protocol and be presented with whatever result is to be afforded, just like if both HTTP_SERVER and HTTPS_SERVER were set to https, if someone visits the site using http then there is no consistent built-in redirect to either of the two constants. Therefore it seems at least on first load such a ftp:// style attempt will provide the same result as any and all subsequent attempts...

Further, and somewhat unfortunately for security but fortunately for development, browsers are offering more onscreen page modification and therefore at any point in a page's presentation such an "insertion" or modification could be made.

Okay, so now that I've written that out, I guess I could maybe see where information from a protocol could be "incorporated" within a request and maybe used/abused because of the way some of the code might be written.

@rod

Quote:

---

'Cos unlike a shared SSL (still the most common implementation)

---

I sure hope that is not true. Shared SSL Certs should never have been allowed IMHO and we have never provided them for obvious Authentication insecurity. Is that the pea in your mattress; Shared SSLs?


@mc1-8

Notwithstanding the server has built-in and default redirect methods for handling Protocols and next the .htaccess file has its methods, are you advocating a "script" should also have a built-in default method for handling first load Protocol response and any redirection? I can see where that would cause problems for site owners.

Quote:

---

Originally Posted by Website Rob

@rod
I sure hope that is not true.
.

---

Still true - as far as I can determine - but this is changing *rapidly*

Quote:

---

Originally Posted by Website Rob

Shared SSL Certs should never have been allowed IMHO

---

Agreed.

Quote:

---

Originally Posted by Website Rob

and we have never provided them for obvious Authentication insecurity. Is that the pea in your mattress; Shared SSLs?

---

Yes the lack of Authentication is the 'pea in my mattress' - But you are still *completely* missing what *AUTHENTICATION* actually means, why it existed, and why it has gone the way of the Dodo.

I'm going to try this one last time. OK?

Back when SSL was 1st created, if I wanted SSL on my site (which I did) - I had to *buy* a certificate from a CA , such as Thawte, etc, etc. (there weren't to many of them back then). The cost was ~$1000 - And the reason it/they were so expensive is because before they would issue the certificate they had to verify that:

1) I ran a legitimate business (I had to provide them with details of business registration or similar)
2) A personal ID, such as a drivers licence
3) A copy of the business bank statements to demonstrate that the business hadn't just been created - possibly for nefarious purposes.
4) A phone number that matched the business details.
5) The domain name for the requested certificate needed to be directly related to the business.
... and possibly a few other things.

In addition to a hard copy of these (had to be faxed) they phoned and gave me a 100 questions (ok, perhaps not that many) - but they did phone to ensure the phone was for the business, and so forth. Only when *they* were convinced that I was who I claimed to be they would issue the certificate.

This ensured that people vising our site could *also* be 100% sure that we were legit, and the website rightly belonged to us, and our business. We had been *authenticated*.

Now skip forward to today.

I can register a domain name ($10). Lets say this is called "paypal.com.au' - No one checks if I'm entitled to use this domain name - $10, and its mine. I can also go to any number of sites/business and get a *free* SSL certificate for my domain name (paypal.com.au). No one checks if I'm entitled to use this domain name - No one checks anything. Automatically issued, on the spot.
I next find a hosting company to host the site - less than $4.00pm (I only want it for a month). Hosting company really doesn't give a damn about the domain name I want them to host.

In short, in less than 24hrs I can have a fully functional website 'paypal.com'au' complete with an SSL certificate that not only matches my domain name, but also passes all browser checks) - total cost $14.

I make a near exact copy of the *real* paypal website, complete with login boxes.

I now start sending out emails to all and sundry from my 'paypal.com.au' domain telling people that their PayPal account has been blocked (or has some other problem) and they need to login to verify something.

Unwitting recipients follow the link (taking them to my spoof site). None the wiser that 'paypal.com.au' has nothing to do with 'paypal.com' The email looks legit (coming from what look like a legit PayPal address, the page they end up on looks just like the'real' paypal. They get the 'green SSL icon', and can even view the certificate - paypal.com.au, which completes the illusion, so they proceed to log in ON MY SITE. I now have their PayPal login details. Just to complete the illusion I pop up a 'password failed' error message and redirect them to the *real* paypal site - They sign in there, can't see anything amiss and right off the 'email' as being some kind of mistake, I now have full access to their PayPal account, and no one is any the wiser.

So, even though the site (my phishing site) is fully SSL 'secured' - there really isn't *ANY* security here at all.

So, now lets go back to the days *before* the 'free' SSL certs were readily available (shared or otherwise) , and *authentication* was *required*. Would I risk paying ~$1000 to one of the CA's? knowing that there would be no way to 'prove' that I am, or even work on behalf of PayPal. They would reject the application, and I'd be $1000 out of pocket. Basically, with all the authentication checks needed there is really no way I could get an SSL cert for a fake site, or even one for a new site/business that *may* be set up for nefarious purposes.

IOW, whenever I (or anyone else) came across a site with an SSL cert you/we could be 100% certain that I'm not being phished or scammed, and the site itself is/was indeed owned by the business it claimed to be, and even that the business itself is legit and not just some 'fly by night' .

This authentication and the *security* it provided was so good, that most CA's even offered a financial guarantee that if you were 'scammed or phished' from a site using one of their SSL certs they would compensate for any losses.

- and THAT my friend is what SSL *authentication* was all about, and that is why *I* no longer feel 'safe' just because a site has a 'valid' SSL.

You may fool yourself and the world that 'SSL == security' but it really isn't. It's just encryption <shrugs>

Cheers
Rod

Quote:

---

You may fool yourself and the world that 'SSL == security' but it really isn't. It's just encryption

---

And what's wrong with "just encryption"? Let us agree that SSL is "a layer" of security, not an end all be all.

If we look at the levels of SSL Certificates available we see the onus is really on the site owner for the level of authentication they choose.

Shared SSL
- requires a hosting account

Domain Name SSL
- requires a hosting account
- requires CSR
- requires dedicated IP address

EV SSL (Extended Validation Certification)
- requires a hosting account
- requires CSR
- requires dedicated IP address
- requires Phone Call verification, copy of Business License and, if applicable, Date of Incorporation

And we wont' get into the problems caused by an incorrect CA bundle even if the SSL Cert is valid.

Sounds like you are saying everyone should use an EV SSL?

Quote:

---

Originally Posted by Website Rob

And what's wrong with "just encryption"?

---

Did you not read, or simply not understand that the 'bad guys' take advantage of the average persons *ignorance* of what SSL does, and doesn't provide? As long as people 'push' the idea that 'SSL == 'secure' then those same 'average' people will be/are happy and willing to enter confidential data (login details) into phishing websites under this *mistaken impression* that all is good and 'secure' . *THAT* is what is wrong with "just encryption". It gives people a *false* impression of security.
My example phishing site will fool almost *everyone* these days that it is a secure site, and in some ways it is - It prevents yet another 'bad guy' from encroaching on their own scam. The original bad guy is laughing all the way to the bank.

Quote:

---

Originally Posted by Website Rob

Let us agree that SSL is "a layer" of security, not an end all be all.

---

If you don't mind (and for the sake of this discussion) I'd rather not, on account of the fact that this 'layer' is so thin that it can be equated to blocking a single hole in a colander. (I may come back to this shortly with a real life, real time packet capture of a login page both with and without encryption)

Quote:

---

Originally Posted by Website Rob

If we look at the levels of SSL Certificates available we see the onus is really on the site owner for the level of authentication they choose

---

If we go back at the original design of SSL we see that the onus of authentication was in the hands of the CA's providing the certificate. The site owners (both the good guys and the bad guys) didn't get a *choice*. If the site was SSL enabled it was *fully* authenticated. - None of this "If I want a lesser authentication then it is my choice" crap, because it goes without saying, the bad guys will always opt for the least amount of authentication possible so that they than can carry out their phishing scam without question, and without be challenged?
Ignoring any cost issue, what possible reason would a legitimate site owner have of watering down their own level of trust? It simply doesn't make sense.

There was never even a thing of 'levels' of SSL - until the last few years, and if it weren't were for the ease and plethora of *unauthenticated* SSL certificates these days there wouldn't be need for these 'levels'

We have gone from SSL == 100% trustworthy.
to
Free SSL = No trust whatsoever,
to
EV SSL = Lets try to bring back some level of trust because we really fcked up by giving away SSL certs without any form of authentication.

Meanwhile, the poor old end users (customers) have been, and still are, totally oblivious to any of this - I doubt that you could find a single person on the planet (other than those of us that know really knows whats going on behind the curtain) that can tell whether any given website has 100% trust, zero trust, or something in between.

All they know is the little green 'secure' icon - which is applicable and nearly indistinguishable between any of them. Heck, this is the problem even *I* have these days. What chance does the typical internet user have when even someone like myself (who has spent a decade or two with a vested interest in network security) has a hard time knowing which sites can be trusted, and which can't?

Quote:

---

Originally Posted by Website Rob

Shared SSL
- requires a hosting account

---

phishing site - requires a hosting account

Quote:

---

Originally Posted by Website Rob

Domain Name SSL
- requires a hosting account
- requires CSR
- requires dedicated IP address

---

phishing site - requires a hosting account, requires a CSR, requires a dedicated IP.

If you don't understand why a CSR is required you don't know the components that make up an SSL certificate. In fact this is a *crucial* component of Authentication .

CSR = Certificate signing request. Anyone can create an SSL certificate, for any domain - but it won't function in any way until it has been 'signed' - it is this signatory that is responsible for 'signing' the certificate.

Example: I create a certificate for the domain 'paypal.com'au' - I do this by installing the openssl software (or similar) and running the command
openssl genrsa -des3 -out server.key 1024
I'm prompted for the domain name, location, email addy, and a few other things.

This creates a certificate for my chosen domain. It is currently *useless* and does nothing. It needs to be 'signed' before it can be used.

I now have two choices - I can 'sign' this certificate myself (using the openssl software). This will create a fully functional certificate that basically says 'This certificate is authentic for the domain name I gave - I signed it myself - you can trust me can't you ?

The web browsers, when coming across this certificate will do a check to ensure the domain on the certificate matches the domain of the website, and the encryption is enabled (this prevents 'hijacking' of a certificate/domain) - They *then* check to see who, or which CA *signed* the certificate. If they don't recognize the CA (which they wont with a self signed cert) - They give the alert that states 'Even though the certificate is valid for this domain and encryption has been enabled, I can't assure you that the site is owned by the company they claim to be) - I can't authenticate - Do you wish to proceed - if so, accept this certificate. If it is a bogus site its your problem not mine.

Or, I can submit this same certificate to a CA and ask them to sign it for me. Needless to say, the CA's aren't going to sign it just because I ask - so they do the *authentication* checks (as previously discussed) and if/when they are convinced I am who i say I am, and the domain is really mine they will sign this certificate as per my request (CSR).
When the web browsers now come across this *exact same certificate*they will check that the cert itself is valid (as before) - IOW, the domain name in the certificate matches the domain name of the website, and if so, encryption is enabled - but this time, when they check to see who or which CA signed it - if they recognize the CA it say "Cool. not only does the certificate match the domain name, It has also been authenticated by a 3rd party that I can trust - You are safe to proceed.

The dedicated IP requirement is (or should I was was) ... no, is, a technical requirement because it is used to 'salt' the encryption algorithms to prevent the MITM attacks - it is actually somewhat more detailed than that, but I fear that I'm already *way* beyond anything you need to know (unless you want me to give you a course on cryptography) - If I wanted to really simplify (and scare) lets just say that the current implementation of SSL where many domains can share the same IP address means that MITM attacks can't be fully mitigated with SSL, (in spite of whatever you have read). Basically, the fact that we *can* have SSL without a dedicated IP is another nail in the coffin in regards to encryption being 'secure' against this form of exploitation.

Quote:

---

Originally Posted by Website Rob

EV SSL (Extended Validation Certification)
- requires a hosting account
- requires CSR
- requires dedicated IP address
- requires Phone Call verification, copy of Business License and, if applicable, Date of Incorporation

---

This is a relatively 'new' implementation because some smart person finally realized that 'free SSL' with no authentication was a bad idea because it negated the single most important aspect of SSL - *authentication* , which by now has long gone the way of the dodo. It is a 'token' effort (best attempt) to bring back what had been lost with the plethora of unauthenticated SSL certs that are now commonplace. The end user (regular folk customers) still can't tell the difference between an authenticated cert, an unauthenticated cert, or an EV (token authentication - single phone call but no actual proof that the site hasn't been created specifically for nefarious purposes).

What is really 'clever' about this one is that even though the typical user can't tell one type of cert from another (bearing in mind that there was at one time only one type - and that one was 100% secure/authenticated) - it actually plays on the 'warm fuzzies' that it gives to the site owner. It's a bit like saying 'hey, I have paid some money here, and even had a phone call, so *my* certificate is 'better' (more secure?) than my opposition that is using a free certificate. What these site owners don't realize, is the customers really don't care, or more precisely, they don't know the difference - Putting it in less polite terms - Site owners that pay for these 'EV' certificates are suckers.

Quote:

---

Originally Posted by Website Rob

And we wont' get into the problems caused by an incorrect CA bundle even if the SSL Cert is valid.

---

Hmm, no, lets take this further - firstly we need to define what constitutes a 'valid' SSL certificate. First and foremost - *any* certificate that has been created for a given *host* that matches the host on which it is found is *valid* *please note - I said host, not domain* Until now, I've been using the term 'domain' rather than host. My mistake. Anywhere I've said 'domain' above - please ignore - I *really mean 'host' - in many cases, the domain *is* also the 'host'. (This is pretty important to understand, because it has a direct relationship to both authentication and encryption - eg: 'mydomain.com' could be authenticated but 'paypal.mydomain.com' could be a phishing site on a totally different server that has no association whatsoever with 'mydomain.com' (DNS hijacking) - This is why certs were once, and generally still are, only issued for a given host, and why a cert issues for 'mydomain.com' would produce and error if/when someone goes to 'www.mydomain.com' (or vice verci)

A self signed certificate is just as 'valid' as a $1000 Thawte Authenticated certificate, which is just as valid as an 'EV' certificate, which is just as valid as a free certificate from any source you care to mention. They all provide the exact same level of encryption. All are equally 'valid' (as long as the hostname in the cert matches the host (site) on which they are found.

So, now lets consider the 'CA bundle'. Firstly, there is no such thing as an 'invalid CA bundle ' - There are just two options here - A current 'CA bundle' or an obsolete 'CA bundle' - I guess you could consider an obsolete CA bundle as 'invalid' - but the more important thing is that that the 'CA bundle' that (I assume) you are referring to, is the one found on a webserver. This is *not* quite the same as the CA's that are found/used by the various web-browsers - The CA's in the web browsers are constantly updated with each new release of any given web browser. The CA's in the web browsers are used for the authentication processes when a person visits an SSL enabled website. (is this SSL cert self signed, was it signed by a company I can trust, was it signed by company that has gone rogue, and so forth.
The CA's found on a web server, serves the same purpose, but from the perspective of the web server - 'Hey. I've been asked to connect to paypal. Is the certificate I'm seeing legitimate? Has it been revoked, has a new certificate been issued and signed by a CA I can trust' and so on. IOW, the 'CA bundle' on a server server serves the same purpose as the CA's embedded into all the major web browsers, but they tend to be more static and often/occasionally need manual updating, depending on the server. IOW, the CA Bundle on a webserver can be as obsolete as fsck, and it will have no bearing/affect whatsoever on any persons visiting the website. - simple put, it is incoming data vs outgoing data. (from the servers perspective).

I don't wish to offend, but the mere fact that you encroached the topic of 'CA bundles' tells me that your understanding of SSL is severely lacking. It is nothing to be offended about - I'm trying (probably unsuccessfully) to teach you in a single post (or two), what took me 6 months of full time study to fully comprehend, but more than that - it is sh*t that most people don't even *need* to know. I am making this attempt because unlike most people, you are NOT the just the end user/customer, you run a hosting business, you *should* know more than the typical internet user - even though there is really no technical reason reason for it - I simply feel that in your position, you should know more than your clients - plus the fact that since you *do* run a hosting business you really are a lot smarter than the average bear - If I didn't believe this I really wouldn't be trying to 'teach' you these things. You really are a smart guy Rob, I've no doubt about that whatsoever - but heck, you frustrate me no end in that in regards to SSL/Security you seem to fall for the same fallacies and misinformation as the 'typical' end user that barely know how to turn a computer on.

Quote:

---

Originally Posted by Website Rob

Sounds like you are saying everyone should use an EV SSL?

---

Yes/no
If the typical end user knew how to tell whether EV SSL was being used, vs Authenticated SSL vs Free SSL (none of which was ever an issue/consideration when SSL was 1st devised) - Then heck yeah - EV SSL is far better (for those end users) than 'free/shared' SSL could ever be - it provides a token amount of authentication at a relatively small cost, compared to 'full' authentication, but the fact is, the end user/average person doesn't 'see' this, so it is a 'sucker' implementation that serves no purpose other than to to extract $$ from web hosts that would be equally served with a free SSL.
Even if you opt to pay ~$1000 for full authentication you, as a webhost, would be no better of for it, simply due to the lie that SSL == 'security'

Sorry, but this has taken me far longer than i had anticipated, as such I've not been able to setup and show you sniffed login page data to demonstrate how pointless encryption really is in comparison to Authentication (which is also pointless these days) - but like I said, I'm trying to teach you in a single message or two, what took me 6 months of full time study to learn.

My final words - Does SSL == security - No. I still feel less safe shopping online now than I ever have in the past.
Is SSL in any way secure? No, not any more - Might just as well use ROT13 (Google this if you've never heard of it before).

Is the encryption aspect of SSL a viable/valid 'layer of security? Yes, if you don't trust those that you should be able to trust anyway. (your ISP/Internet provider/webhost/NSA), otherwise, no, it as as useful/secure as plugging a single hole in a colander.

Rgds
Rod

We're off topic here but, I did want to mention that a DV cert no longer requires the dedicated IP as cpanel can properly separate domains from only one IP.

Let's get back to the topic.

Quote:

---

Originally Posted by mc12345678

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

---

So, I didn't get a response to the question asked in the first paragraph, but I have just considered this as a possibility, if this path is considered desirable.

At a point after the sessions have been loaded and perhaps after $request_type has been set, you set a session variable to indicate what type of URL was used to access the site. If it were https, then one value, if http another, but in either case the session value is set.

Then, at least when using ZC 1.5.5, there is now a notifier that allows you to pick up on link generation requests, though you would want to also ensure appropriate sequencing with any other plugin that attempts to use that notifier because you want the value to be set as desired before that other observer grabs hold of the data ($connection). Notifier to which I refer is found in includes/functions/html_output.php in the zen_href_link function.

In the new observer, if the session is set to https, then make the $connection variable = 'SSL' regardless of the original/previous request, if not set to https, then leave it alone and use whatever value to which $connection is set (don't modify the value of $connection).

I think that would accomplish the requested task, assuming it is still considered desirable...

I still have a prepared answer to a question I was asked earlier, but not sure if on topic for that one. :)

It may even be desirable to put the session setting value inside of the sessions code such that a visitor sees the session value, but a bot does not... Haven't thought that far through it yet. Awaiting "input". :)

Quote:

---

Originally Posted by mc12345678

Oye, that's an entirely different action/request. What is expected to occur at say the login page, or checkout? And then again after such page(s)?

The answer to can it be done? Absolutely it could. What is the "advantage"? What is the benefit that you are seeking to gain? Or what problem is trying to be prevented?

I'm wondering, though can't say that I've tried it if you changed your HTTP_SERVER to just //mydomain (dropping the http: and/or https:) how it would respond/react. The whole thing is deeper involved than just those one or two constants, but it makes me wonder.

---

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

Quote:

---

Originally Posted by one tall man

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

---

Okay, but, what is your consideration if a site visitor enters the site with http:, but at some point is redirected to https: like say they go to send the site owner a message using contact_us. When they then continue on their merry way, which if looking at product on the site would be via http: should they be "allowed" to return to http: or are you thinking that now that they have stepped "up" they can never step back "down"? (please BTW, that is a metaphorical up/down comparison, I am not saying as a comparison, but more like a logical on/off).

Quote:

---

Originally Posted by mc12345678

When they then continue on their merry way

---

They will continue over https which I have zero problem with.

Quote:

---

Originally Posted by one tall man

They will continue over https which I have zero problem with.

---

Per your design request and the discussion I provide above, no they would not go on/continue on using SSL, because the design proposed met the request: want all pages to be SSL if user entered SSL related webpage to access the site. Therefore, if they accessed the site using http: then the proposed solution would enable https: when it was expected to be used, but would return to http: when not so expected (ie. Product information pages, shopping cart, etc...) if they initially entered an https: uri, all pages onsite would be presented https: until they either logged out or their session expired (left the site for a long time).

To then continue on using SSL for each and every properly coded uri after visiting any page while SSL has been requested is a different solution.

Good thing I didn't go trying to write code today based on your design request, because would be back modifying things again or just letting someone else "correct" the situation.

Quote:

---

Originally Posted by one tall man

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

---

Quote:

---

Originally Posted by one tall man

If a site user enters the site via https, they expect that their entire session will be SSL encrypted.
If a site then redirects them back to http, their expectation is violated.

---

In this regard I see no benefit to you serving your site as http at all. If your goal is to have people purchase things, then since it only takes a few clicks before they need to use https for login or checkout, you may as well just use https for everything.
Setup for that is simple:

Change this:
define('HTTP_SERVER', 'http://www.vintageelectronics.ca');

To this:
define('HTTP_SERVER', 'https://www.vintageelectronics.ca');

I am lost in your academic debate and do not have time and resources to read even 10% of what is posted, but I know for certain from my customers' feedback that if they entered my site via https, they expect 100% of their interaction with the site to be SSL encrypted. I understand where they are coming from and have zero problem with their wishes.

If some however want to use http, they should be allowed to do so.

I redirects all to https and see no problem with it

Quote:

---

Originally Posted by one tall man

I am lost in your academic debate and do not have time and resources to read even 10% of what is posted, but I know for certain from my customers' feedback that if they entered my site via https, they expect 100% of their interaction with the site to be SSL encrypted. I understand where they are coming from and have zero problem with their wishes.

If some however want to use http, they should be allowed to do so.

---

You've read and replied to most of it already, so 10% of what remains was less than one word. The discussion was to attempt to provide specific custom design code to address your situation based on the expectations. The cleanest/clearest solution is as DrByte recommended which is to just make the full site https:.

Follow DrByte's recommended modification and it should satisfy those that wish to see a blue lock everywhere.

Quote:

---

Originally Posted by one tall man

If some however want to use http, they should be allowed to do so.

---

Neither you are your customer really get to decide. More increasingly, browsers are the culprits declaring that a site is insecure no matter if it is eCommerce or not just because is is using http versus https.

Quote:

---

Originally Posted by DrByte

Change this:
define('HTTP_SERVER', 'http://www.vintageelectronics.ca');

To this:
define('HTTP_SERVER', 'https://www.vintageelectronics.ca');

---

So in summary, if I want to update my site to https only, all I need to do is
1. make the change above, and
2. do a 301 redirect for all http calls to https, to ensure any hardcoded http calls will be redirected to https, right?
Thanks guys!

Can someone confirm that this is correct please? Thanks guys!

Quote:

---

Originally Posted by ttfan

Can someone confirm that this is correct please? Thanks guys!

---

The action to be taken or perhaps the condition to be in place is described at the following FAQ. There are setups that would be able to operate with just making the change to HTTP_SERVER, but that doesn't mean all can operate that way nor that all things will work with just that change away from a default store. Plus, not all current condition data has been provided. So, stick with the FAQ: https://www.zen-cart.com/content.php...alled-zen-cart

Thank you kindly. :thumbsup:

My second part of the question is not covered though. Will a 301 redirect in .htacess, redirecting all http calls to https, solve the mixed content issue? I know I have quite a few hard-coded images with a http prefix in some of my pages (like EZ pages or defined content pages), so I'm hoping this will fix it?

Quote:

---

Originally Posted by ttfan

Thank you kindly. :thumbsup:

My second part of the question is not covered though. Will a 301 redirect in .htacess, redirecting all http calls to https, solve the mixed content issue? I know I have quite a few hard-coded images with a http prefix in some of my pages (like EZ pages or defined content pages), so I'm hoping this will fix it?

---

No generally speaking an htaccess rule will not affect the mix of content on the page. The htaccess basically processes before the page is loaded and was designed to control access to the site. Mixed content comes from what is presented on the page which occurs after the visitor has been allowed to access the site. Further that "issue" is covered by yet a different FAQ: https://www.zen-cart.com/content.php...lly-encrypted)