Opportunistic SSL/TLS encryption on outgoing emails

Early last year, we implemented opportunistic encryption of incoming emails. We’ve now done the same thing for outgoing emails. This means that for email sent via FastMail (either the web interface or SMTP), if the receiving server advertises STARTTLS support in response to an EHLO command, we will try and negotiate a secure connection and send the email over a secure connection. However if the negotiation fails for any reason, we’ll fallback to a standard connection.

Some extra notes on this:

  • This doesn’t change what happens when sending via SMTP from your email client/software (eg. Outlook, Apple Mail, Thunderbird, etc) to the FastMail servers. Whether that connection is encrypted is controlled by your email client/software and what you configured when you set it up
  • We can’t force a remote server to use encryption, it’s only if the remote server advertises support for encryption that we try and setup a secure channel
  • This is not full end-to-end encryption of the email. The email is only encrypted during transit from our server to the other server, once it’s at their side, it’s stored in whatever form the other side stores emails. For full end-to-end encryption, you need something like PGP
  • The only way to tell if an email has gone over an encrypted connection or not is to look at the headers of the email on the received side. In other words, as a sender, it’s unfortunately not easy to tell, only the receiver can easily tell

Since this feature is only enabled if the other side advertises support for it, it shouldn’t affect sending to servers that don’t support STARTTLS, and thus shouldn’t affect the deliverability of email in any way.

Posted in Technical. Comments Off

Yubikey authentication trial on beta server

We’re currently running a trial of Yubikey authentication on our beta server.

To enable this, just login and go to Options -> Alternate Logins, and create a new Yubikey login set. For the Base Password, just touch your Yubikey button to generate a new one-time code to allow us to associate your particular Yubikey with your account. Currently these logins only work on the beta server web interface.

The Yubikey is a small USB authentication device that you can use to login to your FastMail account (beta web interface only at the moment) instead of your regular password. The Yubikey doesn’t need any client software. You just plug it into a USB port and it acts like a USB keyboard that most OS’s automatically support. It has one button on it, that when you press it, it generates a new one-time 44 character password.

The main advantage of a Yubikey login over a regular static password login is that to login, you must have the physical Yubikey token plugged into your machine, and you must press the button on it to generate a new one-time password. You can’t re-enter an already used one-time password, or copy and paste an existing one-time password. This prevents replay attacks if someone captures any of your logins (eg keylogger, tcp dump, malware root kit, etc).

Here’s the way it works:

  1. Each device has a unique id, that’s the first 12 chars
  2. Each device has an internal "shared secret" AES encryption key
  3. Each time you press the button, it generates a new one-time value that encrypted with that key, that’s the other 32 characters

The way it generates the one-time value is like this:

  1. It takes some internal values and joins them together
  2. It then encrypts that data using a symmetric cipher with the shared AES key that’s stored in the Yubikey, and also on the Yubico server so the server can decrypt it

The internal values that are joined and encrypted include:

  1. A private internal value
  2. A number of counter fields (each time you plug the key into a machine, or generate a new key, internal non-volatile counters are incremented)
  3. Timer field (an internal 8hz counter value)
  4. A random number
  5. A CRC checksum

So at the receiving side, you get the 44 char value. The first 12 chars normally let you work out who’s key it is (we still need to ask for your login name, because we you allow you to associate your Yubikey with multiple different accounts if you want). With the other 32 bytes, they are decrypted using the shared AES key, and then all the values are checked to make sure they are valid (eg counters are all higher than their previous values, checksum is valid, etc). There’s more details at the Yubico website (PDF manual).

So with this approach, you can validate a login, and be sure that if someone captures your keystrokes/one-time password value, it’s useless, because it can’t be used again.

We don’t actually store the AES key or do the decryption. That’s done with the Yubico web API service. So the shared key is stored in the Yubikey itself, and on the Yubico web service API server.

You can order Yubikeys from the Yubico website order page.

If you want to ask more questions, there’s a forum thread about this you can check out: Yubikey forum thread.

Update 22 Jan 2010: We’ve now added a two factor Yubikey authentication option. With this method, you need to enter both a password, and touch your Yubikey button to generate a one-time password. The advantage of this approach is that if you login on a machine with a keylogger/malware/root kit that captures your username + password + yubikey one time password, it doesn’t matter, because the yubikey one time password can’t be reused. If someone steals your physical Yubikey, then it doesn’t matter, because they don’t know your fixed static password. This is why it’s called “two factor” authentication. (Of course it doesn’t protect against the case of both the static password and physical key being stolen, but that’s a lot less likely)

Off topic: Just as an FYI, this isn’t related to the FastMail implementation, but it is neat. If you’re a business that wants to use Yubikeys for authenticating people within your own organisation, you can run your own Yubikey validation server rather than using the Yubico Web API one. In that case what you’d do is before handing the Yubikeys to people in your organisation, you’d reprogram them with you’re own new random AES code. You’d also store that AES code on your own validation server. This means staff could then use their Yubikey to validate against your organisations validation server. Of course it wouldn’t work for other externally run services that validate against the Yubico web API anymore, because the shared AES key is no longer valid in that case.

Posted in News, Technical. Comments Off

New website throttling feature available

We recently had a users website come under a DDOS attack. The site itself was reasonably small (only a few HTML files and downloadable files), but because the requests were coming in continuously at several per-second from many different IP addresses, it was quickly eating into the users available bandwidth.

To help with this, we’ve added a new throttling feature to websites, that allows people to limit access rates to their websites from individual IPs. On the Files –> Websites screen when you setup or edit a website, you can change the IP Throttling to one of the following values:

  • 10000/200M
  • 2000/50M
  • 500/20M
  • 100/5M
  • 20/2M

