Ask HN: Half of YC company websites are SSL-only. Time for SSL-only internet?

by citizenkeys on 3/17/2013, 11:01 AM with 10 comments

As most, if not all, websites now do some form of e-commerce, is it time for an SSL-only web browser to force the transition? And what about sysadmins forcing SSL-only connections by only opening port 443 and not 80? Other than making sure routers have port 443 open, is there any reason not to force everybody to move to SSL-only?

I just checked the website of every known YC company of the last four rounds. About half are SSL-only now. Here's some stats of the SSL-only companies:

YCW13: 10/18 56%

YCS12: 26/69 38%

YCW12: 22/54 41%

YCS11: 23/57 40%

  • by itsprofitbaron on 3/17/2013, 4:53 PM

    I think it will eventually happen but for now there are still issues to overcome. For instance SSL-encrypted HTTP traffic requires more resources (mainly CPU and memory) on servers, than unencrypted HTTP. Although when Google moved to SSL [1], Adam Langley (a Google engineer) said[2]

      “all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.”
    So whilst SSL/HTTPS doesn’t require a significant amount of additional server resources SSL still introduces some latency in particular during the Secure Sockets Layer Handshake phase[3] and it still requires more memory. Although once the SSL Handshake is done, then latency is reduced slightly and you can also solve some of these issues by caching a lot of HTTPs requests and as Google have done, you can also solve the issue with higher memory usage by patching OpenSSL to reduce the memory allocated to each connection[2]:

      “OpenSSL tends to allocate about 50KB of memory for each connection. We have patched OpenSSL to reduce this to about 5KB and the Tor project have independently written a similar patch that is now upstream.”
    This leads nicely onto the issue of caching because, in the context of SSL encryption, browsers handle this differently and whilst some allow caching of SSL content, other browsers don’t or they only allow temporary caching in memory only which means that, the next time a user visits they have to download the same content, even if it hasn’t changed which affects website performance.

    Likewise, there’s also the issue of cookies – and you may think “I’m using SSL, everything is fine” actually it isn’t. If you are using SSL by default but the website still allows requests with unencrypted HTTP then it is still possible to steal cookies containing authentication tokens / session ids by issuing an unencrypted request towards the target website. This is a simple fix though – you can either flag the cookies as secure or you can make sure the web server hosting the web application enforces SSL.

    However, they aren’t the only reasons as to why, as many websites are using CDN’s to reduce load on their servers and to improve performance for their users depending on their geographical location. Thus this reduces latency and helps improve the overall performance of the site for their users. Now this is all good but, CDN’s are use for “static content” – content which doesn’t carry any sensitive information and doesn’t require server side processing. You can say that you could at the same time mix, SSL-encrypted information via HTTPS and serve the static content via HTTP for the same website but because of the way SSL is implemented in browsers, if a page uses SSL and includes content from normal HTTP – it shows the user a warning and for non-technical users (the ones with 100 toolbars) this may ‘scare’ them to leave the website.

    As a result, if you want to use SSL on your website, you need all the static content on your website to be served with the same SSL encryption which is a waste of resources. Likewise, SSL requires a certificate for each of the hostnames used to serve static content so if hostnames for the static content are being served by a CDN and are configured as CNAME records which are pointing directly to the CDN's server, requests for that static content will obviously go straight to the CDN servers rather meaning that those certificates must also be installed on the CDN servers for the CDN to serve the static content under those hostnames and with SSL encryption. As a result, website owners have to then provide the CDN company with the required certificates who has to install them on their servers. However whilst CDN providers do offer SSL support as it requires additional setup and a larger infrastructure to implement this then it can become expensive as most CDN providers do not even offer this possibility as they are predominantly optimised for unencrypted HTTP traffic.

    So if you’re using a CDN switching to SSL-only can become more challenging and expensive than expected.

    CDN’s aren’t the only issue you’re going to face either. There’s the other issue of serving content from third parties which you have no control over – I’m talking about the social sharing stuff etc – and whilst most of them support the SSL/HTTPS protocol not all of them do, and for the ones who do support SSL/HTTPS you need to ensure that you are using the right code snippet that automatically takes care of switching to either HTTP or HTTPS for the external content and you may have to modify your code to ensure that this happens.

    So if you are going to have SSL always on for your site, you need to ensure that all third party services support SSL because otherwise you’ll give your users browser warnings alongside some security concerns.

    [1] http://googleblog.blogspot.co.uk/2010/05/search-more-securel...

    [2] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

    [3] http://support.microsoft.com/kb/257591

  • by ig1 on 3/17/2013, 11:28 AM

    SSL is much more expensive to deliver at scale, it could potentially kill popular non-commercial websites as the costs of hosting would be much more expensive without the caching, etc. that non-SSL permits.

  • by _cbdev on 3/17/2013, 11:34 AM

    A more technical argument: Implementing SSL with name-based VHosts is pretty much impossible, making the use of a dedicated IPv4 or (alternatively) one Port per VHost neccessary.

  • by rmoriz on 3/19/2013, 1:58 AM

    One downside with going full-SSL is that your users cannot use tools like Google Translate anymore as those services don't work with ssl sites.

  • by askar on 3/21/2013, 9:10 PM

    Going full SSL might be a bit too extreme in most cases; best bet would be secure the ones that matter.

  • by seiji on 3/17/2013, 6:32 PM

    We should SSL all the things. No excuses.