[RCD] RC 1.2.1 - Enigma signed e-mail validation failure

Discussion:

s***@schema31.it

2016-07-27 14:11:27 UTC

Hi. I'm facing a strange behaviour on latest RC version.

I've enabled Enigma plugin and I'm able to create my key pairs, sign and
encrypt messages.

The strange thing is I couldn't verify signed messages at all, even if
decryption in perfectly working.

I've debugged GPG class
(vendor/pear-pear.php.net/Crypt_GPG/Crypt/GPG.php) to verify what he was
doing and why sign validation always fails.

Within _SIGN() method, I've added following lines to log what he was
going to sign:

_$rc = rcmail::get_instance();_
_$rc->console('---------------------------------');_
_$rc->console('SIGN INPUT');_
_$rc->console($input);_
_$rc->console('---------------------------------');_

Same thing within _VERIFY() method, to log what is going to verify:

_$rc = rcmail::get_instance();_
_$rc->console('---------------------------------');_
_$rc->console('VERIFY INPUT');_
_$rc->console($input);_
_$rc->console('---------------------------------');_
_$rc->console('VERIFY SIGNATURE');_
_$rc->console($signature);_
_$rc->console('---------------------------------');_

Here is my full output for the sequence:

* user send a new signed email to himself
* user goes to inbox and open signed e-mail

I've noticed that the signed message has an extra newline between main
headers and body (take a look at the highlited rows) so I thing that's
why sign verification fails (content doesn't match with original
message).

_[27-Jul-2016 15:10:38 +0200]: <cmnloql4>
---------------------------------_
_[27-Jul-2016 15:10:38 +0200]: <cmnloql4> SIGN INPUT_
_[27-JUL-2016 15:10:38 +0200]: <CMNLOQL4> CONTENT-TYPE:
MULTIPART/ALTERNATIVE;_
_ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_

_--=_944CBD90B0D51928FF049222817A4B03_
_Content-Transfer-Encoding: 7bit_
_Content-Type: text/plain; charset=US-ASCII_

_This is an HTML content..._
_--=_944cbd90b0d51928ff049222817a4b03_
_Content-Transfer-Encoding: quoted-printable_
_Content-Type: text/html; charset=UTF-8_

_<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=_
_=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family:
Verdana,Gen=_
_eva,sans-serif'>_
_<p>This is an HTML content...</p>_
_</body></html>_

_--=_944cbd90b0d51928ff049222817a4b03--_

_[27-Jul-2016 15:10:38 +0200]: <cmnloql4>
---------------------------------_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4>
---------------------------------_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY INPUT_
_[27-JUL-2016 15:10:45 +0200]: <CMNLOQL4> CONTENT-TYPE:
MULTIPART/ALTERNATIVE;_
_ BOUNDARY="=_944CBD90B0D51928FF049222817A4B03"_

_--=_944CBD90B0D51928FF049222817A4B03_
_Content-Transfer-Encoding: 7bit_
_Content-Type: text/plain; charset=US-ASCII_

_This is an HTML content..._
_--=_944cbd90b0d51928ff049222817a4b03_
_Content-Transfer-Encoding: quoted-printable_
_Content-Type: text/html; charset=UTF-8_

_<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=_
_=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family:
Verdana,Gen=_
_eva,sans-serif'>_
_<p>This is an HTML content...</p>_
_</body></html>_

_--=_944cbd90b0d51928ff049222817a4b03--_

_[27-Jul-2016 15:10:45 +0200]: <cmnloql4>
---------------------------------_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4> VERIFY SIGNATURE_
_[27-Jul-2016 15:10:45 +0200]: <cmnloql4> -----BEGIN PGP SIGNATURE-----_
_Version: GnuPG v1_

_iQEcBAEBAgAGBQJXmLLOAAoJEB1v3mO3A8Wpz6QH/015jrt7YkfGT8pE1nyjpHHe_
_JoCEmugkpmEgJ6wjTgU1SHQos5l1mKqFhsrzpdNghO11yqB/NxOjxOpqSkE9c9c1_
_dXr/H53cLfqPULMD5dqGBFua180BUdLAQ0Nvyll7kD8Y/irU5ccrwA1e3Cb9RYp0_
_sGplLYcD7pPKthCGQfFzPslL9Fj82MBJigm46cKa7pqYhJDNkM4q4zsqtNXcTUqB_
_HcFhEL3+Q21bAbie+B8hDw2SUYGEZORf+sLUrW1oQLLG5ld6XZywCDDKdpq6F+ET_
_OzVaXta8cMIg5dwP/10VALlqYavlzjY/0h7lBmEgm5W/ehs7XuReur45LsS1KJg=_
_=Q6j9_
_-----END PGP SIGNATURE-----_

_[27-Jul-2016 15:10:45 +0200]: <cmnloql4>
--------------------------------_

Anyone is facing the same issue?

Maybe it's not an Enigma related issue but a Roundcube behaviour because
it happes even on not signed e-mails (but in this case it doesn't bother
at all).

Any help would be really appreciate.

Thanks.

Stefano

A.L.E.C

2016-07-28 06:34:15 UTC

Permalink

I’ve noticed that the signed message has an extra newline between main
headers and body (take a look at the highlited rows) so I thing that’s
why sign verification fails (content doesn’t match with original message).

Works for me, but I have an idea that it could be some IMAP response
parsing issue or IMAP server issue. Could you provide imap_debug log for
the moment when you open the message?

