Debugging SSL on Linux

From: Robert Withers [mailto:[hidden email]]
Sent: Tuesday, March 20, 2007 4:43 PM
To: [hidden email]; Cryptography Team Development List
Cc: 'Norbert Hartl'
Subject: Re: [Cryptography Team] Debugging SSL on Linux

I found that SSL failed to establish a connection on the Mac, and I suspect the same is actually true on Windows, on close inspection. The resulting MIMEDocument has an error when evaluating the example:

I debugged into the SSLSocket and found where the ProtocolCap was getting killed. This occurred when processing the SSLCertificateMsg, with a certificate chain of 2 certificates. The new code I added to verify certificates is having a problem verifying certificate 1 with certificate 2.

Digging a little further showed that there are 3 problems, the 2nd and 3rd hidden by the 1st.

The 1st problem is the comparison if cert1's issuer with cert2's subject. One part of these X509Names is a Pkcs9EmailAddress, which is wrapping a ASN1IA5String. This class (ASN1IA5String) is missing an #= operation, and so they are claiming they are not equal. I fixed this.

The 2nd and 3rd problems are ASN1 encoding/decoding problems.

The 2nd problem is an issue with tag 12 being encoded as 19, the default for a String.

the source bytes encoded with this code

          | bytes |

          bytes := #(160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.

          (ASN1Value fromAsnDer: bytes readStream) encodeAsnDer.

encode as

          #(160 18 19 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)

check the third byte to see the problem. Since the TBSCertificate are reencoded for signature checking, the ASN1 hierarchy must be able to reencode precisely. So I added several classes for different types of strings (ASN1PrintableString, ASN1UniversalString, and ASN1BMPString) and updated the tag table to use them. This solves this problem, but there are still holes in the ASN1 tag framework.

The 3rd problem is an ASN1 decoding problem with an ASN1ExplicitContextValue class, that is embedded in a CertificateExtension. Here is the ExplicitContextValue part, which seems to be malformed:

          | bytes ext |

          bytes := #(160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.

          ext := (ASN1Value fromAsnDer: bytes readStream).

          ext encodeAsnDer

resulting in:

          a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5)

Notice the 2nd byte. Now this being embedded means that the part that dropped off is actualy captured in the certExtension, and when he certExtension encdes itself, here is the fragment that it encodes:

          a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)

The original bytes gave a length of 30, which captured 2 values and I didn't think a ExplicitContextValue could do that. The encoded bytes have a length of 10 which is just the first element. When it decodes, instead of grabbing the bytes specified by length it just decodes the next ASN1Value, the first chunk. So here is how it breaks down:

<{160} [30] (

          <{6} [8] (43 6 1 5 5 7 8 5)>

          <{160} [18] (

                      <{12} [16] (104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)>

          )>

)>

Now, either an ExplicitContextValue can have 2 values like this, and we need to change some code, or this is malformed. Please advise if we can change ExplicitContextValue to handle this.

If it is malformed, then because we are re-encoding the ASN1 bytes to do signatures, and since I added the Certificate Extensions, this is now breaking. Either we need to save the original bytes to do signatures with, and avoid re-encoding, or else this correctly fails. Saving the original bytes of ASN1 is a major rewrite.

Sorry I couldn't get this site working for you right away, but we will need to resolve this issue in the design, first.

Robert

From: Robert Withers [mailto:[hidden email]]
Sent: Tuesday, March 20, 2007 4:43 PM
To: [hidden email]; Cryptography Team Development List
Cc: 'Norbert Hartl'
Subject: Re: [Cryptography Team] Debugging SSL on Linux

I found that SSL failed to establish a connection on the Mac, and I suspect the same is actually true on Windows, on close inspection. The resulting MIMEDocument has an error when evaluating the example:

I debugged into the SSLSocket and found where the ProtocolCap was getting killed. This occurred when processing the SSLCertificateMsg, with a certificate chain of 2 certificates. The new code I added to verify certificates is having a problem verifying certificate 1 with certificate 2.

Digging a little further showed that there are 3 problems, the 2nd and 3rd hidden by the 1st.

The 1st problem is the comparison if cert1's issuer with cert2's subject. One part of these X509Names is a Pkcs9EmailAddress, which is wrapping a ASN1IA5String. This class (ASN1IA5String) is missing an #= operation, and so they are claiming they are not equal. I fixed this.

The 2nd and 3rd problems are ASN1 encoding/decoding problems.

The 2nd problem is an issue with tag 12 being encoded as 19, the default for a String.

the source bytes encoded with this code

          | bytes |

          bytes := #(160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.

          (ASN1Value fromAsnDer: bytes readStream) encodeAsnDer.

encode as

          #(160 18 19 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)

check the third byte to see the problem. Since the TBSCertificate are reencoded for signature checking, the ASN1 hierarchy must be able to reencode precisely. So I added several classes for different types of strings (ASN1PrintableString, ASN1UniversalString, and ASN1BMPString) and updated the tag table to use them. This solves this problem, but there are still holes in the ASN1 tag framework.

The 3rd problem is an ASN1 decoding problem with an ASN1ExplicitContextValue class, that is embedded in a CertificateExtension. Here is the ExplicitContextValue part, which seems to be malformed:

          | bytes ext |

          bytes := #(160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray.

          ext := (ASN1Value fromAsnDer: bytes readStream).

          ext encodeAsnDer

resulting in:

          a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5)

