[Tickets #12970] Re: Don't override sticky OPTIONS values with default values.

noreply at bugs.horde.org noreply at bugs.horde.org
Wed Oct 29 03:29:13 UTC 2014


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/12970
------------------------------------------------------------------------------
  Ticket             | 12970
  Updated By         | software-horde at interfasys.ch
  Summary            | Don't override sticky OPTIONS values with default
                     | values.
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


software-horde at interfasys.ch (2014-10-29 03:29) wrote:

I've processed 3 messages using OpenSSL. One sent from Thunderbird,  
one from the BB client and one from the iOS client using `openssl cms`.

Message from TB can be decrypted properly
Message from iOS can't be decrypted because iOS got confused and used  
the wrong certificate to encrypt the message. Not sure what happened,  
but I can't test further as the client just crashes as soon as it  
receives certificates from Horde.

Message from BB client can't be decrypted as is
Error reading S/MIME message
34374513640:error:0D07207B:asn1 encoding  
routines:ASN1_get_object:header too long:asn1_lib.c:153:
34374513640:error:0D0D106E:asn1 encoding routines:B64_READ_ASN1:decode  
error:asn_mime.c:193:
34374513640:error:0D0D40CB:asn1 encoding routines:SMIME_read_ASN1:asn1  
parse error:asn_mime.c:528:

After analysis, I found that the pkcs7 data is sent in one long line  
and that throws off the OpenSSL parser.
If I format the data using a max-length of 72 characters, then OpenSSL  
can decrypt the data.

What's inside is another binary message which starts with
Content-Type: application/x-pkcs7-mime
Content-Transfer-Encoding: base64

but this time it's a signed message with a SignedData structure and  
lines with fixed width.

So, my guess is that Horde sends the msg to OpenSSL which can't handle  
it as is. That's one half of the problem.

The other half is figuring out if Horde is doing something which  
prevents the BB client from understanding the message it gets or if  
the client only understands messages where the data is on one line.

I couldn't find a spec regarding the maximum amount of characters per  
line allowed in pkcs7 data, so I'm guessing that what they're doing is  
legal and one reason most clients can read it.










More information about the bugs mailing list