AOH :: ISNQ4801.HTM

Encrypted E-Mail Company Hushmail Spills to Feds




Encrypted E-Mail Company Hushmail Spills to Feds
Encrypted E-Mail Company Hushmail Spills to Feds



http://blog.wired.com/27bstroke6/2007/11/encrypted-e-mai.html 

By Ryan Singel 
Wired.com
November 07, 2007

Hushmail, a longtime provider of encrypted web-based email, markets 
itself by saying that "not even a Hushmail employee with access to our 
servers can read your encrypted e-mail, since each message is uniquely 
encoded before it leaves your computer."

But it turns out that statement seems not to apply to individuals 
targeted by government agencies that are able to convince a Canadian 
court to serve a court order on the company.

A September court document (.pdf) from a federal prosecution of alleged 
steroid dealers reveals the Canadian company turned over 12 CDs worth of 
e-mails from three Hushmail accounts, following a court order obtained 
through a mutual assistance treaty between the U.S. and Canada. The 
charging document alleges that many Chinese wholesale steroid chemical 
providers, underground laboratories and steroid retailers do business 
over Hushmail.

The court revelation demonstrates a privacy risk in a relatively-new, 
simple webmail offering by Hushmail, which the company acknowledges is 
less secure than its signature product.

A subsequent and refreshingly frank e-mail interview with Hushmail's CTO 
seems to indicate that government agencies can also order their way into 
individual accounts on Hushmail's ultra-secure web-based e-mail service, 
which relies on a browser-based Java encryption engine.

Since its debut in 1999, Hushmail has dominated a unique market niche 
for highly-secure webmail with its innovative, client-side encryption 
engine.

Hushmail uses industry-standard cryptographic and encryption protocols 
(OpenPGP and AES 256)  to scramble the contents of messages stored on 
their servers. They also host the public key needed for other people 
using encrypted email services to send secure messages to a Hushmail 
account.

The first time a Hushmail user logs on, his browser downloads a Java 
applet that takes care of the decryption and encryption of messages on 
his computer, after the user types in the right passphrase. So messages 
reach Hushmail's server already encrypted.  The Java code also decrypts 
the message on the recipient's computer, so an unencrypted copy never 
crosses the internet or hits Hushmails servers.

In this scenario, if a law enforcement agency demands all the e-mails 
sent to or from an account, Hushmail can only turn over the scrambled 
messages since it has no way of reversing the encryption.

