9

I have a site... let's call it mysite.com. On this site, there's the sign up section which I think should be the secure part of this site.

a) Should I enable ssl on the entire site, or just the sign up part (e.g. signup.mysite.com) b) What are the pros and cons of enabling it for the whole site?

rockstardev
  • 13,479
  • 39
  • 164
  • 296

4 Answers4

6

It depends on what your site serves. If the data it serves is sensitive, then providing a full SSL encrypted connection is a bonus.

But, as others have mentioned you will eat your bandwidth. SSL encrypted data, be it images, HTML pages or other information is not (supposed to be) cached on the client, so every time the user restarts the browser the files are downloaded again.

I would agree with Vinay, provide signon/signup over SSL and then fall back to normal HTTP, then see.

The other approach may be to provide all your static content over HTTP while all the sensitive content over HTTPS (e.g. if you use systems like ExtJS then the pages are static files and the data is all retrieved via AJAX).

Of course, if you're serving sensitive information (e.g. banking information) where the data itself is always sensitive then go full SSL and eat the costs.

Jamie Love
  • 5,418
  • 6
  • 30
  • 33
  • 1
    If static content is provided by , let's say a content delivery network, won't this show an 'insecure content' warning? – Sam Vloeberghs Nov 02 '11 at 22:45
  • As far as I'm aware, yes it would. – Jamie Love Nov 22 '11 at 19:57
  • "provide signon/signup over SSL and then fall back to normal HTTP, then see." How do you envision this to work with secure cookies? Or how do you mitigate leaks of sensitive information when mixing ssl with non ssl traffic. – PeeHaa Aug 25 '13 at 16:39
  • 4
    This is [**absolutely incorrect**. Browsers do (and are supposed to) cache SSL-delivered content.](http://stackoverflow.com/q/174348/201952) – josh3736 Aug 25 '13 at 22:45
4

Using entirely SSL will not necessarily increase your bandwidth bills. Encryption does not make the data bigger. Be sure you enable Deflate compression aswell.

Where SSL might increase your bandwidth bill is some browsers (firefox) do not cache pages retrieved over SSL to disc. This means the next time a user visits your site after quitting thier browser, they will download every single bit of content again.

If you opt to ensure user privacy, make sure that any cookies your site sends out have the 'send over SSL only' flag set otherwise users can be tricked into giving out that cookie in clear with some very simple phishing.

SSL also means paying for a certificate signed by a meaningful CA, which in some cases will cost more than your brandwidth.

IanNorton
  • 7,145
  • 2
  • 25
  • 28
3

The pro is increased security and privacy for all pages on your site, and the down-side is lower performance because of the need to encrypt/decrypt traffic at both ends of the connection.

For some high-profile public sites such as GMail, which used SSL for sign-in only, there has been mounting pressure to make all pages use SSL.

I would say, try it and see if the performance is a problem. If not, well and good; otherwise you can always fall back to SSL for sign-in only.

Vinay Sajip
  • 95,872
  • 14
  • 179
  • 191
  • 1
    What you say about GMail is not quite true. It will switch you to ssl for sign in if you call the sign in page using normal http. If you call the sign in page using ssl (using https:) the rest of your session will be done in ssl. It has been this way for a while. – Pinochle Jul 31 '09 at 10:15
-8

Forcing entire site to use SSL will eat your bandwidth since all content is encrypted, including images. Please check apache ssl faq for more info

piotrsz
  • 1,132
  • 8
  • 12
  • 1
    Practically, how badly is bandwidth affected. Let's say the site has about 100 - 200 unique hits a days. Does that mean it will decrease significantly in speed and use up bandwidth much fast? – rockstardev Jul 31 '09 at 10:29
  • Caching in the browser does not (or should not) work over SSL. – Jamie Love Jul 31 '09 at 21:43
  • 3
    This is wrong information. You can CDN assets even over TLS. You can write client cache headers for the client to cache resources. TLS includes native compression including compression of full requests and of response headers, which goes well beyond HTTP compression. For most websites, TLS will add only minimal additional CPU use. – yfeldblum Jul 29 '11 at 19:18
  • Modern browsers will correctly cache assets retrieved over SSL if given a correct Cache-Control header. – Chris S May 10 '12 at 02:44
  • Actually client and server-side CPU usage would increase and could be more of a concern than bandwidth to me. However, in modern times computing resources are plentiful and serving a site entirely over SSL is good practice with little compromise. If your server struggles to serve assets over TLS then it is obviously reaching max capacity and will likely struggle without TLS. In an enterprise-grade solution images and assets do not even factor in as these would be served via CDN and TLS/SSL termination would be taken care of on the load balancer which is an extremely highly optimised appliance. – Gabe Feb 10 '14 at 16:43