[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
- [TLS] TLS1.2 CertificateVerify deocding Akos Vandra
- Re: [TLS] TLS1.2 CertificateVerify deocding carlyoung