| 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 |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14903 [details]
workaround for the issue
Build Information:
Wireshark 2.2.0 (bae2e8e from master)
Copyright 1998-2016 Gerald Combs <[email protected]> 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.