Notice the 2nd byte. Now this being embedded means that the part that dropped off is actualy captured in the certExtension, and when he certExtension encdes itself, here is the fragment that it encodes:

          a ByteArray (160 10 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)

The original bytes gave a length of 30, which captured 2 values and I didn't think a ExplicitContextValue could do that. The encoded bytes have a length of 10 which is just the first element. When it decodes, instead of grabbing the bytes specified by length it just decodes the next ASN1Value, the first chunk. So here is how it breaks down:

<{160} [30] (

          <{6} [8] (43 6 1 5 5 7 8 5)>

          <{160} [18] (

                      <{12} [16] (104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103)>

          )>

)>

Now, either an ExplicitContextValue can have 2 values like this, and we need to change some code, or this is malformed. Please advise if we can change ExplicitContextValue to handle this.

If it is malformed, then because we are re-encoding the ASN1 bytes to do signatures, and since I added the Certificate Extensions, this is now breaking. Either we need to save the original bytes to do signatures with, and avoid re-encoding, or else this correctly fails. Saving the original bytes of ASN1 is a major rewrite.

Sorry I couldn't get this site working for you right away, but we will need to resolve this issue in the design, first.

Robert

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Withers
Sent: Tuesday, March 20, 2007 9:22 PM
To: [hidden email]
Cc: 'Cryptography Team Development List'; 'Norbert Hartl'
Subject: Re: [Cryptography Team] Debugging SSL on Linux

I just want to reiterate that by not preserving the original bytes when decoding, we are forced to re-encode to check signatures.  With that comment out of the way...

First, I turned off CertificateExtension decoding and republished, so the latest code should now work.  I couldn't get it to work...

Second, this is long in the tooth...  

I am referring to the ASN1 book by Olivier Dubuisson, which you had referred me to at one point so I think you have access to this pdf.

Per Figure 18.2 on page 396, we are using the ASN1ExplicitContextValue to wrap APPLICATION {01cttttt}, Context-specific {10cttttt} and PRIVATE {11cttttt} values - tags 6 and 7.  They can be Primitive (Implicit) or Constructed (Explicit) - tag 5.  This specific example is using Explicit Context-specific [0] (see page 409, section 18.2.16 Tagged value, where the value of the Explicit triplet is itself one triplet).

Now, this section just named refers to page 216, which is the chapter on Constructed values.  I just scanned it and it seems necessary to define structures as a SEQUENCE, with no "implicit" structures - i.e. they don't seem to define a Context-specific type that can hold more than one Triplet without embedding it in a SEQUENCE.

So, here is the type definition for an Extension:

Extension         ::=   SEQUENCE {

   extnId            EXTENSION.&id ({ExtensionSet}),

   critical          BOOLEAN DEFAULT FALSE,

   extnValue         OCTET STRING }

                -- contains a DER encoding of a value of type

and the problem we are having is by trying to DER decode the extnValue field.  Here is the full data for that field, both raw and parsed with hex values:

#(48 50 130 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103 160 30 6 8 43 6 1 5 5 7 8 5 160 18 12 16 104 111 109 101 46 115 101 108 102 105 115 104 46 111 114 103) asByteArray

SEQUENCE = T(30) L(32) V(

          Implicit [2] = T(82) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67)

          Explicit [0] = T(A0) L(1E) V(

                      OID = T(06) L(08) V(2B 06 01 05 05 07 08 05)

                      Explicit [0] = T(A0) L(12) V(

                                  String = T(0C) L(10) V(68 6F 6D 65 2E 73 65 6C 66 69 73 68 2E 6F 72 67))))

The outer is a SEQUENCE and is ok.  Inside, at the value of the first Explicit [0] Triplet, it is not a SEQUENCE, but it has 2 Triplets inside of it.  Looking at its Length (1E), it thinks it should be holding both Triplets.

The code is only grabbing the first Triplet when decoding an Explicit [0], and then the outer Sequence is decoding the second inner Triplet, so I actually get:

Sequence (

          Implicit [2]

          Explicit [0] (OID)

          Explicit [0] (String))

instead of:

Sequence (

          Implicit [2]

          Explicit [0] (

                      OID

                      Explicit [0]))

the corresponding length is messed up when I re-encode it.

That's funny, as we agree.  I'll post to the ASN1 list...

later,

Rob

From: [hidden email] [mailto:[hidden email]] On Behalf Of Ron Teitelbaum
Sent: Wednesday, March 21, 2007 12:59 PM
To: 'Cryptography Team Development List'; 'Robert Withers'
Subject: RE: [Cryptography Team] Debugging SSL on Linux

Ron,

From: [hidden email] [mailto:[hidden email]] On Behalf Of Robert Withers
Sent: Wednesday, March 21, 2007 4:27 PM
To: [hidden email]
Subject: Re: [Cryptography Team] Debugging SSL on Linux

I am trying to find out the intersection of Explicit/Implicit and Primitive/Constructed. I think what I am learning is that the Primitive/Constructed is represented in the tag of a Triplet, but the Explicit/Implicit is a property of the Type Module defining user types. We don't have any representation of that, since we are wrapping it all in an ASN1ExplicitContextValue.

I am still wrapping both Primitive and Constructed, but I took you advice and allowed Constructed types to have more than one value - i.e. an Implicit Sequence

We really need to do what you were working on it seems with your ASN1DefinitionModel. We need to be able to provide the Type definition to the parser, which is just the #fromAsnDer: method, and allow the BER to be mapped to user classes. Big job.

Rob