Hacker News Reader

You have just given me what I think is a very good possibility regarding a marketing message, namely that we are not subject to NSA orders, and that we take security extraordinarily seriously.

You certainly won't be the first with that idea. I've now lost count of how many blog posts, tweets, forum posts and so on I've seen in the past week that essentially say, "Is the next big selling point for European service companies that we're not subject to US laws?"

The UK is not exactly an ideal location to make a fuss about this from, given that the Regulation of Investigative Powers Act (2000) gives extensive rights to the government to demand covert surveillance, which includes requirements of confidentiality over interception warrants to the extent that they in some circumstances can not even be revealed in court.

On top of that Part III of RIPA makes it an offense to fail to disclose your encryption keys to the government in certain circumstances, and the court does not need to actually prove that you have the keys in order to sentence you for failure to produce them.

The UK has quite a strong military sector with their own secret agencies and a strong relationship with America.

Could that make them capable of similar monitoring? Does the UK have stronger information privacy laws that the US doesn't?

The laws are build on different principles making them somewhat different. However, one of the things that we pay a lot of attention to is security resilience. The question is, "what has to be compromised before your data is compromised? and is there a way to detect it?" The storage is still something we are working on but you can believe it is a design goal.

The EU has very different approaches again to privacy law. I don't know you can compare them. They tend to be more lax with collection and stronger with use.

However, we can also help you install the software (open source, reviewed by developers all over the world) on your premises if you would prefer. So our best shot is only for those who really want to cloud host.

If you're outside of the US, then yes you are not subject to NSA orders. But your data will still be accessed by the NSA, as the NSA won't require an order to read what you've got.

The point is they cannot get a court to compel you to hand it over. Yes, they can take what they can get.

And my point is that what they can get without a court order is more than they can get with one.

But the return on investment is likely to be far less. If it is harder, more resources have to be spent, then they will be more selective if just because it would be prohibitive to bug every system across the world, at least at present.

>But the return on investment is likely to be far less.

I am not so sure about that. The internet... well, many of the wide-open holes have been closed... BGP hijacking isn't as trivial as it was in '08[1], mostly because filtering has been implemented in some places, but it's still something that could be done by someone of, say, my resources. It's trivial to anyone with real resources.

And there are all sorts of other possible attacks. Hell, even ignoring the (probably easy, for one of the three letter agencies) possibility of putting a backdoor in the firmware shipping on popular routers, well, most ISPs end up using ancient router firmware revisions on their routers[2]

