IS SSTP-dissector broken or can I simply not select it?
Hello.
Trying both my own capture and the example-files provided in the Wiki ( https://gitlab.com/wireshark/wireshar... ). I cannot seem to get wireshark to display SSTP properly. In the example I am able to decrypt the TLS-stream, but now it only shows "HTTP continuation"-packets.
Trying to use "Decode As" will not allow me to select SSTP.
If I understand this correct SSTP is basically Data-in-PPP-in-HTTP-in-TLS.
Not entirely sure what's going on, but the sample file has an unbelievable HTTP content-length of 18446744073709551615 in frame 125 which causes the HTTP dissector to look for the rest of the data which will never arrive.
Content length seems to be a according to spec: https://docs.microsoft.com/en-us/open...
Anyway, I am trying older portable releases. Seems to work on 3.0.12 but doesn't work anymore on 3.1.0.. So perhaps there was an update to the http dissector on that point?
For my own trace it stops working after EAP takes over, might have to correct ciphers on my RADIUS-server.
Hmm Content-Length: 18446744073709551615 (ULONGLONG_MAX) should we set a limit for reassembly?
As noted by @Zerqent, it's a bogus specified value in the SSTP docs which actually causes the HTTP\SSTP client to hang around for some time. As dissection works correctly by disabling reassembly as noted in my answer I don't think we need to do anything as the value is actually correct (for the protocol) in this case.
Even adding an Expert Info would cause an incorrect warning in this case.
I was more thinking that we could skip reassembly if the content is bigger than some reasonable/configurable value