[bugzilla-daemon@xxxxxxxxxxxxx]

     Robert Bullen
 changed
              bug 6434

What	Removed	Added
Priority	Low	High
CC		robert@robertbullen.com

Comment # 3 on bug 6434 from Robert Bullen

I continually run into this bug while analyzing decrypted HTTPS traffic. I have
verified that it is present at least as far back as 1.4 and is still a problem
in the 1.9 development trunk.

The instance of this bug that I am currently experiencing is as follows (this
is only one side of the TCP connection):

SSL Segment #  TCP Segment #s
-------------  --------------
            A   1               
            B   2-13
            C  13-17

As you can see, TCP segment 13 carries the end of SSL segment B and the
beginning of SSL segment C. In this scenario the Follow SSL Stream window
displays only SSL segments A and C.

I had only a moment to spend stepping through the code. From what I can tell,
TCP segment 13 is not being sent through the tap listener
(follow_ssl.c::ssl_queue_packet_data()) that is registered in
follow_ssl.c::follow_ssl_stream_cb().

Of course, the code that queues packets for taps is found in
packet-ssl.c::dissect_ssl(). There is a comment there that may be relevant:

    /* TCP packets and SSL records are orthogonal.
     * A tcp packet may contain multiple ssl records and an ssl
     * record may be spread across multiple tcp packets.
     *
     * This loop accounts for multiple ssl records in a single
     * frame, but not a single ssl record across multiple tcp
     * packets.
     *
     * Handling the single ssl record across multiple packets
     * may be possible using wireshark conversations, but
     * probably not cleanly.  May have to wait for tcp stream
     * reassembly.
     */

However, it seems that we are observing the opposite of the second paragraph of
that comment. And the third paragraph leads me to believe that the comment is
just plain out of date.

---

      You are receiving this mail because:

• You are watching all bug changes.