Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 12879] New: Cannot decrypt EAP-TTLS traffic (not recognized as conversation)

[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	12879
Summary	Cannot decrypt EAP-TTLS traffic (not recognized as conversation)
Product	Wireshark
Version	2.2.0
Hardware	x86
OS	All
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	michael+wireshark@stapelberg.de

Created attachment 14903 [details]
workaround for the issue

Build Information:
Wireshark 2.2.0 (bae2e8e from master)

Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.6.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.48.1, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.11.0, with Lua 5.2.4, with GnuTLS 3.5.3, with Gcrypt 1.7.3-beta, with MIT
Kerberos, with GeoIP, with QtMultimedia, without AirPcap.

Running on Linux 4.6.0-1-amd64, with locale LC_CTYPE=de_DE.UTF-8,
LC_NUMERIC=de_DE.UTF-8, LC_TIME=en_DK.UTF-8, LC_COLLATE=de_DE.UTF-8,
LC_MONETARY=de_DE.UTF-8, LC_MESSAGES=C, LC_PAPER=de_DE.UTF-8,
LC_NAME=de_DE.UTF-8, LC_ADDRESS=de_DE.UTF-8, LC_TELEPHONE=de_DE.UTF-8,
LC_MEASUREMENT=de_DE.UTF-8, LC_IDENTIFICATION=de_DE.UTF-8, with libpcap version
1.7.4, with GnuTLS 3.5.3, with Gcrypt 1.7.3-beta, with zlib 1.2.8.
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (with SSE4.2)

Built using gcc 6.1.1 20160802.

--
Even though I have a corresponding premaster log file and the TLS connection
uses non-DH ciphers, wireshark fails to decrypt an EAP-TTLS session.

This is because packets from the client to the server are put into a different
conversation than from the server to the client. I came to this theory because:

1) In the ssldebug file, I see a different conversation pointer for
client→server traffic than for server→client traffic.
2) In the UI, on the left hand side of the packet list, I see a mixture of
dotted/solid lines, indicating that the packets are not in the same
conversation.

The attached patch works around the issue, but is obviously just a workaround:
it just assigns EAP packets the TCP src/dest port 23.

I’ve attached a sample capture file so that you can reproduce the issue. Please
let me know if you have any further questions.

---

      You are receiving this mail because:

• You are watching all bug changes.