Embracing HTTPS
open.blogs.nytimes.com
open.blogs.nytimes.com
Multi-domain certs are used because IPv4 space is full and Windows XP doesn't support Server Name Indication, which allows a unique cert for different domains at the same IP address. So if you want SSL on a shared IP address, and need to support good old IE6 over IPv4, multi-domain certs are necessary. XP still has 19% market share on line, as of October 2014. Everything else has supported SNI since 2007 or so.
I have a paper on this:
http://john-nagle.github.io/certscan/whoamitalkingto04.pdf
This identifies all the major front-end services using shared SSL certificates. Cloudflare has 36,280 second level domains tied to "*.cloudflare.com". Incapsula, the DDOS protection service, has 1471. Once you're past the top 20 such services, no site has more than about 100. Once IE6 has died off, the CAs can stop issuing certs containing unrelated domains. But not yet.
> SSL can be difficult for website administrators to set up.
> For sites that require more advanced SSL configurations, CloudFlare supports custom certificates from any certificate authority, full end-to-end SSL with robust certificate checking...
Just, wow. TLS is NOT hard to setup for a website administrator. I think I just lost a ton of respect for CloudFlare. Granted, most threats would be between the client and CloudFlare anyway(that is to say, on the wrong side of the tracks), but still....
* "Flexible SSL" - encrypted from client to Cloudflare using Cloudflare's cert, unencrypted from Cloudflare to host.
* "Full SSL" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host self-signed cert.
* "Full SSL (strict)" - encrypted from client to Cloudflare using Cloudflare's cert, encrypted from Cloudflare to host using a different host CA-signed cert.
(http://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tech...)
* "Keyless SSL" - encrypted from client to Cloudflare using the customer host's cert. Cloudflare doesn't have the customer's cert private key. They contact the customer's host for a session key for each session, and use this to encrypt from the client to Cloudflare. They decrypt at Cloudflare, and re-encrypt for the trip to the customer's host.
With the first three, you can see in the browser that this is happening. The host will be identified as "cloudflare.com" in the certificate. With "Keyless SSL", which is basically MITM with active cooperation from the end host, it looks at the browser end like you're encrypted end to end, but you're not.
One assumes that all of these are being "lawfully intercepted".
That's the problem. If you only use SSL/TLS for security-critical pages where there's a login or a credit card, you don't need some massive cloud-based service to cache your stuff. Many sites still use "transferring to secure site for shopping cart checkout". That's fine. If you use SSL/TLS for everything, now you have a load problem on the secure infrastructure.
That's why "SSL Everywhere" is security theater. To have "security" on pages that don't need to be secure requires weakening security on the pages that do.
Nah, you can still have separate secure domains with EV certs for taking credit cards. That way your customer's browsing habits and product preferences are protected from snooping by their ISP, the page assets are still cached and DDOS protected, and the credit card data is still sent to a separate domain without an intermediary.
The only thing still to worry about is your caching provider sending maliciously modified content that bypasses your secure domain.
EDIT: just read your answer below, my comment is off-topic. Sorry.
It really is – you might just be living in a bubble of competence!
I've got years of experience as a developer and sysadmin, and I still sometimes struggle to get SSL working correctly on a site. Sure, getting and installing a cert is fine – but the mess of making sure that third-party services don't break, and that redirects aren't messed up, and that other virtual hosts don't break… it can be a time-consuming effort, and probably difficult for someone with less experience.
Cloudflare have been pretty transparent with the service they're offering, so I find it hard to see this as a bad thing.
Regarding setting up SSL I'm reminded of this: https://news.ycombinator.com/item?id=8471877
This is doubly annoying for checking blogs that require https and redirect http. I have no way to check their RSS feeds.
That is true. But it the user's main concern is the legs of network from their location out of a local untrusted network (such as communal wireless) or country, that is definitely better than nothing.
> XP still has 19% market share
I don't worry about the security of XP+IE users any more. Anyone still there has chosen against good advice to remain insecure. It is their choice when there are other options available (both browsers that support modern standards on XP, and alternate OSs), it is their choice to have the certificate warning and more iffy security when they hit a site that needs SNI.
This article is funny... written by the CTO for nytimes (et al).. asks news sites to make a commitment to HTTPS... but fails to commit to it for NYTimes.
Dear Akamai: when are you going to make TLS 1.2 support free? Cloudflare has. :)
Lol.
Doesn't look like she's an NYtimes employee, but her name is on the article.. so: https://twitter.com/elenakvochko
Let's hope that twelve months from now, we're looking at a very different landscape. Kudos to NYTimes for issuing the challenge. At the very least, this is an important conversation starter.
1. Https is slower. From a practicality standpoint - is it that much slower to actually make a difference from a UX side of things?
2. I've implemented https on one of my sites, but in chrome, it's not full green, but appears as https with the broken lock. Any idea on what that means and how to fix it?
If you put a real web application on that server, enable all the bells and whistles (keep-alive, session cache, OCSP stapling, SPDY, etc), and configure your benchmark tool to make use of those features, the performance penalty of HTTPS becomes less than 5%.
And that was a couple of years ago on a relatively low-end VPS. Nowadays, the difference is probably even smaller.
Can you suggest a benchmark tool that can be used to give a more realistic figure than `ab`? I know jmeter can do session caching, but I find its interface baffling and I can't find a pre-made configuration.
I recently compared performance of my home ARM server when serving my blog through HTTP and HTTPS:
https://www.tablix.org/~avian/blog/archives/2014/11/cubietru...
By the way, did you use `ab` with the `-k` option when you ran those benchmarks? Testing HTTPS without keep-alive is utterly meaningless, since every browser aggressively reuses HTTPS connections nowadays.
Anyway, to get to your question; it can. Normally you wouldn't notice because you're close-ish to the servers and you have stuff like keep alive and TLS session caching(tickets or ID's) to mitigate the issue.. But under other circumstances such as the server being in the US and you are not in the America's the difference can be significant, particularly if session caching isn't working(or working properly) and of course on first request. You can mitigate this with geographical distributed endpoints but most sites won't bother with this.
- Link: https://www.bionicspirit.com/
- SSL Rating: https://www.ssllabs.com/ssltest/analyze.html?d=bionicspirit....
- Server is in Europe, here's a load test from New York: http://tools.pingdom.com/fpt/200PE/https://www.bionicspirit....
On nr. (1) it is not that big of a deal and for your own content SPDY can make a difference. Satellite connections are indeed problematic for HTTPS.
BTW - I have insisted on having my personal blog on HTTPS because I noticed that some public networks in hotels and public places are injecting content into websites. And so for me HTTPS is a way of signing my content.
Create a text file called curl-format.txt:
time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
----------\n
time_total: %{time_total}\n
curl -w "@curl-format.txt" -o /dev/null -s "https://mysite.com"
s/its secure alternative/a secure alternative/ s/,HTTPS,//
This NYT blog post reads like an advertisement.
If the newspaper is worried about guaranteeing the authenticity of its web content, then why don't they publish their SSL certificate in the print version? For scanning/OCR.
No third party CA needed.
When connecting to the desired website, I can check for the correct certificate myself, thanks. This is not a perfect solution, but it is better than third party CA's or letting third parties embed certificates in browsers where no user ever looks at them. In my opinion.
How about do it by the end of next quarter, seriously!?