Feeds

back to article Another 'NSA-proof' webmail biz popped by JavaScript injection bug

German startup Tutanota has admitted its webmail service was vulnerable to a cross-site scripting bug despite boasting it offered an "NSA-proof email service." The flaw, which would have allowed attackers to inject malicious JavaScript into victims' browsers, was uncovered and reported last night by German security researcher …

Bronze badge
Stop

Sigh...

This all would be largely unnecessary if Joe Sixpack (and Joe PHB, I suppose) hadn't dismissed PGP as "too complicated". PGP which, as far as I'm aware, Snowden still considers "good enough".

It's easy enough to carry a PGP key on your keyfob, not to mention a portable MUA to use it with if you like. And if you don't trust the host computer enough for that, then you'd be no better off with webmail.

Is it too late for everybody to get behind that?

10
1
Anonymous Coward

Re: Sigh...

PGP, or, for that matter, GPG's interface sucks more than even Microsoft could dream up, it is a usability nightmare. In the hands of someone who is technically literate it's fine, but it is miles from end user compatible.

In addition, as soon as you start talking about key management to the average Joe you've lost them before you have even started.

10
0
Silver badge

Re: Sigh...

PGP, or, for that matter, GPG's interface sucks more than even Microsoft could dream up, it is a usability nightmare. In the hands of someone who is technically literate it's fine, but it is miles from end user compatible.

In general, writing a new UI for an existing relatively-well-proven encryption system is simpler than writing a new encryption system. The question is, why has this not happened w/r/t PGP/GPG?

In addition, as soon as you start talking about key management to the average Joe you've lost them before you have even started.

The average Joe doesn't have a house or flat key, or a car or bike key, or a locker key, or keys for their workplace? The principles of management for digital keys are no different from those for physical keys. If the digital system doesn't express those principles in a reasonable analogue to the physical, the solution is the same: fix the UI.

2
0
Silver badge

Re: Sigh...

For the average Joe, when you say a key, they expect a PHYSICAL key, like a dedicated fob (although those can be STOLEN).

The problem is that to make the system as intuitive as possible for as many people as possible, you can't make them come to you. You'll have to go to them, which means integrating with third-party e-mail clients. Now, Thunderbird has an add-on mechanism, but what about Outlook?

Then there's the matter of being rooted outside the e-mail program. Then the malware can control the encryptor, meaning you're hosed in any event.

1
0
Silver badge

Re: Is it too late for everybody to get behind that?

Easier to simply Get Rid Of Useless JavaScript Now! and remove the most pernicious XSS infection vector the world (wide web) has ever seen.

Seriously, why in the name of Farkle J Thinggblat the Fourth would you need to have client-side javascript (or indeed any client side smarts) in order to read e-mail?

Stupid with a capital stupe.

1
0
Bronze badge

Re: Is it too late for everybody to get behind that?

Seriously, why in the name of Farkle J Thinggblat the Fourth would you need to have client-side javascript (or indeed any client side smarts) in order to read e-mail?

So you can perform encryption and decryption in the MUAs, and the MTAs never see plaintext or keys. Why is that hard to understand?

0
0
Bronze badge

Re: Sigh...

The question is, why has this not happened w/r/t PGP/GPG?

It has, any number of times. I have a GPG plugin for Thunderbird, and at least one GUI GPG wrapper (which I installed to see how usable it would be for non-technical users). There seem to be many others.

A better question would be why haven't they become popular? Because:

- Most email users want to minimize cognitive load and opportunity cost, which means using the MUA that minimizes what they have to learn and how much work they have to do. Webmail beats separate MUA applications by that metric.

- By the same token, most email users don't want to have to learn even the high-level security concepts associated with PGP/GPG (or PEM or S/MAIL or any of the other schemes that have been floated). They don't want to learn about asymmetric encryption and public and private keys and digital signatures. They really don't want to learn about the Web of Trust or other PKI architectures, all of which are usability disasters. Many aren't really clear on what "encryption" is in the first place, or how the newspaper Cryptogram differs from standard algorithms or from the mythical "military-grade encryption" they hear about on NCIS.

- Most email users are operating under a threat model where the benefits of email cryptography (privacy, integrity, some degree of authentication and non-repudiation) are very small. Hell, I wouldn't care if the vast majority of my email were published, and I'm an IT security professional.

Widespread adoption of email with digitally-signed envelopes would offer some benefit to most email users, as it would eliminate some spam and phishing channels, but the key there is widespread - and thus convincing users to adopt it now, so eventually it would scale up enough to help. And even then the implementation has to be very good.

0
0

