summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Correct value for SSL_TLSEXT_MSG_HRR.jsing2020-01-251-2/+2
| | | | ok beck@ tb@
* Add tls_extension_seen(), a utility to know if a particular extensionbeck2019-01-281-1/+2
| | | | | has been seen in the handshake so far. Use it for keyshare. ok tb@
* Add server side of versions, keyshare, and client and server of cookiebeck2019-01-241-1/+9
| | | | | | | | extensions for tls1.3. versions is currently defanged to ignore its result until tls13 server side wired in full, so that server side code still works today when we only support tls 1.2 ok bcook@ tb@ jsing@
* revert previous, accidentally contained another diff in additionbeck2019-01-231-9/+1
| | | | to the one I intended to commit
* Modify sigalgs extension processing for TLS 1.3.beck2019-01-231-1/+9
| | | | | | | | | - 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@
* copyrightbeck2019-01-181-1/+2
|
* Add client side of supported versions and keyshare extensions with basic regressbeck2019-01-181-1/+15
| | | | ok jsing@
* Rename TLS extension handling to use less "hello".jsing2019-01-181-66/+75
| | | | | | | | | | | | | | | | | | | | | | | 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 header guards and hidden declarations.jsing2018-11-091-1/+10
|
* Rename the TLS Supported Elliptic Curves extension to Supported Groups.jsing2018-11-051-7/+7
| | | | | | | | | 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@
* Complete the TLS extension rewrite on the client-side.jsing2018-02-081-3/+2
| | | | | | | | | | | 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@
* Complete the TLS extension handling rewrite for the server-side.jsing2018-01-271-3/+2
| | | | | | | | | | | | | 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@
* Rewrite SRTP extension using CBB/CBS and the new extension framework.doug2017-08-271-1/+10
| | | | input + ok beck@, jsing@
* Rewrite ALPN extension using CBB/CBS and the new extension framework.doug2017-08-261-1/+8
| | | | | ok bcook@ beck@ input + ok jsing@
* Rewrite the TLS status request extension to use the new TLS extension framework.beck2017-08-121-1/+8
| | | | ok jsing@
* Convert TLS signature algorithms extension handling to the new framework.jsing2017-08-121-1/+8
| | | | ok beck@ doug@
* Rewrite session ticket TLS extension handling using CBB/CBS and the newdoug2017-08-121-1/+7
| | | | | | extension framework. ok jsing@ beck@
* Rewrite EllipticCurves TLS extension handling using CBB/CBS and the newdoug2017-08-111-1/+9
| | | | | | extension framework. input + ok jsing@
* Add doug@'s copyright since he just added code to these two files.jsing2017-08-111-1/+2
|
* Rewrite the ECPointFormats TLS extension handling using CBB/CBS and thedoug2017-08-111-1/+8
| | | | | | new extension framework. input + ok jsing@
* Rewrite the TLS Renegotiation Indication extension handling using CBB/CBSjsing2017-07-241-1/+8
| | | | | | | | and the new extension framework. Feedback from doug@ ok inoguchi@
* Start rewriting TLS extension handling.jsing2017-07-161-0/+31
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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-21 15:26:30 +0000