Comment # 4
on bug 10686
from Dave Tapuska
(In reply to Peter Wu from comment #3)
> Giving a second thought to it, this patch[1] increases the peak memory usage
> during dissection. It can be optimized as follows:
>
> 1. Clear the ClientHello message (freeing data as needed) and any hash
> structures (just in case a capture contains garbage). Save the ClientHello
> message when the extension is set.
> 2. The next expected message is the ServerHello. This is an authoritative
> message that decides the TLS version to be used. If the extension is
> enabled, initialize the hashes. Now the ClientHello message copy can be
> cleared (both when the extension is available and not available).
>
> Now whenever after step 2 the extension is enabled, update the hash with the
> handshake data. After calculating the MS, one could free the hash structures
> again.
>
> [1]: https://code.wireshark.org/review/#/c/5168/3
Yes the peak memory usage is increased in terms of readability; once you
process the ServerHello then you know the hash algorithm that is used and can
start computing running hashes which is a fixed size as opposed to a variable
size (all the client hello messages). The problem with this approach I found
and that I didn't have a solution for was that the hash algorithms are
currently allocated and released in a single stack context via gcrypt; if we do
this then we need to allocate them on the heap; storing them in the
SSlDecryptSession. I did not see a callback for when this structured is freed
and the gcrypt deallocate functions can be called. If there is such a callback
please advise.
You are receiving this mail because:
- You are watching all bug changes.