Big websites for things such as banks (eg www.cimbclicks.com.my) and online shopping (eg www.lazada.com.my) don't seem to care to secure their front page with SSL but their login page is secured with SSL. Is there any technical motivation for not using HTTPS on the front page (such us decreased performance)?
-
5You should contact them and ask? There is no possible way we can explain the reasons a website doesn't use SSL– RamhoundSep 14, 2016 at 3:38
-
I thought that someone could possibly give a professional answer like https perhaps affect the performance of the front page .. etc.. but that's one answer that i got. thanks for the voting down unprofessionally.– MaXi32Sep 14, 2016 at 3:59
-
Ok I got the related question asked here: security.stackexchange.com/questions/16246/…– MaXi32Sep 14, 2016 at 4:07
-
1Both those sites do have HTTPS (e.g. cimbclicks.com.my is valid). It's just that the HTTP site does not redirect to the HTTPS site. When people are just viewing marketing material, not entering personal data, there's no massive need for HTTPS. Still, the trend is to use HTTPS everywhere, banks tend to be slow to follow, but they will eventually.– paj28Sep 14, 2016 at 8:50
-
1There will often be a senior guy that'll say "everything works fine with HTTP, why should we waste time/money into fixing something that's not broken?".– André BorieSep 14, 2016 at 11:06
|
Show 5 more comments
3 Answers
This is you thinking with your "nerd" brain and ignoring the ten different things which come into play when you talk about "security".
These are attitudes of the people running the site, their skill sets, their production/business working schedules about getting the site offline to do such work etc.
As for the techie aspects, yes you are absolutely correct that all sites must use https all the time and since you mention "big sites", there's netflix and others who are following that rule.
The SSL causing overhead arguments are no longer true and so is the meme that "only logins should be SSL". Read this post for more.
This says more about friction in enterprise processes than it does about technology.
For an enterprise to set up their website with https throughout, they have to sort out the certs and configuration up front. That requires a bunch of background management and security processes all of which add friction to the deployment project that is probably already under-funded and under pressure to deliver.
So it is conceptually easier for the project to implement a "standard" website then worry about the security once they have proved that the basic site is sufficiently robust and performant.
HTTPS does make some things more complex to manage and thinking about end-to-end caching strategies are a bit harder to manage.
None of these things are excuses really but that is my take, from experience, on the enterprise process.
It is changing and if you change the link to https you will find that it has actually been implemented so that might only be how the URL has been written and communicated - often by non-experts. http should be disabled of course.
Services such as the excellent Cloudflare are also helping since everyone can now present their site over https even without getting your own certificate (though you obviously still need at least a self-signed cert to help secure the traffic between your server and Cloudflare).
If the asset has any value which would be compromised by being exposed then there is no good reason for mixing SSL and non-SSL traffic. Arguably even if it has little intrinsic value, while people tend to re-use passwords, the operator has a duty of care to protect the password for its potential value elsewhere.
Since it's not unreasonable to expect that people will transition from the non-ssl to ssl part, there is a potential for an SSL stripping attack (not all browsers implement HSTS and certificate pinning, not all websites implement HSTS and pinning).
Yes there is a performance overhead (if I don't qualify that, then some bright spark will come along and say CPUs and cypher alogrithms are much faster - but the overhead is in the extra RTTs for negotiation). But the performance impact can be mitigated at a cost comparable to that of hosting and provisioning a certificate.
