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 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
