# Lavabit Security Misconfiguration Yesterday, Ladar Levison [tweeted](https://twitter.com/kingladar/status/882464301096849408):
"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](https://lavabit.com/) account earlier this year to mess around with the various [Dark Mail](https://darkmail.info/) 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: ```text 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." ```text 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.