https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14603

            Bug ID: 14603
           Summary: x509ce iPAddress always decoded as IPv4
           Product: Wireshark
           Version: 2.4.6
          Hardware: x86-64
                OS: Windows 10
            Status: UNCONFIRMED
          Severity: Normal
          Priority: Low
         Component: Dissection engine (libwireshark)
          Assignee: bugzilla-ad...@wireshark.org
          Reporter: stefanp-a-bugs.wireshark....@cabal1.net
  Target Milestone: ---

Build Information:
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,
with
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 1.1.1.1) 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 1.1.1.1 and 1.0.0.1, 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
so:

>                                                                 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 38.6.71.0, which
corresponds to the first four bytes of the IPv6 address.

To reproduce, capture your HTTP client requesting <https://1.1.1.1/> 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 <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to