[TLS] TLS1.2 CertificateVerify deocding

Akos Vandra <axos88@gmail.com> Wed, 15 July 2009 08:39 UTC

Return-Path: <axos88@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554953A6A40 for <tls@core3.amsl.com>; Wed, 15 Jul 2009 01:39:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfiRpbABblWC for <tls@core3.amsl.com>; Wed, 15 Jul 2009 01:39:44 -0700 (PDT)
Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 439DE3A6B2A for <tls@ietf.org>; Wed, 15 Jul 2009 01:39:01 -0700 (PDT)
Received: by bwz28 with SMTP id 28so1264376bwz.37 for <tls@ietf.org>; Wed, 15 Jul 2009 01:37:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=bDPZ9QP0Pr8RDjd/dEMX4H56jFUoJlvF+/7YLKcsaOY=; b=E+TkSUVwHMUb8Amku7t27qbAW+0SN4aDrSGByGnb8z3EtFZ9WN+07wpb5JylfTN0Ek UtdCZxaIBvCO2GRGCCZ65x/QkRr0Qi4DrtZiyw3IfAR8GN7G1ygC0OGMYq0i+uOjDWaL ls9kgXVdh31NdULzKhNdWdDrS6z0QaGSyge5w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TyJvzRzWX7KApgXsGPC+WlLaDhW0cKK3TQuuZZ7iXnad15NG3+pkpOOqgLEJDFLy21 LbATSatFw8n1oolUgKuFULAr0iTwstCfbLIvNccGq7akP1Yuv5PCcAHnqavhRuLXKCU0 4ig+AWGkkjJ4FdZb5Rk4P/SlYEe+DLHFagVUQ=
MIME-Version: 1.0
Received: by 10.204.116.69 with SMTP id l5mr7359451bkq.52.1247647054203; Wed, 15 Jul 2009 01:37:34 -0700 (PDT)
Date: Wed, 15 Jul 2009 10:37:34 +0200
Message-ID: <a53f2ccc0907150137r2c7dc9c1v6d68780c9b997288@mail.gmail.com>
From: Akos Vandra <axos88@gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [TLS] TLS1.2 CertificateVerify deocding
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 09:01:52 -0000

Hello,

I have written to half a dozen mailing lists, but never got an answer.
This is why I am contacting you, in spite of the fact that I don't
think my email is on-topic here.

I am a student doing some research on the inner workings of TLSv1.2,
for implementation on a custom hardware.

Currently I am sniffing traffic between gnutls-serv and gnutls-cli,
and trying to work out each bytes meaning (yeah I am a little bit
crazy, but this helps me understand the protocol top to bottom. :)

I am trying to decode the CertificateVerify structure, but have thus far failed.
I have access to both client(512bit) and server(1024bit) keys, and
have sniffed their
communication, what I came up with
(along the stream) is this CertificateVerify packet sent from the
client to the server:

0x16, 0x03, 0x03, 0x00, 0x46,
0x0f, 0x00, 0x00, 0x42, 0x00, 0x40, 0xe4, 0xe9,
0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67,
0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d,
0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6,
0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48,
0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49,
0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30,
0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b,
0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3

As far as I know, this means the next things:

TLSPlainText.
 ContentType = 0x16 (Handshake)
 ProtocolVersion = 0x03, 0x03,
 Length = 0x00, 0x46,
 Fragment = Handshake
TLSPlainText.Handshake.
  HandshakeType = 0x0f (certificate_verify)
  Length = 0x00, 0x00, 0x42,
  Body = CertificateVerify
TLSPlainText.Handshake.
CertificateVerify
    Length = 0x00, 0x40,   <-- The RFC doesn't say that there should
be a length info here, but
this certainly is the remaining part's length.
    Data = 0xe4, 0xe9,
           0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67,
         0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d,
         0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6,
         0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48,
         0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49,
         0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30,
         0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b,
         0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3

I tried decoding this signed data with openssl (successfully), it yielded:

$openssl rsautl -verify -inkey clientkey.pem -in sign.bin -hexdump

0000 - 47 f6 a5 1b a9 cb 4a a6-90 63 2c 65 ec 6f 6d 20
0010 - 10 af a8 f0 f0 80 0d 99-a3 22 cf 2b 07 b0 a4 c8
0020 - c7 ec 1d 33

My question is how to interpret this data? From the rfc I understood
that this should be a .DER encoded

    struct {
       SignatureAndHashAlgorithm algorithm;

       opaque signature<0..2^16-1>;
    } DigitallySigned;

But this certainly isn't one (for ex. the second byte which should be
a length byte is way too long).
What am I missing?
I am not sure what is the hash that should be calculated, so I am not
sending that along, because I
don't think it would be correct.

Thanks in advance for your help,
 Vandra Ákos