One More Thing: Keyless SSL and CloudFlare's Growing Network | Hacker News Reader

One More Thing: Keyless SSL and CloudFlare's Growing Network

blog.cloudflare.com

60 pointsjgrahamc20 comments

Not true at all: "With most of CloudFlare's rival services, even those that have a seemingly larger network footprint, the minute you ask them to enable SSL the size of the network shrinks to something that resembles our network today. That's because they too don't feel comfortable storing customers' private keys in many of their edge nodes. And that's why most legacy CDN providers charge such such an enormous premium the minute you ask them to support SSL."

They are perfectly capable of running SSL on the Edge. The reason for the increased price is that you will get a dedicated IP which in most cases means not only 1 IP but 1 IP per region in which the CDN is active. And IPs are becoming a scarce resource. You can also see this expressed in the fact that if you accept a shared IP and SNI certificate (so not EV) you'll get lower prices of most of the major CDNs.

Personally, I find CloudFlare to be annoying as a TOR user. They keep bothering me with a Captcha to solve.

I sympathise.

I run a lot of forums and we use Stop Forum Spam to block spammers from posting comment spam. They are identified and reported according to three things: 1) Email address, 2) Username and 3) IP address.

The IP address is the most effective way to stop comment spam, and I only block people based on "Has spam been received from this IP according to StopForumSpam.com within the last few days?".

Understand that the vast majority of spam comes from several countries, and Tor.

I'm massively in favour of using Tor and having it as a privacy/anonymity tool. But... Tor is also heavily favoured by spammers and whilst the Tor exits are not explicitly blocked in the system I use, the mere fact that spammers use Tor heavily means that the IP addresses for Tor exit nodes are constantly being refreshed on StopForumSpam.com .

Anyone running any kind of IP reputation is going to have the same problem, and CloudFlare do run their own IP reputation.

It's nothing against Tor, but if an individual mixes their traffic in with a stream of spam, trolls, script kiddies, etc... and the behaviour of those users affects the reputation of the IP, then the innocent Tor users who merely want privacy/anonymity are going to be affected.

It's a difficult balance to strike, but any IP reputation system is going to score Tor badly given that it is used for so much abuse and bad stuff.

I'm curious if people would use exit nodes which specifically blocked comment submission on sites. I use Tor frequently, but never for posting comments.

It's an interesting proposal, that perhaps the things that degrade the reputation of Tor nodes could be blocked by Tor nodes.

Not just comment spam, but to have the equivalent of mod_security be run over an exit node and to deny traffic that triggers it.

This wouldn't reduce privacy/anonymity, but would avoid the IP address from having its reputation damaged (in turn enhancing privacy/anonymity as the exit nodes can be protected and thus prove more useful to good users).

Yeah, we already see this with exit nodes having "cautious" policies about not allowing ssh, smtp, etc.

Being able to advertise some kind of filtered outbound on specific higher-risk traffic types so you can offer those at all might be nice. I'd have no problem offering ssh to an opt-in whitelist of destinations.

Exactly... Tor nodes that don't just let anything through, but do let "safe" (to some agreed definition) web traffic through. Then a client could say "only exit via safe nodes" and you'd have this much better chance that the exit hadn't been used for the nefarious purposes that were likely to have resulted in an IP being blocked or challenged.

I get what you said in the earlier comment, but it sounds like CF would run a node and people would need to connect to it. I'm not sure of the implementation details, but either that's only a single hop through Tor (thus reducing the privacy/anonymity), or you're still making a single entry/exit point be the focus of all traffic from a given user (reducing privacy/anonymity by creating a single target for state attacks - likely court order based).

There's got to be a way to keep the multi-hop high-privacy and high-anonymity for those who need it, without having those users treated the same as those using Tor to hide various attacks (spam, the kind of attacks the CF WAF mitigates the risk of, etc).

