A few weeks ago I (‘we’) silently added SSL to rwt-to (http://rwt.to). The reason is quite simple, “it ain’t safe no more”. When I went shopping for a bare-metal server I looked at performance, price and regulations, and didn’t take much into considering latency or where most users of my current/future projects are located. Even with that said, the US seemed a good option, as I got a very ‘powerful’ server for the same price I’d pay locally.
Now the biggest problem with the server’s location is that it’s in the US, in fact, even all the VPServers that I use are in the US. This was always not a problem in the past, but due to the data hose of NSA revelations that keep pouring in, I get concerned by the day.
NSA and Google
I use Google services, the NSA have seen all my data one way or the other, and in practicality I don’t have a problem with that. Google gives me services for free, in exchange for my information so they can sell me ads. I’m happy with the model, it works out well for me. In principle, however, I am very concerned with the fact that government agenc[ies] have warrantless access to my data. Not just my data as a consumer, but also data as a service provider.
The recent revelation that the NSA had access to Google’s dark fiber, which was unencrypted petabytes of our information, is one of those things that have tipped the scales for me. I’ve never had to think about it, but now that I have thought about it; I didn’t expect Google to encrypt data between their data centers, as long as they theoretically were the only ones with access to their network. Simply, this is the same as operating on a VPN. The VPN security layer on its own should suffice as security that you’re on your own network. This, coupled with the presumption that Google wouldn’t share a leased connection, is the basis for my expectation.
I didn’t expect Google to encrypt data between their data centers
Realistically though, encrypting internal data is likely to be a costly exercise, both computationally and from an efficiency perspective. As +Mike Hearn from Google recently put it (https://plus.google.com/+MikeHearn/posts/LW1DXJ2BK8k):
“… the entire thing requires a large and complex key distribution and management infrastructure (fortunately already present). Also lots of different protocols flow over our wires, each one of which has to be handled. …”
Remember that, unless the model’s changed, Google uses distributed commodity servers, which might not always be the latest and greatest Intel chips with SSX 4.3 or whatever instruction sets make our blood rush with excitement these days. So end-to-end encryption on its own would really be costly.
My SSL Efforts
With the above said, now knowing that the NSA has had access to organisation[s]‘ dark fiber, I am overly concerned for the little server that I own, and the VPServers too. As mentioned, a few weeks back I added SSL on the public-facing ports on my little server. The main logic from that was because that in a few months I’ll be hosting probably a number of services that are consumed by the public.
I (‘we’) find it reasonable for anyone using whatever service I’ll have running at the time to have an expectation of security about inputting or storing their data on my (‘our’) services.
I’m about to go on a process of either killing the VPServers that I own or moving them to a small dedicated server, retiring some random experiments of mine, and perhaps also killing my blog and mail server. That’s something to think of over a glass of juice. Securing all of that with SSL (where necessary) will be expensive, unless I sign all the keys myself where possible.
The main thing that remains a concern for me is that as and when my services expand, and the need for additional servers/shards arises, I’ll have the same problem (albeit at a micro level) as the one that Google faced, being that; Do I (‘we’) need to protect internal traffic between downstream and upstream servers?
To give some context, I run a Node.js app on a single-instance cluster. Now, Node.js isn’t the most efficient of servers out there when it comes to handling TLS/SSL encryption and decryption (I believe Ben Noordhuis has made this admission himself). So as most people do, I use nginX to handle the crypting. The problem with this is that once a request is validated by nginX, internal traffic is decrypted (i.e. the Node.js cluster doesn’t use SSL) it flows around unencrypted. So, with more shards potentially located in other DCs (say, around the world, or maybe locally in SA), it means that the traffic that actually matters (the exchange between the database[s] and Node.js) is in full view of hackers and certain authorities.
Well, Nobody Cares
The reality is that for now, nobody cares. I don’t expect myself to build a sensitive system which will require important user information. However, as someone who has had an interest in computer security, and is aspiring to study in the field, it matters that I learn how to deal with such architectural problems at an early stage. This means that over time I’ll learn how distribution of encryption keys works, and other interesting concepts.
What Mike Hearn posted was quite insightful for a curious mind like mine, and is surely encouragement for me to continue with SSL for TCP protection. Of course the problem is that getting keys signed by a public authority can be expensive, and that isn’t a guarantee of security if the NSA wants in (eg. Lavabit’s certificate was revoked over a month ago).
I’ve had some time to look at PGP and things like PPTP/IPSec, and without promoting paranoia, I am going to be working more towards keeping my data safe, through the wire and beyond. I’ve learnt that it’s better to be safe than sorry when it comes to data security.