

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

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?<p>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:<p>YCW13: 10/18 56%<p>YCS12: 26/69 38%<p>YCW12: 22/54 41%<p>YCS11: 23/57 40%
======
itsprofitbaron
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...](http://googleblog.blogspot.co.uk/2010/05/search-more-securely-
with-encrypted.html)

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

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

------
ig1
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.

~~~
citizenkeys
Got any specific details of how this makes hosting more expensive and
difficult to scale? If the browser and all web servers have the same
certificate, I don't see much of a challenge in going SSL-only.

Also, I did some research after posting. Google Chrome now has an HTTPS-only
mode: [http://www.cgisecurity.com/2009/01/httpsonly-mode-added-
to-c...](http://www.cgisecurity.com/2009/01/httpsonly-mode-added-to-chrome-
browser.html)

And the EFF has released extensions for Firefox and Chrome that apply HTTPS to
all websites: <https://www.eff.org/https-everywhere>

~~~
silvestrov
SSL uses a lot more cpu on the server for static pages/images.

SSL prohibits caching of resources by ISP, universities etc which reduces
their internet bill.

~~~
codesuela
FWIW addressing point 1: The difference in pricing when using Cloudfront for
serving 10.000.000 files (in the US) over HTTPS opposed to unencrypted is 2.5$

------
_cbdev
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.

~~~
citizenkeys
Apache httpd supports Server Name Indication (SNI) since Apache 2.2.12:
[http://stackoverflow.com/questions/517336/apache-name-
virtua...](http://stackoverflow.com/questions/517336/apache-name-virtual-host-
with-ssl)

Configuration can be found at:
<http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI>

------
rmoriz
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.

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

------
seiji
We should SSL all the things. No excuses.

