Grepular

Yesterday, Ladar Levison tweeted:

“My birthday gift? A new website. Enjoy… sign up reminders will go out later this week.”

This reminded me that I pre-ordered a Lavabit.com account earlier this year to mess around with the various Dark Mail related protocols on a live service.

So I signed up this morning with the promo code I had purchased.

I haven’t got much to report yet, except there are some mildly embarrassing security oversights on the IMAP and SMTP services. With GMail, Outlook 365, Yahoo, and every well run mail service out there, if you forget to check the little “TLS” box in your email client, your client figures out there is a problem before sending the credentials over the unencrypted connection and stops you. With Lavabit, your email client will happily send your credentials over an unencrypted connection. Not only that, but the Lavabit service will happily allow you to successfully authenticate and retrieve/send email over this unencrypted connection:

mike@blob:~$ telnet imap.lavabit.com 143
Trying 64.182.234.110...
Connected to imap.lavabit.com.
Escape character is '^]'.
* OK [CAPABILITY IMAP4 IMAP4rev1 STARTTLS LITERAL+ ID] lavabit.com Magma IMAP server v6.4.1014 is ready.
1 LOGIN *******@lavabit.com ****************
1 OK Password accepted.

What should have happened above is that “LOGINDISABLED” was included in the capability list so my client would know not to even attempt to login until after negotiating STARTTLS. Secondly, if I was using a client which ignored “LOGINDISABLED”, I should have received an error message telling me that my credentials were now compromised. Not a “1 OK Password accepted.”

mike@blob:~$ telnet smtp.lavabit.com 587
Trying 64.182.234.110...
Connected to smtp.lavabit.com.
Escape character is '^]'.
220 lavabit.com ESMTP Magma
EHLO wibble
250-lavabit.com
250-8BITMIME
250-STARTTLS
250-PIPELINING
250-SIZE 1073741824
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 EHLO COMPLETE
AUTH LOGIN
334 VXNlcm5hbWU6
WW91IHNuZWFreSBidWdnZXI=
334 UGFzc3dvcmQ6
WWUgaGF2ZSBsaXR0bGUgZmFpdGg=
235 AUTH PLAIN SUCCESSFUL - AUTHENTICATED

What should have happened here was the ESMTP extensions “AUTH LOGIN” and “AUTH PLAIN” should have not been included in the response to my EHLO command. Then my client would know that authentication wasn’t available. Only after negotiating STARTTLS should those options become available. And like with IMAP, my credentials should have been rejected even if they were correct.

Of course, if you’ve misconfigured your client and there is an active attacker involved when you make your first connection, they could add the SMTP AUTH extensions or remove the LOGINDISABLED IMAP capability.

But what I’m talking about here is Lavabit.com. You’ve got to assume all traffic is being passively captured. And if it’s not today, it will be soon. If Lavabit wants to claim to be a secure service, it should at least match the security features that GMail, Office 365 and Yahoo Mail provide.

I assumed that this was an oversight, but I’m not certain: https://lavabit.com/settings.html states “encryption supported” for IMAP and SMTP, rather than “encryption mandated”, and also says “We recommend using port 587 and enabling STARTTLS for outbound SMTP access.” STARTTLS should not be “recommended”, it should be “required”

I reported this issue only a few hours ago, but I don’t consider this category of problem to require a delayed disclosure.