13

Recently Google has indicated that a HTTPS certificate will be used as a positive signal in it's search rankings.

This has caused some discussion within our company as to if we should apply a HTTPS certificate to our new site.

However, our site contains no login details, does not carry user data, and is effectively static content.

This combined with the fact that Google has stated that it will only be used as a small factor, means that I feel like it would be overkill and not required.

However others at the company are saying "what's the harm, it can only help".

Other than the cost, are there any downsides to HTTPS?

Improve this question
7
  • 2
    Did you come across this java.dzone.com/articles/irony-googles-https-mandate ?
    – Darsstar
    Commented Aug 22, 2014 at 9:36
  • @Darsstar, the cost of a SSL cert is negligible even for a small start-up, and see my answer below why the performance issue is a non-starter.
    – Chris Murray
    Commented Aug 22, 2014 at 9:48
  • @ChrisMurray Since he asked for reasons other than the cost the reason I linked it were the to a lesser extent the performance, but mostly that third party resources you need have use the HTTPS protocol as well. Otherwise it gives a false sense of security.
    – Darsstar
    Commented Aug 22, 2014 at 11:10
  • @Darsstar, that article only mentions Google rankings being affected by thirdparty resources not using SSL. Nothing to do with a "false sense of security". Generally, delivering certain things (ads, etc) over non-SSL channels is not a worry - particularly when there's no sensitive data to protect anyway!
    – Chris Murray
    Commented Aug 22, 2014 at 11:15
  • This makes you wonder whether the ranking boost for having a fast site will be similar to the boost for having an encrypted connection. i.e. if you slow your site down by using HTTPS, Google will restore the balance by promoting your site for having SSL.
    – SilverlightFox
    Commented Aug 22, 2014 at 12:39

4 Answers 4

Reset to default
13

HTTPS gets you confidentiality (encryption), authentication (identity), and integrity (tamper-evident connections).

You don't care about so much about the first one in your case, but you should care about the second two. The "identity" part implicitly protects you from certain DNS attacks, but there is the chicken-and-egg problem (hence HSTS). There's also the "green URL bar" and all that nonsense, but that's mostly a side-show.

HTTPS has at least the following drawbacks:

  • it's slower on both sides (but not by much, and possibly hidden by bandwidth constraints)
  • it's got higher latency (more round trips, but not many more), this can be minimised with SPDY
  • it complicates legitimate analysis and troubleshooting (e.g. packet capture)
  • it may prevent some users from accessing your site (corporate policy, content scanning etc.)
  • the cert and CA chain can really add to connection overheads (there are potential workarounds like this)
  • you have do deal with a CA, and have an administrative process to deal with renewals (sadly more difficult in practice than it sounds)
  • more protocols means more configuration, more software, and a greater attack surface

(A less tangible drawback is getting on board the whole PKI/CA train, but let's not go there today...)

Improve this answer
13

Other than the cost, are there any downsides to HTTPS?

Yes, HTTPS traffic cannot be cached by third party proxies. If your content is highly cacheable (very likely if your site is mostly static content) and you have lots of users that have slower internet connection (e.g. most people in developing countries rely solely on slow, congested mobile network), caching proxies set up by their ISPs or mobile providers or corporate/university network cannot return a locally cached result. Instead they all have to go all the way to hit your server even when the same content has been requested thousands of times around the neighborhood.

This can be mitigated a little if these users install their ISPs proxy certificate, which allows the ISP to essentially do an MITM with the user's permission, but this will significantly compromise the security of sites that actually do need the security of HTTPS.

Improve this answer
4
  • 1
    3rd parties cannot cache resources under HTTPS, but 2nd parties can. If you actually need to provide localised caching for your resources, you can use a Content Delivery Network. Each CDN host, which users reach by anycast, can have the same hostname and SSL certificate, because each host is controlled by the same company. The SSL certificate can list a singular hostname and all possible IP addresses in the SubjectAltName section.
    – Stuart Caie
    Commented Aug 22, 2014 at 13:54
  • Don't forget Cache-Control: public which can help, as long as the cache can act as a HTTPS endpoint.
    – user
    Commented Aug 22, 2014 at 15:26
  • Cache-Control only controls browser caching in HTTPS, which isn't the issue here.
    – Lie Ryan
    Commented Aug 22, 2014 at 16:15
  • @StuartCaie: A 2nd party cache will still uses the ISP's external bandwidth usage. I am quite sure somewhere there are ISPs that distinguish between cached, local, and international bandwidth and have different pricing between them. Even if they don't actually distinguish them, the ISP's cost for external bandwidth will indirectly be reflected into your plan, so if everyone bypasses the cache that would force the ISP to increase price to cover cost.
    – Lie Ryan
    Commented Mar 2, 2015 at 12:18
4

HTTPS is still useful even without sensitive data being passed over the wire. SSL also guarantees identity, so the client knows that the information does indeed come from you and not someone else.

The only real downside for a long time was performance. However, this has largely disappeared now as SSL/TLS implementations have got better and technology has progressed. Check here for a detailed explanation.

Improve this answer
2

HTTPS is HTTP inside a SSL connection, that is you have yet another layer. This introduces overhead which can be a problem, see Is there ever a good reason _not_ to use TLS/SSL?.

As an additional layer it also introduces more complexity on the server side, because you get all the server-side problems of HTTP (application level DOS like this) and then the problems of SSL (like Hearbleed) on top.

This means, that you secure the data transport between client and server at the cost of increasing the attack surface of the server. There is no free lunch :(

Please don't understand this as an argument against SSL. Securing the transport layer is really important and has also advantages if you don't have obviously sensitive data (e.g. privacy). But, you have to be aware that you increase the attack surface and thus you have to be prepared to handle problems associated with SSL.

Improve this answer
5
  • If the argument against SSL is that there's no sensitive data to protect, I don't think you can claim the extra attack surface of SSL as a disadvantage (as currently much simpler attacks will succeed).
    – Chris Murray
    Commented Aug 22, 2014 at 10:24
  • I've edited the answer so that it does not look like that I'm against SSL. But the question was about downsides and if you don't know the problems you cannot prepare against them.
    – Steffen Ullrich
    Commented Aug 22, 2014 at 11:11
  • I definitely agree it's a maintenance overhead, but I think reducing MitM susceptibility is worth more than the increase in attack surface. I mean, you could use the same argument against firewalls, or any security feature.
    – Chris Murray
    Commented Aug 22, 2014 at 11:17
  • HTTPS is HTTP on top of TLS, not the reverse. Uulike say SMTP and its STARTTLS command, the TLS part is handled before any HTTP operation takes part in HTTPS.
    – Bruno Rohée
    Commented Sep 16, 2014 at 12:10
  • To make my wording more clear: HTTPS is the HTTP protocol spoken inside a TLS connection. What I originally meant was to say that you add add additional layer.
    – Steffen Ullrich
    Commented Sep 16, 2014 at 12:45

Not the answer you're looking for? Browse other questions tagged .