Lavabit Security Misconfiguration

Written 3 months ago by Mike Cardwell

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 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 143
Connected to
Escape character is '^]'.
* OK [CAPABILITY IMAP4 IMAP4rev1 STARTTLS LITERAL+ ID] Magma IMAP server v6.4.1014 is ready.
1 LOGIN ******* ****************
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 587
Connected to
Escape character is '^]'.
220 ESMTP Magma
EHLO wibble
250-SIZE 1073741824
334 VXNlcm5hbWU6
334 UGFzc3dvcmQ6

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 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: 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.

Looking to hire somebody like me? I'm open to offers of full time employment and small contract jobs. Check out my hiring page. You can follow this Blog using RSS or . To read more, visit my blog index.

Feeling generous?BitcoinMoneroZcashPaypal