I've recently realized that my digital life is only as secure as my Google account. Every account I have can be reset through Gmail.
And many websites now implement two-factor authentication by sending me a text message or calling on the phone, which goes
through Google Voice.
I love Google Voice. I love being able to make calls from Gmail and send texts from a browser. I love that my voice mails get
emailed to me. And I love that I can switch cell phone carriers without having to port my number. I just get a new number
and wire it up in Google Voice.
But since I leave my Google account logged in at home and at work (though I'm pretty good about locking the screen when I leave), I've
started to worry about my attack surface. Is there a more secure way to get those 2FA texts without going through Google?
Two Numbers
Whenever I need a 2FA phone number, I could give out my real cell phone number (not my Google Voice number). But I really try to
avoid using that number at all, because I don't want to maintain a list of places I need to change my phone number when I change
carriers.
Alternatives
If I found a good alternative to Google Voice, I could set up a separate SMS account just for receiving 2FA messages.
They seem to be out there, but they are all expensive services for businesses. I care about my security, but I can't pay $30 a month for it!
Roll My Own
A few years ago, that would've been the end of the story. But nowadays we have Twilio, a company which offers telephone and SMS
services with a nice API! Phone numbers are only $1 per month and text messages are less than a penny each. That's a cost I can live with.
Twilio is an awesome service that I'd like to do more with in the future. I'm beginning to roll my own (simple) SMS service.
The minimum viable functionality to be useful is to capture incoming messages from Twilio and store them (encrypted?)
in a database, along with an interface to retrieve them. To receive these messages, I give Twilio an endpoint URL and they send them
along with a post message. This is quite simple and I'm well along the way to completing it.
Obviously, if I want this to be secure, I need to use SSL. And fortunately, StartSSL gives out SSL certificates free for personal projects.
Done, right?
Paranoia Strikes Deep
Well, the internet security community has realized that there are a few weaknesses in the SSL trust system.
In particular, any certificate authority that your browser trusts can create a certificate for any site, so if a CA is malicious, or gets
deceived, then someone can create a fake certificate for your domain and intercept your traffic. Some trusted CAs are quite mysterious.
Others are foreign governments which we might not want to trust. CAs have been compromised in the past, and it's rumored that the NSA
is on good terms with some of them.
Granted, this is a targeted attack, but if you're using SSL you should at least be aware of the shortcomings. So the true attack surface
with a Twilio/SSL setup is:
- SMS Sender
- SMS Infrastructure
- Twilio
- My server that receives the messages
- Domain registry system
- Every SSL CA trusted by Twilio
The others are mostly unavoidable, but the last one is kind of disconcerting. Does Twilio publish a list of which CAs they trust?
DNSSEC and DANE
The internet security community does have a solution to these weaknesses. It's called DNSSEC and DANE. You secure your DNS records
with a cryptographic key, which has to be signed by the entity that runs your TLD. You also add a DNS entry which says that SSL
connections to a certain host on a certain port must be secured by a certain SSL certificate.
I'm thinking of using the official Swiss domain registrar, SWIT.CH, who also administers DNSSEC for the CH top-level domain. With
this setup, the attack surface has been shrunk to:
- SMS Sender
- SMS Infrastructure
- Twilio
- My server
- SWIT.CH (Domain registrar and TLD administrator)
The question is, does Twilio respect DNSSEC and DANE?
An Optimal Solution
Frankly, I would prefer not to use the DNS system at all. I would rather base the Twilio endpoint off an IP address,
except that prevents the use of SSL. SSL is based on the DNS system.
Unless you allow self-signed certificates, that is.
If I could use an IP address with a self-signed SSL certificate, and if I could configure that certificate in Twilio so it would
reject any other certificates, then the attack surface would be down to:
- SMS Sender
- SMS Infrastructure
- Twilio
- My server
At this point, Twilio doesn't support self-signed certificates. But I wish they would. Self-signed certificates can
be the most secure solution when you have a secure way to establish the validity of a certificate.