I am managing a shop that forces HTTPs on the register/login/account/checkout pages, but that's it, and I've been trying to convince people to force HTTPs on everything.
I know that it's recommended to use HTTPs everywhere, but not sure why.
Are there any good reasons to keep part of the site on HTTP ?
One good reason is that page perfomance has a massive impact on sales (there's lots of published studies) and SSL has a BIG imact on performance - particularly if it's not tuned right.
But running a mixed SSL and non-SSL is full of pitfalls for the unwary...
Exactly which pages you put inside SSL has a big impact on security too though - suppose you send a login form using HTTP with a POST target which is HTTPS - a trivial analysis would suggest this is secure - but in fact an MITM could modify the login page to send the post elsewhere or inject some ajax to fork a request to a different location.
Further with mixed HTTP and HTTPS you've got the problem of transferring sessions securely - the user fills their session-linked shopping basket outside the SSL site, then pays for it inside the SSL site - how do you prevent session fixation problems in the transition?
Hence I'd only suggest running a mixed site if you've got really expert skills in HTTP - and since you're asking this question here, that rather implies you don't.
A compromise solution is to use SPDY. SPDY requires SSL but makes most sites (especially ones that have not been heavily performance optimized) much faster. Currently it's not supported by MSIE - and (last time I checked) is not enabled by default in Firefox. But it's likely to make up a large part of HTTP/2.0 any time soon.
Using (good) CDNs over HTTPS also mitigates much of the performance impact of SSL.
There's really no need to use HTTPS on the whole website. Using HTTPS will cause the server to consume more resources as it has to do extra work to encrypt and decrypt the connection, not to mention extra steps/handshake in negotiating algorithms etc.
If you have a heavy traffic website, the performance hit can be quite big.
This will also mean a slow response time then using plain on HTTP.
You should only really use HTTPS on the parts of the site you actually need to be secure, such as when ever the user send important information to your site, completes forms, logs in, private parts of the site etc.
One other issue can be if you use resources from none secure URLS, maybe images/scripts hosted elsewhere. If they are not available over HTTPS then your visitors will get a warning about an insecure connection.
You also need to realise the fact HTTPS data/pages will hardly ever get cached. this will also add a performance penalty.
Related
I have a hosted webserver with http/2 (medium fast) and additionally I have a space on a fast CDN-Server with only http/1.1.
Is it recommended to load some ressources from the CDN or should I use only the webserver because of http/2?
Loading too many recources from the CDN could be a bottleneck due to http/1.1?
Would be kind to get some hints...
You need to test. It really depends on your app, your users and your servers.
Under HTTP/1.1 you are limited to 6 connections to a domain. So hosting content on a separate domain (e.g. static.example.com) or loading from a CDN was a way to increase that limit beyond 6. These separate domains are also often cookie-less as they are on separate domains which is good for performance and security. And finally if loading jQuery from code.jquery.com then you might benefit from the user already having downloaded it for another site so save that download completely (though with the number of versions of libraries and CDNs the chance of having a commonly used library already downloaded and in the browser cache is questionable in my opinion).
However separate domains requires setting up a separate connection. Which means a DNS lookup, a TCP connection and usually an HTTPS handshake too. This all takes time and especially if downloading just one asset (e.g. jQuery) then those can often eat up any benefits from having the assets hosted on a separate site! This is in fact why browsers limit the connections to 6 - there was a diminishing rate of return in increasing it beyond that. I've questioned the value of sharded domains for a while because of this and people shouldn't just assume that they will be faster.
HTTP/2 aims to solve the need for separate domains (aka sharded domains) by removing the need for separate connections by allowing multiplexing, thereby effectively removing the limit of 6 "connections", but without the downsides of separate connections. They also allow HTTP header compression, reducing the performance downside to sending large cookies back and forth.
So in that sense I would recommended just serving everything from your local server. Not everyone will be on HTTP/2 of course but the support is incredible strong so most users should.
However, the other benefit of a CDN is that they are usually globally distributed. So a user on the other side of the world can connect to a local CDN server, rather than come all the way back to your server. This helps with connection time (as TCP handshake and HTTPS handshake is based on shorter distances) and content can also be cached there. Though if the CDN has to refer back to the origin server for a lot of content then there is still a lag (though the benefits for the TCP and HTTPS setup are still there).
So in that sense I would advise to use a CDN. However I would say put all the content through this CDN rather than just some of it as you are suggesting, but you are right HTTP/1.1 could limit the usefulness of that. That's weird those as most commercial CDNs support HTTP/2, and you also say you have a "CDN server" (rather than a network of servers - plural) so maybe you mean a static domain, rather than a true CDN?
Either way it all comes down to testing as, as stated at the beginning of this answer it really depends on your app, your users and your servers and there is no one true, definite answer here.
Hopefully that gives you some idea of the things to consider. If you want to know more, because Stack Overflow really isn't the place for some of this and this answer is already long enough, then I've just written a book which spends large parts discussing all this: https://www.manning.com/books/http2-in-action
This article mentions and this site seems designed to show that HTTPS can be faster than HTTP. I'm surprised; I thought HTTPS was just HTTP plus encryption, which adds a small, likely negligable amount of work but doesn't remove any.
Why might an HTTPS page load be faster than one over HTTP?
It's a bit of a con to be honest.
HTTPS is slower than HTTP. There's no denying that. HTTPS works over HTTP so has to do everything HTTP does and more. Now, with good web server config, the computational cost of HTTPS is almost non-existent to the average user on today's modern hardware but it is there. But it also slows down the first page render as it takes a few hundred extra milliseconds to set up the HTTPS connection. Again not a big deal for most people but it is there.
Now there is the argument that someone - be it a mobile network or ISP or whatever - can change HTTP by injecting ads and the like, potentially slowing down a website, but that's not the reason for the speed difference here.
The reason that website is faster is because it is using HTTP/2 when using HTTPS and not when using HTTP. HTTP/2 is faster than HTTP/1.1 - especially for websites with lots of resources.
Of course you can say that HTTP/2 is only available over HTTPS and while that is true*, the corollary is not - implementing HTTPS does not automatically give you HTTP/2.
*Well technically it's not true that HTTP/2 requires HTTPS as per the spec, but all the browser makers have said they will only support this over HTTPS so it basically is true to all intents and purposes.
Additionally the sample website loads 360 small and near identical (but crucially not identical) resources. Precisely the sort of thing that HTTP/2 is very good at. And while average web pages are growing, most of them don't load 360 near identical images - so that network latency is basically the only bottleneck. Most have other issues as well that are nothing to do with the network latency issues that HTTP/2 massively improves.
The speed gains for HTTP/2 are hugely impressive and it is the future and everyone should use it, as latency is a major bottleneck. But that test site is an extreme example of it. Depending on the exact site's make up, HTTP/2 will mostly offset the cost of HTTPS and in many cases more than offset it - but that does not mean HTTPS itself is faster.
There are very good reasons to use HTTPS, and the article is fantastic for listing them all (except for that first one). In my opinion HTTPS should be the default and everyone should move to it - precisely for the other reasons listed. But it's a lie to say HTTPS is faster that HTTP. Or, at the very least, it obfuscates the truth by not explaining why it can be faster. And then listing HTTP/2 as a second, seemingly unrelated, reason to further confuse the reader! I just don't understand why they couldn't combine these two points into one and fully explain this so questions like this didn't need to be asked? Same for that sample site - why is there no FAQ to explain why HTTPS is apparently faster?
Historically yes, https was http+ssl/tls, so it was slower
But now with spdy/http2, it's a new protocol, which can be faster than http when dealing with multiple requests:
it can compress headers, and if you send the same header multiple times (like cookies) it doesn't need to send it fully but just an id
if can reuse tcp connections, so it avoid the overload of opening multiple tcp connections and stream efficiently data
If you use some kind of network scanner (e.g. a component of an antivirus, proxy of firewall), it may scan plain HTTP traffic causing a slowdown. At the same time, it won't touch encrypted HTTPS traffic unless you installed a special root certificate that will help the intermediate scanner to process HTTPS traffic. So if there is some kind of intermediate service scanning HTTP traffic, but not HTTPS -- using HTTPS will be much faster.
I have a site that works very well when everything is in HTTPS (authentication, web services etc). If I mix http and https it requires more coding (cross domain problems).
I don't seem to see many web sites that are entirely in HTTPS so I was wondering if it was a bad idea to go about it this way?
Edit: Site is to be hosted on Azure cloud where Bandwidth and CPU usage could be an issue...
EDIT 10 years later: The correct answer is now to use https only.
you lose a lot of features with https (mainly related to performance)
Proxies cannot cache pages
You cannot use a reverse proxy for performance improvement
You cannot host multiple domains on the same IP address
Obviously, the encryption consumes CPU
Maybe that's no problem for you though, it really depends on the requirements
HTTPS decreases server throughput so may be a bad idea if your hardware can't cope with it. You might find this post useful. This paper (academic) also discusses the overhead of HTTPS.
If you have HTTP requests coming from a HTTPS page you'll force the user to confirm the loading of unsecure data. Annoying on some websites I use.
This question and especially the answers are OBSOLETE. This question should be tagged: <meta name="robots" content="noindex"> so that it no longer appears in search results.
To make THIS answer relevant:
Google is now penalizing website search rankings when they fail to use TLS/https. You will ALSO be penalized in rankings for duplicate content, so be careful to serve a page EITHER as http OR https BUT NEVER BOTH (Or use accurate canonical tags!)
Google is also aggressively indicating insecure connections which has a negative impact on conversions by frightening-off would-be users.
This is in pursuit of a TLS-only web/internet, which is a GOOD thing. TLS is not just about keeping your passwords secure — it's about keeping your entire world-facing environment secure and authentic.
The "performance penalty" myth is really just based on antiquated obsolete technology. This is a comparison that shows TLS being faster than HTTP (however it should be noted that page is also a comparison of encrypted HTTP/2 HTTPS vs Plaintext HTTP/1.1).
It is fairly easy and free to implement using LetsEncrypt if you don't already have a certificate in place.
If you DO have a certificate, then batten down the hatches and use HTTPS everywhere.
TL;DR, here in 2019 it is ideal to use TLS site-wide, and advisable to use HTTP/2 as well.
</soapbox>
If you've no side effects then you are probably okay for now and might be happy not to create work where it is not needed.
However, there is little reason to encrypt all your traffic. Certainly login credentials or other sensitive data do. One the main things you would be losing out on is downstream caching. Your servers, the intermediate ISPs and users cannot cache the https. This may not be completely relevant as it reads that you are only providing services. However, it completely depends on your setup and whether there is opportunity for caching and if performance is an issue at all.
It is a good idea to use all-HTTPS - or at least provide knowledgeable users with the option for all-HTTPS.
If there are certain cases where HTTPS is completely useless and in those cases you find that performance is degraded, only then would you default to or permit non-HTTPS.
I hate running into pointlessly all-https sites that handle nothing that really requires encryption. Mainly because they all seem to be 10x slower than every other site I visit. Like most of the documentation pages on developer.mozilla.org will force you to view it with https, for no reason whatsoever, and it always takes long to load.
Our company runs a website which currently supports only http traffic.
We plan to support https traffic too as some of the customers who link to our pages want us to support https traffic.
Our website gets moderate amount of traffic, but is expected to increase over time.
So my question is this:
Is it a good idea to make our website https only?(redirect all http traffic to https)
Will this bring down the websites performance?
Has anyone done any sort of measurement?
PS: I am a developer who also doubles up as a apache admin.
Yes, it will impact performance, but it's usually not too bad compared to the running all the DB queries that go into the typical dymanically generated page.
Of course the real answer is: don't guess, benchmark it. Try it both ways and see the difference. You can use tools like siege and ab to simulate traffic.
Also, I think you may have more luck with this question over at http://www.serverfault.com/
I wouldn't worry about the load on the server; unless you are serving high volumes of static content, the encryption itself won't create much of a burden, in my experience.
However, using SSL dramatically slows down web sites by creating a lot more latency in connection setup.
An encrypted session requires about* three times as much time to set up as an unencrypted one, and the exact time depends on the latency.
Even on low latency connections, it is noticeable to the end user, but on higher latency (e.g. different continents, especially Australasia where latency to America/Europe is quite high) it makes a dramatic difference and will severely impact the user experience.
There are things you can do to mitigate it, such as ensuring that keep-alives are on (But don't turn them on without understanding exactly what the impact is), minimising the number of requests and maximising the use of browser cache.
Using HTTPS also affects browser behaviour in some cases. Certain optimisations tend to get turned off for security reasons, and some web browsers don't store objects loaded over HTTPS in the disc cache, which means they'll need to get them again in a later session, further impacting the user experience.
* An estimate based on some informal measurement
Is it a good idea to make our website
https only?(redirect all http traffic
to https) Will this bring down the
websites performance?
I'm not sure if you really mean all HTTP traffic or just page traffic. A lot of sites unnecessarily encrypt images, javascript and a bunch of other content that doesn't need to be hidden. This kind of content comprises most of the data transferred in a request so
if you do find feel that HTTPs is taking too much out of the system you can recommend the programmers separate content that needs to be secured from the content that does not.
Most webservers, unless severely underpowered, do not even use a fraction of the CPU power for serving up content. Most production servers I've seen are under 10%, even when using some SSL traffic. I think it would be best to see where your current CPU usage is at, and then do some of your own benchmarking to see how much extra CPU usage is used by an SSL request. I would guess it isn't that much.
No, it is not good idea to make any website as only https. Page loading speed might be little slower, because your server has to perform redirection operation unnecessarily for each web page request. It is better idea to make only pages as https that may contain secure/personal/sensitive information of users or organization. Even if the user information passing through web pages, you can use https. The web page which have information that can be shown to all in the world can normally use http. Finally, it is up to your requirement. If all pages contain secure information, you may make the website as https only.
My last couple of projects have involved websites that sell a product/service and require a 'checkout' process in which users put in their credit card information and such. Obviously we got SSL certificates for the security of it plus giving peace of mind to the customers. I am, however, a little clueless as to the subtleties of it, and most importantly as to which parts of the website should 'use' the certificate.
For example, I've been to websites where the moment you hit the homepage you are put in https - mostly banking sites - and then there are websites where you are only put in https when you are finally checking out. Is it overkill to make the entire website run through https if it doesn't deal with something on the level of banking? Should I only make the checkout page https? What is the performance hit on going all out?
I personally go with "SSL from go to woe".
If your user never enters a credit card number, sure, no SSL.
But there's an inherent possible security leak from the cookie replay.
User visits site and gets assigned a cookie.
User browses site and adds data to cart ( using cookie )
User proceeds to payment page using cookie.
Right here there is a problem, especially if you have to handle payment negotiation yourself.
You have to transmit information from the non-secure domain to the secure domain, and back again, with no guarantees of protection.
If you do something dumb like share the same cookie with unsecure as you do with secure, you may find some browsers ( rightly ) will just drop the cookie completely ( Safari ) for the sake of security, because if somebody sniffs that cookie in the open, they can forge it and use it in the secure mode to, degrading your wonderful SSL security to 0, and if the Card details ever get even temporarily stored in the session, you have a dangerous leak waiting to happen.
If you can't be certain that your software is not prone to these weaknesses, I would suggest SSL from the start, so their initial cookie is transmitted in the secure.
If the site is for public usage, you should probably put the public parts on HTTP. This makes things easier and more efficient for spiders and casual users. HTTP requests are much faster to initiate than HTTPS and this is very obvious especially on sites with lots of images.
Browsers also sometimes have a different cache policy for HTTPS than HTTP.
But it's alright to put them into HTTPS as soon as they log on, or just before. At the point at which the site becomes personalised and non-anonymous, it can be HTTPS from there onwards.
It's a better idea to use HTTPS for the log on page itself as well as any other forms, as it gives the use the padlock before they enter their info, which makes them feel better.
I have always done it on the entire website.
I too would use HTTPS all the way. This doesn't have a big performance impact (since browser cache the negociated symmetric key after the first connection) and protects against sniffing.
Sniffing was once on its way out because of fully switched wired networks, where you would have to work extra hard to capture anyone else's traffic (as opposed to networks using hubs), but it's on its way back because of wireless networks, which create a broadcast medium once again an make session hijacking easy, unless the traffic is encrypted.
I think a good rule of thumb is forcing SSL anywhere where sensitive information is going to possibly be transmitted. For example: I'm a member of Wescom Credit Union. There's a section on the front page that allows me to log on to my online bank account. Therefore, the root page forces SSL.
Think of it this way: will sensitive, private information be transmitted? If yes, enable SSL. Otherwise you should be fine.
In our organization we have three classifications of applications -
Low Business Impact - no PII, clear-text storage, clear-text transmission, no access restrictions.
Medium Business Impact - non-transactional PII e.g. email address. clear-text storage, SSL from datacenter to client, clear-text in data center, limited storage access.
High Business Impact - transactional data e.g. SSN, Credit Card etc. SSL within and outside of datacenter. Encrypted & Audited Storage. Audited applications.
We use these criteria to determine partitioning of data, and which aspects of the site require SSL. Computation of SSL is either done on server or through accelerators such as Netscaler. As level of PII increases so does the complexity of the audit and threat modelling.
As you can imagine we prefer to do LBI applications.
Generally anytime you're transmitting sensitive or personal data you should be using SSL - e.g. adding an item to a basket probably doesn't need SSL, logging in with your username/password, or entering your CC details should be encrypted.
I only ever redirect my sites to SSL when it requires the user to enter sensitive information. With a shopping cart as soon as they have to fill out a page with their personal information or credit card details I redirect them to a SSL page.
For the rest of the site its probably not needed - if they are just viewing information/products on your commerce site.
SSL is pretty computationally intensive and should not be used to transmit large amounts of data if possible. Therfore it would be better to enable it at the checkout stage where the user would be transmitting sensitive information.
There is one major downside to a full https site and it's not the speed (thats ok).
It will be very hard to run Youtube, "Like"boxes etc without the unsecure warning.
We are running a full forces secured website and shop for two years now and this is the biggest drawback. We managed to get Youtube to work now but the "Add this" is still a big challenge. And if they change anything to the protocol then it could be that all our Youtube movies are blank...