| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
- Make a separate sigalgs list for TLS 1.3 including only modern
algorithm choices which we use when the handshake will not negotiate
TLS 1.2
- Modify the legacy sigalgs for TLS 1.2 to include the RSA PSS algorithms as
mandated by RFC8446 when the handshake will permit negotiation of TLS 1.2
ok jsing@ tb@
|
|
|
|
|
|
| |
A couple of cleanup/style tweaks while here.
ok tb@
|
| |
|
|
|
|
| |
ok jsing@
|
|
|
|
|
| |
appear with which messages.
ok jsing@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the TLS extension code was rewritten, TLS extensions could only exist
in ClientHello and ServerHello messages - as such, they were named in pairs
of *_clienthello_{needs,build} which would be called by the client and
*_clienthello_parse. Likewise for *_serverhello_{needs,build} which would
be called by a server and *_serverhello_parse, which would be called by a
client.
Enter TLSv1.3 - TLS extensions can now exist in one of seven messages,
with only certain types being allowed to appear in each, meaning the naming
scheme no longer works. Instead, rename them to indicate the caller rather
than the message type - this effectively means:
clienthello_needs -> client_needs
clienthello_build -> client_build
clienthello_parse -> server_parse
serverhello_needs -> server_needs
serverhello_build -> server_build
serverhello_parse -> client_parse
ok beck@ tb@
|
|
|
|
|
| |
Add a priority list for tls 1.2
ok jsing@
|
|
|
|
|
| |
that will be usable with TLS 1.3 with less eye bleed.
ok jsing@ tb@
|
|
|
|
|
|
|
|
|
| |
RFC 7919 renamed the Supported Elliptic Curves TLS extension to Supported
Groups and redefined it to include finite field DH (FFDH) in addition to
elliptic curve DH (ECDH). As such, rename the TLS extension and change the
associated code to refer to groups rather than curves.
ok beck@ tb@
|
|
|
|
|
|
| |
by moving the needs/build/parse functions into their own struct.
ok beck@ tb@
|
|
|
|
|
|
|
|
| |
alert rather than an internal_error alert.
Issue found by Simon Friedberger, Robert Merget and Juraj Somorovsky.
ok beck@ inoguchi@
|
|
|
|
|
|
|
|
|
|
|
| |
The RI logic gets pulled up into ssl3_get_server_hello() and
ssl_parse_serverhello_tlsext() gets replaced by tlsext_client_parse(),
which allows a CBS to be passed all the way down.
This also deduplicates the tlsext_client_build() and tlsext_server_build()
code.
ok beck@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes ssl_parse_clienthello_tlsext() and allows the CBS to be
passed all the way through from ssl3_get_client_hello(). The renegotation
check gets pulled up into ssl3_get_client_hello() which is where other
such checks exist.
The TLS extension parsing now also ensures that we do not get duplicates
of any known extensions (the old pre-rewrite code only did this for some
extensions).
ok inoguchi@
|
|
|
|
| |
Also reference the knowledge base article instead of a discussion thread.
|
|
|
|
|
|
|
|
| |
If no TLS extensions are present in a client hello or server hello, omit
the entire extensions block, rather than including it with a length of
zero.
ok beck@ inoguchi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- When parsing the OCSP extension we can have multiple responder IDs - pull
these out correctly.
- Stop using CBS_stow() - it's unnecessary since we just need access to the
data and length (which we can get via CBS_data() and CBS_len()).
- Use a temporary pointer when calling d2i_*() functions, since it will
increment the pointer by the number of bytes it consumed when decoding.
The original code incorrectly passes the pointer allocated via CBS_stow()
(using malloc()) to a d2i_*() function and then calls free() on the now
incremented pointer, most likely resulting in a crash. This issue was
reported by Robert Swiecki who found the issue using honggfuzz.
ok beck@
|
|
|
|
|
|
|
| |
after we finish building the responder ID list. Otherwise adding to the
responder ID list fails.
ok beck@
|
|
|
|
|
|
| |
leaving ssl_add_{client,server}hello_tlsext() as pointer to CBB wrappers.
ok doug@
|
|
|
|
|
|
|
| |
This needs to skip past the CBS data or it will be treated as a decode
error even though it returns 1.
ok jsing@
|
|
|
|
|
|
|
|
| |
callback has been installed. This ensures that the ALPN extension is valid
and avoids leaving unprocessed extension data, which leads to a decode
error.
Found the hard way by jsg@
|
|
|
|
| |
input + ok beck@, jsing@
|
|
|
|
|
| |
ok bcook@ beck@
input + ok jsing@
|
|
|
|
|
|
|
|
|
|
| |
RFC 4492 only defines elliptic_curves for ClientHello. However, F5 is
sending it in ServerHello. We need to skip over it since our TLS extension
parsing code is now more strict.
Thanks to Armin Wolfermann and WJ Liu for reporting the issue.
input + ok jsing@
|
|
|
|
| |
ok jsing@
|
|
|
|
| |
ok beck@ doug@
|
|
|
|
|
|
| |
extension framework.
ok jsing@ beck@
|
|
|
|
|
|
| |
extension framework.
input + ok jsing@
|
| |
|
|
|
|
|
|
| |
new extension framework.
input + ok jsing@
|
|
|
|
|
|
|
|
| |
tlsext_sni_serverhello_parse(). This also adds a check to ensure that
if we have an existing session, the name matches what we specified via
SNI.
ok doug@
|
|
|
|
|
|
|
|
| |
and the new extension framework.
Feedback from doug@
ok inoguchi@
|
|
Introduce a TLS extension handling framework that has per-extension type
functions to determine if an extension is needed, to build the extension
data and parse the extension data. This is somewhat analogous to BoringSSL,
however these build and parse functions are intentionally symetrical. The
framework is hooked into the existing TLS handling code in such a way that
we can gradual convert the extension handling code.
Convert the TLS Server Name Indication extension to the new framework,
while rewriting it to use CBB/CBS and be more strict in the process.
Discussed with beck@
ok inoguchi@
|