: Https (SSL) instead of http for mobile users I am building myself a new website, out of privacy and security concerns I am contemplating trying to make it https only. It will be mobile-friendly

@Kimberly868

(You may be interested in this related question on SO: Make full site HTTPS / SSL? What performance issues & best practices still apply in 2012?)

How much will doing so increase my bandwidth or slow load times?

Once the handshake has completed, the encryption is done using symmetric keys. There is a bit of overhead for the SSL/TLS records, but it's actually quite small (according to Google engineers, there's about 2% of network overhead).

What's costly is the handshake (both in terms of CPU and network). Without session resumption, you'll have to get the server certificate (about 1KB for a cert with a 2048-bit RSA key, this depends on the attributes). The round trips can also increase latency (and might be a bigger problem on mobile devices). I presume some mobile devices at least support session resumption.

The biggest handshake traffic I've seen were due to a long certification authorities list in the Certificate Request TLS message, when using client-certificate authentication. This was configured with a default trust store (on a Java server). A good server setting can avoid this problem (when you use client-cert authentication, you can usually limit yourself to a few CAs you're willing to accept, from a server point of view, you don't need the default list, which in this case had 100+ names).
If you're not even using client-certificate authentication at all, make sure you don't enable it (even optionally), so that you won't have this problem.


For pages where I'm not transferring sensitive information, should I
leave external links (to a jQuery library, or a web font for instance)
in http?


Yes, never mix content. It defeats the purpose of HTTPS. The issue with mixed content is that you no longer know which part of the page you can trust. It's a UI issue (and mobile browsers are already quite poor in terms of making it clear what security conditions you're under).

You can use CDNs that support HTTPS if you need (Google Libraries API provide links, for example, including for jQuery).
Modern browsers should cache HTTPS content by default, although some might not, in which case you can use the Cache-Control: public header. You should also prevent caching of the sensitive pages.

Vote Up Vote Down

@Nimeshi995

HTTPS does not offer any strong security - since it is vulnerable to a MiTM attack. It just makes it a bit harder (just a bit). I don't see the advantage gain over the cost for having a full https site.

Vote Up Vote Down

@Goswami781

The bandwidth shouldn't increase by that much. There's a bit of extra negotiation when an https connection is set up, and because encryption pads things out to a certain block size pages might get slightly bigger.

The load times might increase because of the overhead in encrypting the page at your end and decrypting the page at the user's end. I can't say by how much because I don't know your hardware and neither of us know how powerful the user's mobile devices are.

If you have a secure page with non-secure content then the user's browser may give a worrying error message.

I would only encrypt the pages with sensitive information on them.

Vote Up Vote Down