The 2 values are “number of requests” and “bandwidth of requests” per-IP per-10 minutes respectively. So setting the 10000/200M value will limit each accessing IP to a website to no more than 10,000 requests and 200M of data per 10 minutes. If a particular IP goes over one of the limits, we’ll return an error page to requests from that IP for the given website for the next 10 minutes.

In general, people shouldn’t need to change this value from the default 10000/200M, but if their site does come under some form of attack, this will provide a way to help limit the damage.

Posted in Technical. Comments Off

Roboform can cause extreme slowness in Firefox

If you use Firefox and Roboform together, and find the webmail interface slow, the problem may be Roboform.

The main symptom of the problem is that page loads are very slow. When clicking on a link or button, the Firefox tab will change to “Loading” with the spinning loading icon, and the page will appear to load after a short moment, but then the browser will completely “freeze” (no spinning loading icon, no scrolling or interaction with any element on the page possible, CPU pegged to 100%) for 1-10 seconds before finally becoming interactive again. The amount of time the freeze occurs for is often proportional to the size of the page, so displaying 500 rows of a mailbox will take many seconds, even on a fast machine.

After some testing and disabling of Firefox extensions one by one, I tracked the problem down to Roboform (the problem occurs even with the as current latest version 6.9.98).

So if you are also experiencing this problem, as a first step, you can use Tools –> Add-ons to disable the Roboform extension inside Firefox. After disabling the extension and then restarting Firefox, you should find the web interface a lot faster.

As a long term solution, I recommend using the password manager built into Firefox instead, and completely removing Roboform. Unfortunately I don’t know an easy way of transferring passwords from Roboform to Firefox, so I’ve had to do it manually one by one. Within Firefox, you can also use the free extension SyncPlaces to store a copy of your Firefox passwords and bookmarks in your FastMail file storage area via WebDAV. You can also use SyncPlaces on multiple machines to keep your bookmarks and passwords in sync across those machines.

Posted in News. Comments Off

Truedomain anti-phishing and email authentication

One of the big problems with email is that the email standards were developed during the earlier days of the internet when all the machines and people connected to the internet trusted each other. That means that emails are very easy to forge and spoof, because there was no method of trust or authentication built into the email standards.

Over time systems have been added which try and add these extra layers of trust. Unfortunately each of these systems introduces it’s own problems.

RBLs provide a list of machines that are untrusted, or have shown malicious behaviour, or have sent spam (each RBL has different listing criteria). Using these you can block emails from particular machines, or give them a higher spam score. Unfortunately RBLs can cause false positives, and cause legitimate emails to be blocked.

SPF is a way to trust the domain in the “SMTP envelope from” address. Unfortunately most people don’t actually see the envelope from address, so this isn’t actually very useful. In most cases, the main thing this will help stop is backscatter because email with forged from addresses won’t be accepted and/or bounced. Unfortunately SPF breaks forwarding of emails, something lots of people want to do. There’s an additional standard SRS that attempts to fix this, but it’s annoying to implement, given the only small benefit that SPF provides.

DKIM is a way to sign emails using a public/private key system based on a particular domain. Basically if you own xyz.com, then you can sign an email with DKIM, and the receiver can verify that:

  1. The email was signed by the domain xyz.com
  2. The email content and headers haven’t been altered in any way from when xyz.com sent it

In theory this is very useful, because it provides a way to identify trusted emails. The problem is that just verifying that an email is signed by xyz.com isn’t really enough. The big queston is “Do you trust email from xyz.com?”.

If the domain is yahoo.com, then the answer is generally “no”. Anyone can signup a free account at yahoo.com, and then send you emails, that will be DKIM signed by yahoo.com. So knowing an email is signed by yahoo.com doesn’t tell you much useful about the trust of that email.

On the other hand, if the domain is facebook.com, then the answer is generally “yes”. At the moment, the only email being sent by facebook.com is official notification emails from Facebook. Similarly sites like paypal.com, linkedin.com, ebay.com, etc are domains you do want to trust, as any emails they do send are definitely from their corresponding company only, and not from just any person.

The problem is that there’s lots of email providers out there, and lots of domain owners out there. To make DKIM useful as a way to trust emails, each email provider has to work out which domains they want to list as trusted and a way to display those emails. With lots of different email providers and potential companies to trust, that creates a huge number of required relationships.

td1

What’s needed is someone that sits in the middle to act as a mediator between companies that want emails they send to be trusted, and the email providers, so they don’t have to build and maintain lists of domains to trust individually themselves.

That’s where Truedomain comes in. Their aim is to work with senders to build a list of trusted sending domains, and easily allow receivers to check the DKIM signatures on received emails to see if they’re from a trusted domain. When an email is from a trusted domain, they make it easy to display trust details for that domain, including the sending company, and a logo from that company. This is particularly useful as a way to protect users from phishing emails.

td2

Emails that are truedomain protected are now displayed in the FastMail web interface with a light green background on the mailbox screen, and the logo from the company next to the from name/address. Additionally on the message read screen, a green box under the subject line also shows the company logo and details of what company sent the email.

Mailbox screen display

td3

Message read screen display

td4

For email users, you can think of truedomain as EV SSL for email. In the same way that SSL certificate providers vet companies, and then provide them a certificate that displays a secure connection in your browser with the company name, truedomain vets companies, and then provides a way for their emails to display securely in your email service with the company logo and name.

With the large amount of phishing emails, and the huge cost phishing emails cause, we believe that truedomain are providing a useful service that will continue to grow as more sending companies and email receivers get on board.

Posted in News. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,461 other followers