HTML email

[gus2986]

When Settings > Compose HTML messages > always, no encrypting email body, full process without errors but sending out original message.

Thanks for help.

[lazlolazlolazlo]

I think the same applies here as with drafts, when encryption / signing is enabled HTML messages should be disabled.

[quemquis]

I can confirm this issue. The workaround I found was to have plain text editor as default, although that's less than ideal.

[niklasfemerstrand]

I'm leaning towards lazlo's idea. Less than ideal but it would pose a huge security threat to allow HTML messages. With keys residing in the browser accessible by anything in the DOM I'm not sure if I could sleep well at night with the risk of somehow missing to filter something and that way leave glaring vulnerabilities.

I never use HTML emails, how do other email clients handle this issue? It's not surely relevant since we are web based here, but it's worth to look at how others do and consider the same thing.

[niklasfemerstrand]

The main issue is that by parsing HTML content and allowing it in the decryption process Roundcube's own XSS filtering and such is bypassed. We could port it to JavaScript, but I'm not sure if we can guarantee the result to be the same, which could leave us very vulnerable.

Technically the message could be returned to the server and then have the server return the decrypted content filtered. But that would void everything in terms of security by exposing decrypted content to the server.

[gus2986]

A solution could be add to this plugin a HTML editor and a function to encrypting the result form the editor, because you get control in the HTML editor and disable the native HTML editor tool.

[gus2986]

Hi, Quick question, where the plugin store the Key Manager info?

[niklasfemerstrand]

Check the readme.

[gus2986]

Oooh I see, thanks for the answer, I will need a version of this plugin storing at mysql roundcube tables and creating automatic the keys at the user creation time with same password as user account. Please email to [email protected] to talk about. Thanks.

[niklasfemerstrand]

No thanks, you can write your backdoors yourself.

[gus2986]

upss sorry I am not trying to offend you. just a quick $ ... thanks anyway

[niklasfemerstrand]

It goes totally against my principles, sorry. I'm not putting my name on concious insecurity.

[gus2986]

but not keeping you own keys at db force to create you key at each computer, so leaving your private keys at a cybercafe computer is more insecure I guess.

[niklasfemerstrand]

but not keeping you own keys at db force to create you key at each computer

Yeah... We should probably invent something to make it easier to transfer data between computers using some sort of hardware storing device.

so leaving your private keys at a cybercafe computer is more insecure I guess.

Exactly. Don't put your keys on devices you don't control. That includes your server, from the perspective of your users.

[gus2986]

Well, losing a flash_mem is much common that something braking in my server, in fact you can encrypt the key at your server db, I lost many mems sticks ... you didnt?

[niklasfemerstrand]

Sorry to rain on your parade but this plugin's agenda is not to enhance your memory so that you don't lose your sticks.

But since you're asking, no I've never lost one actually.

[gus2986]

Ok, fine!

[krautsource]

Regarding the original topic, you're raising a very important point:

it would pose a huge security threat to allow HTML messages. With keys residing in the browser accessible by anything in the DOM I'm not sure if I could sleep well at night with the risk of somehow missing to filter something and that way leave glaring vulnerabilities. [..] The main issue is that by parsing HTML content and allowing it in the decryption process Roundcube's own XSS filtering and such is bypassed.

However, this is not a concern when sending email, but only when receiving email. Which means two things, if I'm not mistaken (bear with me, it's currently 3 AM where I live):

• There is probably no point in preventing roundcube users from encrypting outgoing HTML emails.
• Since we cannot prevent an attacker from sending us encrypted HTML email, we have to sanitize any and all decrypted output.

Please correct me if I'm wrong...

[niklasfemerstrand]

However, this is not a concern when sending email, but only when receiving email.

Unless you're replying to an HTML email and it's parsed (wrongfully), am I right?

Since we cannot prevent an attacker from sending us encrypted HTML email, we have to sanitize any and all decrypted output.

Yes, so it becomes difficult to receive encrypted HTML. hmhm...

[phunehehe]

How about decrypting the HTML content, then stripping all but some basic HTML tags (using a whitelist)? I'm going to implement this somehow because I use gpg-mailgate to encrypt all incoming emails and some services just won't send a text-only version.