Hi,
> It seems to me that the way Wireshark handles some aspects of the SSL
> communication is wrong or at least inconsistent.
It is a "feature" of the Wireshark BER ASN.1 handling (packet-ber.c) -
only the Value of the ASN.1 Tag/Length/Value are selected - which to
be fair is often what you want.
Nothing is wrong with the SSL communication - or indeed inconsistent.
Wireshark just currently doesn't do what you would like/expect it to
do. But that can be changed! 8^)
> Let us take a packet
> where the server furnishes its certificate. If we select the string
> "Certificate: 3082..." in the middle window, corresponding bytes will
> be automatically selected in the lower one. Export in the CER-file by
> means of the context menu must leave us with a valid certificate.
> However, its signature turns out to be invalid. What is the reason? To
> get a right X.509 DER certificate we must add to the selected bytes
> four preceding ones.
I came across this same issue and as I regularly want to be able to
extract various bits of ASN.1 (including certificates) from captures,
I added a local BER preference in my Wireshark.
It allows the ASN.1 tag and length bytes to be selected in addition to
the value - which then allows the intact, valid ASN.1 to be exported
as you would wish/expect. (Though it doesn't currently worked with
IMPLICITly tagged fields).
Given there is more interest than just me maybe I should check it in.
> By the way, the first two them are also 30 82, which could be the origin of the confusion.
'30' indicates SEQUENCE
'82' indicates the next two bytes contain the length of the SEQUENCE
Graeme