And this is the relevant part of the code, in case you'd like to work on
this by yourself.

https://github.com/roundcube/roundcubemail/blob/release-1.2/plugins/enigma/lib/enigma_engine.php#L1185-L1187

--
Aleksander 'A.L.E.C' Machniak
Kolab Groupware Developer [http://kolab.org]
Roundcube Webmail Developer [http://roundcube.net]
---------------------------------------------------
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl

s***@schema31.it

2016-07-28 08:54:38 UTC

Permalink

Enabled IMAP and SMTP debug (see attachments) and tested against a
DBMail internal mail server and an external one (GMail to simplify test
repeatability).

Attached files are related to the GMail session.

As you can see, IMAP response differs on main mime part headers
structure, so i think that's the reason for sign verification failure.

Any idea on how to fix this?

Thanks!

Stefano

SMTP log

....... cut .......

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_12a667e67cfa1dc2752a3a26a0315da3
CONTENT-TYPE: MULTIPART/MIXED;
BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2"

....... cut .......

IMAP log (response)

....... cut .......

[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] C: A0008 UID FETCH 9460
(BODY.PEEK[1.MIME])
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: * 31 FETCH (UID 9460
BODY[1.MIME] {80}
[28-JUL-2016 10:23:17 +0200]: <ML905LHG> [17EE] S: CONTENT-TYPE:
MULTIPART/MIXED; BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2"
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S:
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: )
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] S: A0008 OK Success
[28-Jul-2016 10:23:17 +0200]: <ml905lhg> [17EE] C: A0009 UID FETCH 9460
(BODY.PEEK[1])

....... cut .......

Parsed IMAP response

....... cut .......

CONTENT-TYPE: MULTIPART/MIXED;
BOUNDARY="=_6252574EB3EF7A89798CDB7924177AF2"

....... cut .......

Post by A.L.E.C

Post by s***@schema31.it
I've noticed that the signed message has an extra newline between main
headers and body (take a look at the highlited rows) so I thing that's
why sign verification fails (content doesn't match with original message).

Works for me, but I have an idea that it could be some IMAP response
parsing issue or IMAP server issue. Could you provide imap_debug log for
the moment when you open the message?
And this is the relevant part of the code, in case you'd like to work on
this by yourself.
https://github.com/roundcube/roundcubemail/blob/release-1.2/plugins/enigma/lib/enigma_engine.php#L1185-L1187

A.L.E.C

2016-07-28 09:28:06 UTC

Permalink

Post by s***@schema31.it
Enabled IMAP and SMTP debug (see attachments) and tested against a
DBMail internal mail server and an external one (GMail to simplify test
repeatability).
Attached files are related to the GMail session.
As you can see, IMAP response differs on main mime part headers
structure, so i think that's the reason for sign verification failure.

I created a ticket for this issue
https://github.com/roundcube/roundcubemail/issues/5371

I don't see a simple workaround now, we'd need to get the whole signed
message body and parse it instead of fetching headers and body of the
first part separately. I'll take a look at this over the weekend.

Andrea Brancatelli

2016-07-28 13:29:20 UTC

Permalink

Hello Alec,

just as a confirm of your hypothesis, if you look at the raw source of
the message within Roundcube (Action -> show source) it's layout is
different from the one that gets thrown at gpg.

This is the very same mail:

RAW SOURCE:

[....]

Message-ID: <***@brancatelli.it>
X-Sender: ***@brancatelli.it
User-Agent: Roundcube Webmail/1.2.1

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

--=_ad16315c31f34b75fe12de9a5f6ff9c3
Content-Type: multipart/mixed;
boundary="=_0c2026a878accfb67f4729bf2f2a522d"

--=_0c2026a878accfb67f4729bf2f2a522d
Content-Type: multipart/alternative;
boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"

--=_4f6a45d8f3d31b8528676bb2b9630c46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

[...]

CONSOLE LOG:

[...]

[28-Jul-2016 15:19:22 +0200]: <s4r01i4d>
---------------------------------
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> VERIFY INPUT
[28-Jul-2016 15:19:22 +0200]: <s4r01i4d> CONTENT-TYPE: MULTIPART/MIXED;
BOUNDARY="=_0C2026A878ACCFB67F4729BF2F2A522D"^M
^M
--=_0c2026a878accfb67f4729bf2f2a522d^M
Content-Type: multipart/alternative;^M
boundary="=_4f6a45d8f3d31b8528676bb2b9630c46"^M
^M
--=_4f6a45d8f3d31b8528676bb2b9630c46^M
Content-Transfer-Encoding: 7bit^M
Content-Type: text/plain; charset=US-ASCII^M
^M
Mail firmata mandata tramite potassio.^M
--=_4f6a45d8f3d31b8528676bb2b9630c46^M
Content-Transfer-Encoding: quoted-printable^M
Content-Type: text/html; charset=UTF-8^M

[...]

---

Andrea Brancatelli
Schema31 S.p.a.
Responsabile IT

ROMA - BO - FI - PA
ITALY
Tel: +39.06.98.358.472
Cell: +39.331.2488468
Fax: +39.055.71.880.466
SocietÃ del Gruppo SC31 ITALIA

Post by A.L.E.C

I created a ticket for this issue
https://github.com/roundcube/roundcubemail/issues/5371
I don't see a simple workaround now, we'd need to get the whole signed
message body and parse it instead of fetching headers and body of the
first part separately. I'll take a look at this over the weekend.