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.