author Dennis Jackson <>
Sun, 26 Mar 2023 07:31:40 +0000
changeset 657950 dee1eb3308521b4cb7c8a3afe44520efcf582650
parent 292808 6c2df11a71b14819993bfe3f29cf8439551b802c
permissions -rw-r--r--
Bug 1822876: Add H3 ECH Telemetry. r=kershaw,necko-reviewers This patch adds telemetry which records when H3 connections succeed / fail and what kind of ECH they used. Our H3 ECH tests are extended to test these different modes and that the telemetry is recorded correctly. Differential Revision:

# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at

SSL's Buffers: enumerated and explained.


gs = ss->gather
hs = ss->ssl3->hs

gs->inbuf   incoming (encrypted) ssl records are placed here,
        and then decrypted (or copied) to gs->buf.

gs->buf     ssl3_HandleHandshake puts decrypted ssl records here.

hs.msg_body When an incoming handshake message spans more
        than one ssl record, the first part(s) of it are accumulated
        here until it all arrives.

hs.msgState an alternative set of pointers/lengths for gs->buf.
        Used only when a handleHandshake function returns SECWouldBlock.
        ssl3_HandleHandshake remembers how far it previously got by
        using these pointers instead of gs->buf when it is called
        after a previous SECWouldBlock return.


sec = ss->sec
ci  = ss->sec->ci   /* connect info */

ci->sendBuf Outgoing handshake messages are appended to this buffer.
        This buffer will then be sent as a single SSL record.

sec->writeBuf   outgoing ssl records are constructed here and encrypted in
        place before being written or copied to pendingBuf.

ss->pendingBuf  contains outgoing ciphertext that was saved after a write
        attempt to the socket failed, e.g. EWouldBlock.
        Generally empty with blocking sockets (should be no incomplete

ss->saveBuf Used only by socks code.  Intended to be used to buffer
        outgoing data until a socks handshake completes.  However,
        this buffer is always empty.  There is no code to put
        anything into it.


SECWouldBlock means that the function cannot make progress because it is
waiting for some event OTHER THAN socket I/O completion (e.g. waiting for
user dialog to finish).  It is not the same as EWOULDBLOCK.


Rank (order) of locks

recvLock ->\ firstHandshake -> recvbuf -> ssl3Handshake -> xmitbuf -> "spec"
sendLock ->/

crypto and hash Data that must be protected while turning plaintext into

SSl3:   (in ssl3_SendPlainText)
    ss->ssl3            (the pointer)
    ss->ssl3->current_write*    (the pointer and the data in the spec
                     and any data referenced by the spec.

    ss->sec->writebuf* (ptr & content) locked by xmitBufLock
    "buf"                  locked by xmitBufLock

crypto and hash data that must be protected while turning ciphertext into

SSL3:   (in ssl3_HandleRecord )
    ssl3->current_read* (the pointer and all data refernced)

Data that must be protected while being used by a "writer":

ss->saveBuf.*       (which is dead)

in ssl3_sendPlainText

ss->ssl3->current_write-> (spec)

in SendBlock



Data variables (not const) protected by the "sslGlobalDataLock".
Note, this really should be a reader/writer lock.

cipherSuites[]      ssl3con.c