Why 128 bit AES not 256 bit?

Just asking.

0
0
Silver badge

Re: Why 128 bit AES not 256 bit?

Why AES at all???

How about a non-American government generated encryption method instead?

1
6
Bronze badge

Re: Why 128 bit AES not 256 bit?

>How about a non-American government generated encryption method instead?

How about one invented by a few Belgium blokes? There is a good one called AES....

13
0
Anonymous Coward

Re: Why 128 bit AES not 256 bit?

How about one invented by a few Belgium blokes? There is a good one called AES....

Well, it's actually called Rijndael, but that probably sounds too foreign and lack acronyms..

3
0

Re: Why 128 bit AES not 256 bit?

The time to decrypt\encrypt goes up dramatically between 128 and 256. 256 would be better left to hardware and not software which works against a browser based mail.

1
0
Bronze badge

Re: Why 128 bit AES not 256 bit?

I wonder if decrypting 256 bit AES would be faster than I can read the decrypted output; and also whether the time taken to encrypt really matters as long as it happens in less than minutes. And I wonder what the answers would be if the computer were restricted to an 8086.

1
0
Bronze badge

Re: Why 128 bit AES not 256 bit?

How about a non-American government generated encryption method instead?

You're free to build your own MUA using Camelia, if that makes you happy. Or you could adopt a reasonable threat model.

0
0
Anonymous Coward

Tricky problem

Replace 'hacked' with 'receives a secret court order' and you suddenly discover the vulnerability if this secure email service is hosted in the USA, or hosted by any business that has any assets in the USA, or by anyone who lives in a country with a no-quibble extradition treaty to the USA. How can you ensure the Javascript you're running hasn't been replaced with an NSA trojanised version that sends your key in the response the first time you unlock it?

I suppose the site could sign their code, but that then requires a browser to be able to natively check the signature against a trusted public key. A signature validating Javascript could just be likewise crippled by a court order. And it also doesn't help when the court order requires the provider to sign the NSA trojaned code with their key.

Perhaps there needs to be browser level support for the ability to mark a Javascript file as 'frozen', with browsers popping up huge great big warning messages should a frozen JS file ever change in the future. Put the critical decryption code into that JS, debug it, and never touch it again. And train your users to become -very- suspicious should you ever claim you need to change it, and to ignore anything you say that might explain why. Remember that court order? It's probably going to include something like "You must put a notice on your website reassuring users the updated script is to fix a criticial security bug"

Ideally? Ditch email. Find yourself a secure instant messenger, perhaps developed in a Scandinavian country and therefore hopefully immune from the NSA's secret backdoor shenaningans.

3
1
Anonymous Coward

Re: Tricky problem

Ideally? Ditch email. Find yourself a secure instant messenger, perhaps developed in a Scandinavian country and therefore hopefully immune from the NSA's secret backdoor shenaningans.

Won't work if you explicitly need to retain that information for later (usually required by any regulated business, and they have to be really, really careful with IM), oh, and I would reconsider the Scandinavian thing if I were you.. Messaging is very interruptive, email is asynchronous - you can park it until you have time.

0
0
Silver badge

Re: Tricky problem

"Messaging is very interruptive ..."

The 'problem' with IM is that you need the applications and the computers to be running all the time. Apart from that, you can send it anytime you like and could read a received message anytime you like.

0
0
Anonymous Coward

Re: Tricky problem

The 'problem' with IM is that you need the applications and the computers to be running all the time.

That is, if you don't want an IM service to store your messages in between (a bit like Skype messages) because then you'd have the same data-at-rest problem as email.

Now, what is the problem with constant running software?

1 - can be a surveillance vector in itself (think Teamviewer in read only mode), and the user won't have a clue what is happening as we now have connections fast enough to allow that

2 - constant ability to track the users - we have far too many facilities to locate people these days. WiFi IDs, GPS chips, IP geotagging.

No thanks.

0
0
Silver badge

Browsers cannot be secure...

...since there the encrypted channel is based on public certificates. Though you can get something similar to certificate pinning with self-signed certificates, this can easily be subverted by using normal certificates.

What we finally need to do is to get GPG to be more usable and shipped by default with e-mail software.

1
0
Bronze badge

Re: Browsers cannot be secure...

Something like Enigmail?

0
0
Bronze badge

Re: Browsers cannot be secure...

[in browsers] the encrypted channel is based on public certificates

HTTPS normally uses X.509 certificates and a PKI that relies on preinstalled signing certificates to provide authentication, yes. That's a far cry from "the encrypted channel is based on public certificates" (a meaningless claim if interpreted strictly), and even farther from "that's how browsers do encryption".

