| Bug ID |
11557
|
| Summary |
Parsing of ECDSA signatures (with TLS 1.2, brainpoolP256r1) in ClientVerify
|
| Product |
Wireshark
|
| Version |
unspecified
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13894 [details]
Screenshot: Wrongly parsed ECDSA signature
Build Information:
Version 1.12.7 (v1.12.7-0-g7fc8978 from master-1.12)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Aug 12 2015),
with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz, with 8065MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
I had to estabslish a TLS connection as client where client authentification is
required. To investigate problems in achieving that I captured traffic using
wireshark.
Having TLS 1.2, and a TLS_ECDHE_ECDSA ciphersuite parsing of the Client Verify
message works wrong.
In the Client Verify the ECDSA signature is for example 04 03 00 46 ...,
according to RFC this indicates the hash algorithm (04 = SHA-256), the
signature algorithm (03 = ECDSA), followed by the signature (00 46 = length of
signature, 70 byte).
However wireshark shows this in the GUI as:
Signature length: 1027 (marking the bytes 04 03 which indicate
signatureAndHashAlgorithm) and
Signature: 0046304402203856adca8913e6bbcb04c58d915133d310d3... (taking the 00
46 bytes as part of the signature).
This seems to be a lack of parsing ECDSA signatures.
In the shown screenshot I had used a wrong value of 64 for the signature
algorithm. Hence the reported signature length is 1088 instead of 1027 as
indicated by the bytes 04 40 (the ones immediately before the marked ones
containing the signature).
You are receiving this mail because:
- You are watching all bug changes.