Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3177] Jabber dissector: Detect and dissect SSL payload.

Date: Wed, 7 Jan 2009 06:58:03 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3177





--- Comment #2 from Florian Forster <wireshark.org@xxxxxxxxxxxxxxxxxxx>  2009-01-07 06:57:59 PDT ---
(In reply to comment #1)
> Could you please provide a capture file showing an XMPP session that uses TLS?

Sure, will create a PCAP file when I come home.

> As you mention "STARTTLS", it would be better to take that as a trigger to
> start treating packets afterwards as TLS. Have a look at
> 'epan/dissectors/packet-http.c' to see how it changes to SSL after the "CONNECT
> <HOST-PORT>" command in a proxied SSL connection to see how that can be done.

I see two potential problems with that:

- Jabber messages are XML. If I simply search for `starttls', I may interpret
  some irrelevant part of the payload as a request to encrypt the connection.
  To do this ``right'', I'd need to fully decode the XML payload and scan the
  parse tree. As far as I see this, this is currently not possible with the
  XML dissector.

  As soon as the actual parsed XML is available to the Jabber dissector, you
  could display a *lot* more information about the contents of the package.
  Unfortunately I currently don't have enough time to dive into that.

- Jabber/XMPP connections are usually long-lived. Unless you scan for a long
  time, you probably miss the connection setup, thus not seeing the packet
  containing `starttls'. Passing the packets of those connections to the XML
  dissector will yield the same bad output that's displayed right now (i. e.
  something like `Jabber request: \015\002g\247...').

What do you think about this compromise:

 - Scan for `starttls' using the equivalent to
     strstr (buffer, "starttls")
   (or whatever is appropriate to match most valid starttls-requests). If
   found, future packets are passed to the SSL dissector.

 - Check for control characters (other than 0x0A and 0x0D) in the buffer.
   Since they should not appear in valid XML (to my knowledge at least),
   it's relatively sane to assume binary data in this case. Display `binary
   payload of unknown type'.

 - Otherwise, use the XML dissector.

Regards,
-octo


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.