In the case of a browser-hosted MUA written in ECMAScript, where encryption happens in the MUA, the subversion of the HTTPS authentication mechanism is utterly irrelevant to the confidentiality of the email message, except on one branch of the attack tree: when the MUA itself is retrieved from a compromised server (and thus replaced with a compromised MUA).

However, there's no reason, in principle, why the endpoints couldn't load the MUA from an uncompromised local source.1

For that matter, technical users could eliminate the normal HTTP PKI attack vectors (compromised CAs, typically) by constructing their own PKI in parallel with the public one. Plenty of organizations do that already (installing their own root certificates in the browser stores, etc). It's a usability nightmare, but so is the existing HTTPS PKI. Again, the point is that problems with the HTTPS PKI do not necessarily compromise encrypting MUAs running in the browser.

What we finally need to do is to get GPG to be more usable and shipped by default with e-mail software.

Already done (see my post above). Didn't help. Most people don't want encrypted email if they're required to do anything to get it.

1Obviously that requires a prior secure channel, but the main point remains: it doesn't depend on the normal HTTPS PKI.

0
0
Anonymous Coward

Oh no. Not again.

I have been struggling to communicate securely with my nefarious brotherlings for some time now.

Hence, I have decided to hang up my swag-bag, say 'farewell' to the ne'er-do-well folk, and get a proper job.

(damn, how do I say farewell to them securely?)

1
0
Silver badge
Devil

Re: AC Re: Oh no. Not again.

"I have been struggling to communicate securely with my nefarious brotherlings for some time now....." I know! It's just so hard to keep in touch with your minions, especially when carrier pigeons are too scared to fly into the volcano hideout (let alone the problem of launching them from my supersecretsub!).

0
0
Bronze badge
Joke

Re: AC Oh no. Not again.

The pigeons couldn't make it past the sharks with their frikkin' lasers.

1
0

Third rate pen-testers

"Tutanota told The Register it had run an "extensive penetration test" during which cross-site scripting attacks were attempted. These tests [results PDF] were carried out by Syss GmbH,"

Good to know who to avoid in the future.

1
0

Corrections

Dear Sir,

the thing you call Results PDF, merely is a certificate of passing security tests. A results PDF would have info like: Description of test, execution time, results, detailed results in case XPASS or FAIL or XFAIL.

That would also indicate that the tests would be regressive, and that indeed when not using SSys GmbH, one can rerun the same tests.

Different subject: Who scrutinised the tests? They don't seem too clever or inclusive...

Regards,

Guus

PS: I know about the correction link and stuff. I just wonder why I must fire up all sorts of infrastructure just to give an email about corrections... A Webform would be much easier...!!!???!!!

1
0

Anyone looked at it with Fiddler?

So in taking a passive look with Fiddler (which the site does not complain about - such does mail.google.com):

SSL on Welcome page:

Secure Protocol: Tls

Cipher: Rc4 128bits

Hash Algorithm: Sha1 160bits

Key Exchange: RsaKeyX 2048bits

Note: The above cert was purchased after app.tutanota.com's cert, which is AES. Though it did try to negotiate TLS/1.2 ... (Firefox and all).

Missing header elements like:

X-Frame-Options, Content Security Policy (Src, Script Src, Obj Src), anti-mime sniffing and XSS Protection directives.

Spotty Cache-Control .... esp with JSON, which contains Symemtric and Pre-Shared Keys....though I will not try to speak to their encryption practices.

404 error shows that Jetty is in use, and though it could be fake, Apache/2.2.22?

Why would they use the URL for to/from email addresses? Those get stuff into logs.

GET request: /--SNIP--2mailAddress%22%3A%22awood495%40yahoo.com%22%7D--/snip-

POSTs are not redirected.

And some of the stuff on their site is large - non-min'd JS, pics, etc. Bandwidth is cheap, unless you live where it is not.

I could go on, but there could be some tightening of this site.

1
0
Bronze badge

Re: Anyone looked at it with Fiddler?

Missing header elements like:

X-Frame-Options, Content Security Policy (Src, Script Src, Obj Src), anti-mime sniffing and XSS Protection directives.

This sort of thing is the real problem. I'm not inclined to put much faith in any provider of "secure" web-based software, if its developers can't be bothered to go through the OWASP Top 10 list and implement their recommendations.

It's not like this is top-secret knowledge. You don't have to be a television-drama super-hacker to plug these sorts of holes. Organizations like OWASP make this information available for free, with clear, cogent, simple explanations that should be accessible to any experienced practitioner. Fixing these things might take a week or two for a competent team.

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon