• Registered: 2008-12-12
  • Posts: 6

Topic: apply FireGPG not only to plain text but to parts of the DOM tree

Hello,

I think it's a pity that FireGPG allows to encrypt data only but not HTML tags. It's not very convenient to encrypt all data fields one by one let alone the display problems.

I think often it would make more sense to encrypt parts of the document that include tags. an example:

<div class="firegpgcontainer">
<p>This is my <strong>formatted</strong> text with my <a href="youneverknow.tld">secret link</a>.</p>
</div>

could be transformed into

<div class="firegpgcontainer">
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.9 (GNU/Linux)

hQIOA0NeQ3HmI++IEAf/RwUzty28vpcQmkfpKgzRkd/pxkwTiW0DyFDoXd0Ju420
IXpRzzo6WW7GiBFLc0+eCcIr8bZ/hLcTCtpga7/JiBP8jEkC8VDC78+rAU44lca5
PICYIZ6M2jZoblDwt8pDPxvDsmo4dURGtWAYRnoDS69zBo4GPWZ4QfT/0uEA+oSG
QoemictFa1sYbRwlP5IrTdsCLfy9NfSZg+vT0/I1Pc/AHGSWGgQXDl5c+504yweZ
8yCybE6NqakXLsX0R8ATsiS23bW66VPpsGrI+NRbwjIKg2+/rPiCU5gcbZchPTBB
EywNx/lh4CvDxURBBKSOJLYhefJ8ZCwfljP8s+jNPwf+Is56aQPW1cwuaPxM+2Ys
buPr3KL3yGOI/QbT+UZYcbX5wjLrlAZJ9lH3InLBo9jBZAFF9arO4SoYm3fLaAFs
53oie3eqI6rozXwC+X952YH37BGGXfphnGE5On7BkI7ODCSXKLQRoN8LU4wjeaLZ
fOS3+xLr6rLKkrfTjp07+pSJ7FbNw7pynq6oAOUrqRuTeFGNUX6M8XHUxudyhs5O
HXsU3xHnVKgwPSfPozp9aCphKlfpbtWphL5lrxp++hQiT5slN61z9WtsnUQBSUQ3
4Iwr2dR4HJwwzOIwszBDRmAp4uZD3h2wkr5lBD9rTKu3Fa1zwCG3b7RVpMeYRfTe
mNKWAWDc9kVmRn4tJCV8KbtWyp9IhqQX/sLriNke6gmQLa7fAEN+gsC/i1Ic16eJ
r0CrOxpZp54Tk4XlY1LIje6rrfdJjqNsC5i82W0dxwxLu4eTpIYsPI6TGjMYDew7
qlWL4QHCF7H807eiv5bnNpaITe3smOZarlQJxKke8omorIWK+ThqdbY9p7cZ7Jp6
FtSEH6se/KSe
=A7QW
-----END PGP MESSAGE-----
</div>

That would be correct from an HTML parser's point of view (plain text without illegal characters within <div>). After decryption the result could be added to the Document by adding DOM nodes and their content. This could be restricted to valid code. So it might be necessary to install one of the existing offline validation add-ons. Thus it might make sense to restrict the encrypted DUM subtree to XHTML. Perhaps it is possible to create a new "document" without opening a window in Firefox. Then you could create a temporary document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
</head>
<body>

<div class="firegpgcontainer">
<!-- insert decrypted data here -->
</div>

</body>
</html>

have that one checked by a validator add-on and in case of success simply read and copy the DOM nodes and contents from the temporary document into the real one. But that's just an implementation idea by someone who doesn't know anything about this kind of programming. :-)

  • From: Geneva
  • Registered: 2007-04-04
  • Posts: 1,040

Re: apply FireGPG not only to plain text but to parts of the DOM tree

Problem : About security ?

If someone send a email to a yahoo user, using his private key. FireGPG autodecrypt the text, and re-insert it into the dom. Imagine the text contains javascript (XSS) or a image (tracking).

So it's seem to be a good idea but.. it not a good idea wink

the_glu's Website

  • Registered: 2008-12-12
  • Posts: 6

Re: apply FireGPG not only to plain text but to parts of the DOM tree

That wouldn't make any difference to sending the same code unencrypted. A signature even less encryption does not say anything about the quality of the content.

The only possible problem is that the encryption hides malicious code from browser features so that they would not be dangerous if unencrypted. But that would mean that these protection features could easily be circumvented by Javascript (in unencrypted documents) thus this is not a valid argument.

If you want to play it safe you can easily erase all critical tags (<script>) and attributes (href to a different domain, onmouseover and so on).

  • From: Geneva
  • Registered: 2007-04-04
  • Posts: 1,040

Re: apply FireGPG not only to plain text but to parts of the DOM tree

> That wouldn't make any difference to sending the same code unencrypted.

I don't agree, as this problem are (should) handle by system who have to, in my example yahoo.

FireGPG can't parse html to be secure in all different case, except if he simply remove all html and keep the text, only the text.

You said "href to a different domain". But href to the same domain are dangerous too. Imagine an <img src="delete.php?id=balbalba"> wink Edit : woops misunderstanding

Safe tags are only tags like <b>, <font>, etc. But we should handle unclosed tags, etc.. It's too works for a not very critical feature...

But notice we have to think on this problem. We have to (it's our #1 problem now) be able to parse mail in pgp/mine format. Who encrypt/sign mail at lower level that the mail content, so when we decrypt this kind of email, we (can) got html...

Last edited by the_glu (2008-12-12 23:31:59)

the_glu's Website

  • Registered: 2008-12-12
  • Posts: 6

Re: apply FireGPG not only to plain text but to parts of the DOM tree

Your "Yahoo can't handle then what is supposed to handle" argument is valid for webmail (and theoretically proxy servers) only, not for normal web pages because there is nobody between you and the original data who could check it for you.

This leads to the idea to lock your webmail domain for this feature. A further protection would be to only parse such code as HTML which is not only encrypted but signed, too. And the user may decide: "decrypt as plain text" vs. "decrypt as HTML".

In general I would say that you try to care about a problem that is not yours. Checking encrypted contents (just think of SSL protected web pages and filtering proxies) has to be solved at the application level. That cannot be an argument against using encryption. And if HTML cannot be encrypted its an argument against encryption if you need HTML.

  • From: Geneva
  • Registered: 2007-04-04
  • Posts: 1,040

Re: apply FireGPG not only to plain text but to parts of the DOM tree

> Checking encrypted contents (just think of SSL protected web pages and filtering proxies) has to be solved at the application level.

Yes. But we are after the application, who is the server who create the page, not the client.

> In general I would say that you try to care about a problem that is not yours.

Yes it's our problem. An Firefox extension has full rights (an extension can format your disk if she wants...), and use FireGPG to inject html is a problem wink.

Edit :

Ho btw, it's apply to webmail but we can't detect all webmail in the world. It's apply to forums too if it's apply to webmail. And blogs. And everything.

Last edited by the_glu (2008-12-13 00:11:57)

the_glu's Website

  • Registered: 2008-12-22
  • Posts: 2

Re: apply FireGPG not only to plain text but to parts of the DOM tree

hello smile
congrats on the plugin, thank you smile

the_glu wrote:

Ho btw, it's apply to webmail but we can't detect all webmail in the world. It's apply to forums too if it's apply to webmail. And blogs. And everything.

perhaps supporting bbcode (for forums) would be a good idea...

no safety issues there smile

being able to display the quotes on an encrypted pm on a forum, would be nice...


also, if there is a clear signed message (on a forum such as this one) which contains quotes, it doesn't display correctly and verification fails...
if i clear signed my current post for example, verification would fail, i tested it on a preview just to be sure...

thanks again for the great plugin big_smile


(ps. the "Back to the WebSite" link on the top left of the forum, points to getfiregpg.prg instead of .org ... perhaps you want to fix it)

edit: i think i found a bug... check out this post  http://www.nabble.com/Re%3A-New-GnuPT-V … 06688.html 
while the signature verifies by copy-paste the original text, it fails to verify in firegpg

Last edited by JollyRoger (2008-12-22 06:03:03)

  • Registered: 2009-01-02
  • Posts: 2

Re: apply FireGPG not only to plain text but to parts of the DOM tree

The nabble page above that has the "bug" is due to the html on the page. if you copy the "original" text, you get the > that was escaped as HTML entities (>). If you view the source of the page and take that, though, you get something different, which is probably the source of the problem - mis-interpreting HTML entities. Any thoughts?