[Cryptography Team] Debugging SSL on Linux

Tue Mar 20 22:03:20 UTC 2007

Hey Rob,

I'll look more into the asn issue but this doesn't explain why it works on
my machine. 

I was able to connect and retrieve data just fine, I just checked again
with:

ANS1.26

Core.23

SSL.109

X509.32

I'll try your new code but first I'll verify the extension data and see if I
can tell why it is parsing correctly on my machine.  I can't get to it till
tomorrow.

Thanks for looking at it!

Ron  

  _____  

From: Robert Withers [mailto:reefedjib at yahoo.com] 
Sent: Tuesday, March 20, 2007 4:43 PM
To: Ron at USMedRec.com; Cryptography Team Development List
Cc: 'Norbert Hartl'
Subject: Re: [Cryptography Team] Debugging SSL on Linux

Ron and Norbert,

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:

' <https://home.selfish.org/> https://home.selfish.org' asUrl
retrieveContents.

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

On Mar 20, 2007, at 11:01 AM, Ron Teitelbaum wrote:

Hello everyone,

Can anyone help debugging SSL on Linux?

This is from Norbert:

I'm using it on linux with squeak vm 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006
gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu
2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default
plugin location: /usr/local/lib/squeak/3.9-8/*.so and a stock 3.9 7067
image. I tried using a fresh copy of the image but the errors stay the same
errors.

I tried using the url that Norbert gave and it worked fine on Windows.

'https://home.selfish.org <https://home.selfish.org/> ' asUrl
retrieveContents.

Could someone try this on Linux and see if they can help provide info as to
what is going wrong. I suspect that the client hello is causing the server
to disconnect. Maybe an Endian issue?

Thanks,

Ron Teitelbaum
Squeak Cryptography Team Leader

_______________________________________________

Cryptography mailing list

Cryptography at lists.squeakfoundation.org

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20070320/2022ea6b/attachment-0001.htm