However, installing Java and loading and running the Java applet can be 
annoying. So in 2006, Hushmail began offering a service more akin to 
traditional web mail. Users connect to the service via a SSL (https://) 
connection and Hushmail runs the Encryption Engine on their side. Users 
then tell the server-side engine what the right passphrase is and all 
the messages in the account can then be read as they would in any other 
web-based email account.

The rub of that option is that Hushmail has -- even if only for a brief 
moment -- a copy of your passphrase. As they disclose in the technical 
comparison of the two options, this means that an attacker with access 
to Hushmail's servers can get at the passphrase and thus all of the 
messages.

In the case of the alleged steroid dealer, the feds seemed to compel 
Hushmail to exploit this hole, store the suspects' secret passphrase or 
decryption key, decrypt their messages and hand them over.

Hushmail CTO Brian Smith declined to talk about any specific law 
enforcement requests, but described the general vulnerability to THREAT 
LEVEL in an e-mail interview (You can read the entire e-mail thread 
here):

    The key point, though, is that in the non-Java configuration, 
    private key and passphrase operations are performed on the server- 
    side.

    This requires that users place a higher level of trust in our 
    servers as a trade off for the better usability they get from not 
    having to install Java and load an applet.

    This might clarify things a bit when you are considering what 
    actions we might be required to take under a court order. Again, I 
    stress that our requirement in complying with a court order is that 
    we not take actions that would affect users other than those 
    specifically named in the order.

Hushmail's marketing copy largely glosses over this vulnerability, 
reassuring users that the non-Java option is secure.

    Turning on Java provides an additional layer of security, but is not 
    necessary for secure communication using this system[...]

    Java allows you to keep more of the sensitive operations on your 
    local machine, adding an extra level of protection. However, as all 
    communication with the webserver is encrypted, and sensitive data is 
    always encrypted when stored on disk, the non-Java option also 
    provides a very high level of security.

But can the feds force Hushmail to modify the Java applet sent to a 
particular user, which could then capture and sends the user's 
passphrase to Hushmail, then to the government?

Hushmail's own threat matrix includes this possibility, saying that if 
an attacker got into Hushmail's servers, they could compromise an 
account -- but that "evidence of the attack" (presumably the rogue Java 
applet) could be found on the user's computer.

Hushmail's Smith:

    [T]he difference being that in Java mode, what the attacker does is 
    potentially detectable by the user (via view source in the browser).

"View source" would not be enough to detect a bugged Java applet, but a 
user could to examine the applet's runtime code and the source code for 
the Java applet is publicly available for review. But that doesn't mean 
a user could easily verify that the applet served up by Hushmail was 
compiled from the public source code.

Smith concurs and hints that Hushmail's Java architecture doesn't 
technically prohibit the company from being able to turn over 
unscrambled emails to cops with court orders.

    You are right about the fact that view source is not going to reveal 
    anything about the compiled Java code. However, it does reveal the 
    HTML in which the applet is embedded, and whether the applet is 
    actually being used at all. Anyway, I meant that just as an example. 
    The general point is that it is potentially detectable by the 
    end-user, even though it is not practical to perform this operation 
    every time. This means that in Java mode the level of trust the user 
    must place in us is somewhat reduced, although not eliminated.

    The extra security given by the Java applet is not particularly 
    relevant, in the practical sense, if an individual account is 
    targeted. (emphasis added) [...]

Hushmail won't protect law violators being chased by patient law 
enforcement officials, according to Smith.

    [Hushmail] is useful for avoiding general Carnivore-type government 
    surveillance, and protecting your data from hackers, but definitely 
    not suitable for protecting your data if you are engaging in illegal 
    activity that could result in a Canadian court order.

    That's also backed up by the fact that all Hushmail users agree to 
    our terms of service, which state that Hushmail is not to be used 
    for illegal activity. However, when using Hushmail, users can be 
    assured that no access to data, including server logs, etc., will be 
    granted without a specific court order.

Smith also says that it only accepts court orders issued by the British 
Columbia Supreme Court and that non-Canadian cops have to make a formal 
request to the Canadian government whose Justice Department then 
applies, with sworn affidavits, for a court order.

    We receive many requests for information from law enforcement 
    authorities, including subpoenas, but on being made aware of the 
    requirements, a large percentage of them do not proceed.

    To date, we have not challenged a court order in court, as we have 
    made it clear that the court orders that we would accept must follow 
    our guidelines of requiring only actions that can be limited to the 
    specific user accounts named in the court order. That is to say, any 
    sort of requirement for broad data collection would not be 
    acceptable.

I was first tipped to this story via the Cryptography Mailing List, and 
Kevin, who had been talking with Hushmail about similar matters 
involving another case, followed up with Smith. We both agree Hushmail 
deserves credit for its frank and open replies (.pdf). Such candor is 
hard to come by these days, especially since most ISPs won't even tell 
you how long they hold onto your IP address or if they sell your 
web-surfing habits to the highest bidders.


__________________________________________________________________      
CSI 2007 is the only conference that delivers a business-focused
overview of enterprise security. It will convene 1,500+ delegates,
80 exhibitors and features 100+ sessions/seminars providing a
roadmap for integrating policies and procedures with new tools
and techniques.  Register now for savings on conference fees   
and/or free exhibits admission. - www.csiannual.com 

Site design & layout copyright © 1986-2014 CodeGods