https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5485
--- Comment #4 from Sake <sake@xxxxxxxxxx> 2010-12-13 08:46:41 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > I'm getting a malformed packet warning. This looks like RFC5485 Errata ID: 1585
> >
> > Ugh, so that means gnutls is generating pre-errata CertificateRequest formats.
> > How would you feel about arranging the decode to check if the 2nd/3rd bytes of
> > the CertificateRequest message look like a valid sig alg and if not decode
> > w/out that field (and note "pre Errata 1585-missing Sig ID") or some such?
>
> Upon further inspection, no... it looks like the packet is ok. I also receive
> a "Malformed Packet: SSL" message. The problem appears to be that the version
> of Wireshark mentioned above simply doesn't proceed past the CertificateRequest
> message to process the ServerHelloDone message in the same packet (which means
> that gnutls is doing the right thing).
That's what I thought too, looking at the tracefile. However, looking a bit
more deep. It looks like GNUtls is doing a proper job and Wireshark is not. If
you expand the CertificateRequest in the packet details pane, you can see that
it sees a length of 10 for the "Distinguished names", however, this should be
the list of SignatureAndHashAlgorithm. If you look in the hex pane, then it is
clear that after the 10 bytes of SignatureAndHashAlgorithm, there is another
length of "00 16" and that is the Distinguished name list. After that, The new
TLS record with the ServerHelloDone.
tshark does decode things properly when not using -V to fully dissect the
packets.
So... the SSL dissector should be updated according to Errata 1985. One can
wonder wether there are implementations that do follow the RFC instead of the
errata and if Wireshark should be able to distinguish them.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