I think this idea of Tor nodes that are trusted to have implemented various policies, and that only exit traffic that has filtered out attacks (and obvious spam), kinda works. By protecting the IP reputation of the exit node, we get a Tor that isn't being penalised and affecting the end user experience and that doesn't reduce the privacy/anonymity stuff that is important.

I didn't mean for CF to run a Tor node (I'd be in favor of that, but I wouldn't want to run a lot of them, although having all traffic destined for cf go through special Tor infrastructure on top of everything else in a normal Tor session would be fine).

I just meant for anyone running Tor exit nodes -- it would be cool if those people could configure some kind of filter on their exit node to do this filtering.

The security check captchas are in no way Tor-specific.

The shared Tor IP happens to have a threat score based on past traffic we've seen from that IP. This would be the same for any shared IP though -- like a VPN service IP address.

As other folks have mentioned, we're working on better handling for shared IPs in general, but to make this clear: this in no way has anything to do specifically with Tor users.

They are trying to solve this by treating Tor exit nodes / shared IPs differently: https://news.ycombinator.com/item?id=8297192

Most TOR IPs are flagged as abusive because of... abuse. SO, you wind up with extra CAPTCHAs to solve or outright blocking from being able to post content.

My guess: exit nodes are responsible for a number of attacks against CloudFlare-protected sites so it makes sense to question each visit from those IPs.

The data comes from project honeypot - the IP you are using has been flagged for abuse in the past.

I'm surprised this Keyless SSL thing hasn't taken more flack here on HN...

To me it seems the only advantage is in the time dimension: Keyless SSL allows for quicker/easier revocation than plain SSL. But to say that Keyless SSL allows SSL termination in insecure locations, that's clearly controversial. An attacker can still access plain text in these insecure locations of course, but also (in my mind more importantly): persistent access to the "Keyless SSL Key Server" gives an attacker the same benefits as access to SSL private key, e.g. the ability to MITM SSL communication anywhere else on the Internet.

It can of course be argued that it's more difficult inject malicious requests to the key server than it is to steal a private key, but it's in the domain of "security by obscurity". At least that's how I classify it.

Converting the SSL key from a file to a separate oracle is exactly how HSMs work, and they were existing best practice in securing keys. Keyless works the same way, just remotely, and using commodity stuff (although the local key at the user's site can live in an EKCM system, in an HSM, or otherwise be protected.)

As you say, it's a big deal for revocation. It's ALSO a big deal for auditing -- you know every time a session was initially negotiated, vs. if you give someone else the key -- you have no idea how many sessions were set up. It's also just a policy/compliance thing -- not needing to go through the process to be approved to store keys from organizations makes our sales process a lot faster.

There are some fairly obvious extensions to the security model which are in the works as well.

The reason why I think it's obvious there are security advantages to keyless is that we're using it internally. For us, consolidating our keys in a smaller number of secure locations is totally worth it.

> Keyless works the same way, just remotely,

Again, you can attach to a remote HSM. It's called a network attached HSM. They're not even uncommon.

A smart card is an HSM. An HSM is not necessarily a smart card.

It has:

- https://news.ycombinator.com/item?id=8339705 top comment

- https://news.ycombinator.com/item?id=8334933 further down

> [We have been] hiring cryptographers out of Apple

Is that really something to boast about? I never think of Apple as a hotbed for cryptographic genius

On the platform security side, Apple is about 5y ahead of the rest of the industry. Look at iOS specifically, and the secure element/trusted boot/etc. process.

(This isn't a general iOS vs. Android argument; I prefer Android in a lot of ways, just not for security.)

The problem with Apple is they do everything, and with very small teams, and end up with elements of widely varying quality. Their online-services security, to date, has been subpar. They aren't terribly fast with patches for known vulnerabilities. They are exceptionally good at platform security architecture.

(We've also got a really smart security guy from a satellite tv company...the satellite tv crypto/hw security world was >10y ahead of everyone else for a long time.)

Has there been a release of iOS yet for which there hasn't been a root exploit released?

Honest question, just based on the prevalence of "rooting" your device and running non-blessed software.

Reply on news.ycombinator.com