Yeah; read over that BGP hijacking attack; it sounds way easier than setting up a collector at every ISP. (You'd still need local collectors to not add too much latency, but a single (/very/ well connected) collector could cover a reasonable region)

[1]http://www.defcon.org/images/defcon-16/dc16-presentations/de...

[2]Cisco charges an arm and a leg for firmware upgrades... they give you some of the really old stuff? but usually the choice is used $BIGNAME hardware without firmware updates, or you roll-your own quagga. (at the 10G/sec traffic level my upstreams can push, quagga/vyatta work just fine... that's what I use.)

Metadata cannot be protected as well as the actual content can. One of the keys of good security is to ask what has to be compromised for your data to be compromised, though. If you have SSL-protected connections, BCG hijacking alone isn't going to reveal your communications but BCG hijacking along with a fake certificate issued by a trusted CA under court order or merely voluntarily) would allow a MITM attack.

The thing is, if you have your own CA, and expect certs from both sides from the same CA, then it is very hard for an MITM attack of this sort to be orchestrated because you can say, "Something isn't right here." So that leaves attacks against the cyphers involved or against the endpoints.

One service we offer is an ability to use an SSL cert issued by the customer, as well as appropriate VPN options to connect to the system at all. Between these, in general I would expect that MITM approaches can be protected against in high security configurations. But that still leaves cyphers and endpoints.

So the first thing we need is a better PKI which can more robustly handle fraudulent certificates. This is something I have written about a bit. (see my blog, http://ledgersmbdev.blogspot.com for more.) But we also need a lot more.

BTW, we build everything on the basis of compartmentalized security with the idea that compromising customer data will require working through quite a bit of depth, particularly in relatively high security configurations. It wouldn't protect against a court order, but it should protect against a lot of other things.

Could the NSA hack us? I am sure they could. Could we make it difficult enough that they would be much better going through legal channels (maybe making deals with local law enforcement or the like)? That's what I am shooting for. It is probably the best one really can shoot for.

>Could we make it difficult enough that they would be much better going through legal channels (maybe making deals with local law enforcement or the like)? That's what I am shooting for. It is probably the best one really can shoot for.

Yeah; my point was just that getting to that point (where it's easier for them to go through legal channels) is harder than it looks. It's certainly not the default state.

> Yeah; my point was just that getting to that point (where it's easier for them to go through legal channels) is harder than it looks. It's certainly not the default state.

As we went through our initial design, and started talking to others, it became quite clear that the being industry standard when it came to security is not something that either myself nor my business partner were comfortable with. We opted to start looking at everything very carefully and review eachothers' works regarding security, suggesting improvement, etc.

It's one of the reasons we decided to go hosted cloud first and only later multi-tenant.

>It's one of the reasons we decided to go hosted cloud first and only later multi-tenant.

So by 'hosted cloud' you mean 'every user gets their own VM?' I mean, you could mean that you use on-demand dedicated servers, but most people mean virtual instances when they say "cloud" (I hate that word "cloud" - it's so vague)

(personally, i still think of multiple VMs on one physical box as multi-tenant. But managing a VPS per user? thousands of times easier than managing a user-account per user and just having a bunch of users on the same box. In my opinion, more secure, too.)

How are you managing images? I mean, that's the thing you've gotta watch for, a backdoor in the install image.

One thing I've noticed about my customers is that they almost all prefer to use my image than to do a net-install. (I give my xen users a paravirtualized boot loader, so they can load the distro install kernel and go from there.) the interesting thing is that my dedicated customers are far more likely to do their own install (I provide only... a very rudamentary PXE menu.)

Or, maybe that's just my perception because I only notice what OS they are running when they ask for help... whereas on the dedicated servers, I've recently had to move a bunch of them, which required me to look at consoles. So I guess there could be a bunch of arch users or something like that who just don't ask for help.

It does seem like having your own physical hardware would make... a big difference, security-wise.

We can do either but our default is vm's, just because for smaller businesses that is a lot more practical. Customers typically do not have root access to their VM's unless they supply their own keys/x509 certs so we can take ours off. If we are managing the box we have, for example, stored root passwords (rarely needed and only two people have access) encrypted in PostgreSQL (which means we do not log when we are not debugging and we do not allow history to be stored since manual keys must be entered when retrieving this info).

> How are you managing images? I mean, that's the thing you've gotta watch for, a backdoor in the install image.

It's not the only thing you have to watch out for. If someone can compromise the host they should be able to compromise all vm's given a little time. We do have some automated ways of checking for changes though. In general the physical hosts are much less exposed but cannot guarantee that more generally. We are always discussing ways to tighten security (I am considering setting up a rediculously tight selinux policy on the physical hosts).

> It does seem like having your own physical hardware would make... a big difference, security-wise.

The big difference is actually where the hardware is located. The big difference is really having your own physical hardware on your own premises on your own intranet vs using someone else's physical hardware in their datacenter, with their intranet. In general though if you have someone else's hardware on your intranet you can better control it than if you have your hardware somewhere else.

Again, I don't understand why you think that it's harder for the NSA to hack / bribe / trick their way into data than it is to have to obtain court orders and convince everyone to work with them.

The cannot get a US court to compel you to hand it over.

How likely do you think it is that any of the UK agencies that have powers to request interception under RIPA will refuse a "please scratch your back, and we'll scratch your back later" request from the NSA if the NSA actually cares about your data enough to try to get someone to compel you to hand it over?

And RIPA does provide basis for compelling you to hand over keys or face prison.

Being in the UK may protect us against NSA just taking whatever they feel like whenever they feel like it for no reason at all, but I very much doubt it does much good for anyone that actually ends up in the NSA's crosshairs.

Before anyone else gets this idea, I'd encourage you to look at your organizations' resident country laws before thinking & acting on this.

Companies based in the UK, for example, can not make the claim found above ( http://m.washingtonpost.com/investigations/us-intelligence-m...).

I'm not a lawyer, but you could lose all credibility if you act on that and get it wrong.

"Suppose you do business with an American company that has servers in Australia (for the record we are registered in the UK, not the US), and they get a FISA warrant? Of course they will send the info over"

There's a way out. Those server offshore must be handled by subsidiary. Then the parent company in US does not have the data and they can not also command subsidiary to handle it over.

The big US companies have made it clear that they will give out data held by subsidiaries, even if this is illegal eg under European law.

That means the best option is not to use wholely owned subsidiaries and instead have a partnership with the parent owning a large plurality but non-controlling interest (say 10 partners from various countries, with the parent owning 49.9% of the subsidiary). You can set the agenda, more or less run things how you want, but anything you try to do as shareholder can be vetoed by the other 9 acting in unison.

Is this true? genuine question - have these companies stated this or done so in the past?

Yes, this has been an issue for a few years now eg see http://www.zdnet.com/blog/igeneration/eu-demands-answers-ove...