6

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 using media queries but I am concerned--especially for mobile users--about the increased bandwidth.

How much will doing so increase my bandwidth or slow load times? 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?

Simply put, I have read articles saying the entire web would be more secure if everything was SSL but my actual knowledge of implementation is limited to payment gateways and log-in pages and such. I apologize for the open-ended nature of the question but anything, even just simple answers to the specific questions is welcomed.

Improve this question
3
  • Original search of this site didn't turn up a suitable answer but I followed a few related links threads and found info indicating this probably isn't a good idea. For instance, apparently YouTube videos (which I sometimes make and embed) is not served over https, and while the post was 2 years ago, apparently there can be caching and/or indexing problems. If this incorrect or out of date please detail. Thanks
    – adam-asdf
    Jul 11, 2012 at 3:00
  • If external links (to a jQuery library) are HTTP on an HTTPS page then the user will get notified that "this page contains insecure content".
    – MrWhite
    Jul 11, 2012 at 11:26
  • 1
    While the answers in this thread have all been quite good, I do want to note that in the last couple days I started to learn about the SPDY Apache settings (handlers? protocols?). That speed up, and from my understanding compress, SSL connections. So if you come across this down the road, you should look into it.
    – adam-asdf
    Aug 22, 2012 at 6:48

3 Answers 3

Reset to default
4

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.

Improve this answer
3
  • I always thought that HTTPS content is not cached by the browser, hence the increase in bandwidth (and slower response) since the browser will always request a new page? Is this not the case (anymore)?
    – MrWhite
    Jul 11, 2012 at 11:34
  • 1
    According to this article stackoverflow.com/questions/174348/… they probably will cache content.
    – paulmorriss
    Jul 11, 2012 at 13:10
  • Thanks for the replies everybody. When I did a little more digging (as noted above) what I found was basically the issues you all raised: the mixed content warning; added bandwidth for encryption/decryption; sites that don't serve linked or embedded content over SSL; questions about indexing, SEO, and cache. In short, while I will keep it in mind, right now there are too many unknowns for me to risk the problems when I have enough on my plate with a re-design. Thanks,
    – adam-asdf
    Jul 12, 2012 at 11:16
2

(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 https:// 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.

Improve this answer
4
  • In the newest (a few months old) Google styleguide for HTML & CSS link they advocate omitting the protocol so that resources can be accessed by whatever means are appropriate. That ability is news to me.
    – adam-asdf
    Jul 27, 2012 at 9:31
  • @user1332729, indeed, that makes sense if their CDN have the same URL mapping between http:// and https:// (I was just pointing out that they were offering https:// here).
    – Bruno
    Jul 27, 2012 at 9:33
  • apparently I took too long editing that last comment...I hit return for a new paragraph and it posted. Oh well, thanks for the link I'll read more carefully and process.
    – adam-asdf
    Jul 27, 2012 at 9:38
  • @user1332729, after re-reading your comment at the top, this should be of interest (if you haven't seen it already from the other question I've linked to).
    – Bruno
    Jul 27, 2012 at 13:21
-1

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.

Improve this answer
9
  • 2
    HTTPS is not vulnerable to MITM attacks, if the user has normal certificate verification in place. That's the whole point.
    – Bruno
    Jul 26, 2012 at 0:35
  • @Bruno: Google "sslstrip" and use your brain. Considering this "bam,wham,thank you ma'm" tool exists since 2009, you may want to rethink your voting policy, if you get my drift.
    – john
    Jul 26, 2012 at 12:04
  • You don't seem to know how sslstrip works. It MITM-attacks the HTTP connection before getting to HTTPS, for those who rely on an upgrade, or spoofs the cert with its own (which you won't trust). If you expect HTTPS to start with, and if you get a certificate you trust, you're OK.
    – Bruno
    Jul 26, 2012 at 12:06
  • 1
    From the sslstrip page: "It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links.". That's an attack against upgrades and initial HTTP content, not against HTTPS. That's why HSTS is useful.
    – Bruno
    Jul 26, 2012 at 12:10
  • 2
    No, they can't. I connect to my bank website using https://mybank/ directly, and I don't ignore certificate warnings: sslstrip doesn't work here. Again, sslstrip attacks the content obtained via plain HTTP, to prevent you from getting the https:// links (or rediction). If you expect HTTPS for a site, you're OK. Again, that's why HSTS (HTTP Strict Transport Security) is being deployed, to make sure browser expect HTTPS when it's available.
    – Bruno
    Jul 26, 2012 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.