Bug ID: 14603
Summary: x509ce iPAddress always decoded as IPv4
OS: Windows 10
Component: Dissection engine (libwireshark)
Target Milestone: ---
Version 2.4.6 (v2.4.6-0-ge2f395aa12)
Compiled (64-bit) with Qt 5.6.3, with WinPcap (4_1_3), with GLib 2.42.0, with
zlib 1.2.8, with SMI 0.4.8, with c-ares 1.12.0, with Lua 5.2.4, with GnuTLS
3.4.11, with Gcrypt 1.7.6, with MIT Kerberos, with GeoIP, with nghttp2 1.14.0,
with LZ4, with Snappy, with libxml2 2.9.4, with QtMultimedia, with AirPcap,
SBC, with SpanDSP.
Running on 64-bit Windows 10, build 16299, with Intel(R) Core(TM) i3-7100U CPU
2.40GHz (with SSE4.2), with 32657 MB of physical memory, with locale
German_Germany.1252, with Npcap version 0.97, based on libpcap version 1.8.1,
with GnuTLS 3.4.11, with Gcrypt 1.7.6, without AirPcap.
Built using Microsoft Visual C++ 14.0 build 24215
The Cloudflare recursive DNS service (aka 126.96.36.199) supports DNS-over-HTTP
(DoH), as well as IPv6 endpoints. Since DoH runs over HTTPS, it has a TLS
certificate not only for the IPv4 address literals 188.8.131.52 and 184.108.40.206, but
also for the IPv6 address literals 2606:4700:4700::1111 and
2606:4700:4700::1001. These exist as subjectAlternateName fields.
According to RFC5280, page 36, both types encode into an iPAddress field like
> For IP
> version 4, as specified in [RFC791], the octet string MUST contain
> exactly four octets. For IP version 6, as specified in
> [RFC2460], the octet string MUST contain exactly sixteen octets.
(Imagine you have all of ASN.1 at your disposal, and then you require two
different types of data of fixed (but different) length to be encoded into the
same variable length field. Yeah.)
Unfortunately, wireshark always decodes this field as IPv4 address. (Offending
code probably in epan/dissectors/asn1/x509ce/packet-x509ce-template.c:103.)
The IPv6 address literal 2606:4700:4700::1111 encodes as TLV bytes (in hex) 87
10 26 06 47 00 47 00 00 00 00 00 00 00 00 00 11 11, the second nibble of the
first byte indicating type iPAddress 07d, and the second byte 10h indicating a
length of 16d. Wireshark decodes this to the IPv4 address 220.127.116.11, which
corresponds to the first four bytes of the IPv6 address.
To reproduce, capture your HTTP client requesting <https://18.104.22.168/> and
inspect the server certificate in Wireshark.
You are receiving this mail because:
You are watching all bug changes.
Sent via: Wireshark-bugs mailing list <email@example.com>