summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Modify sigalgs extension processing for TLS 1.3.beck2019-01-231-22/+326
| | | | | | | | | - 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@
* TLS 1.3 clients always need to send the supported groups extension.jsing2019-01-201-4/+5
| | | | | | A couple of cleanup/style tweaks while here. ok tb@
* bump copyright years appopriatelybeck2019-01-181-3/+3
|
* Add client side of supported versions and keyshare extensions with basic regressbeck2019-01-181-1/+222
| | | | ok jsing@
* Add support for RFC 8446 section 4.2 enforcing which extensions maybeck2019-01-181-8/+43
| | | | | appear with which messages. ok jsing@
* Rename TLS extension handling to use less "hello".jsing2019-01-181-148/+147
| | | | | | | | | | | | | | | | | | | | | | | 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 the ability to have a separate priority list for sigalgs.beck2018-11-091-2/+2
| | | | | Add a priority list for tls 1.2 ok jsing@
* Reimplement the sigalgs processing code into a new implementationbeck2018-11-091-6/+5
| | | | | that will be usable with TLS 1.3 with less eye bleed. ok jsing@ tb@
* Rename the TLS Supported Elliptic Curves extension to Supported Groups.jsing2018-11-051-39/+38
| | | | | | | | | 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@
* Rework the TLS extension handling code to improve readability/flexibility,jsing2018-11-051-89/+112
| | | | | | by moving the needs/build/parse functions into their own struct. ok beck@ tb@
* If we fail to decode an EC point format extension, send a decode_errorjsing2018-05-121-4/+6
| | | | | | | | alert rather than an internal_error alert. Issue found by Simon Friedberger, Robert Merget and Juraj Somorovsky. ok beck@ inoguchi@
* Complete the TLS extension rewrite on the client-side.jsing2018-02-081-69/+72
| | | | | | | | | | | 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-13/+69
| | | | | | | | | | | | | 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@
* Clarify the comment re the F5 EC curves extension bug.jsing2018-01-271-5/+6
| | | | Also reference the knowledge base article instead of a discussion thread.
* Correct TLS extensions handling when no extensions are present.jsing2017-11-281-1/+13
| | | | | | | | 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@
* Fix various issues in the OCSP extension parsing code:jsing2017-09-251-20/+14
| | | | | | | | | | | | | | | | | | - 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@
* When building the OCSP extension, only add the length prefixed extensionsjsing2017-09-251-6/+6
| | | | | | | after we finish building the responder ID list. Otherwise adding to the responder ID list fails. ok beck@
* Move the full extension building into tlsext_{client,server}hello_build(),jsing2017-08-301-13/+17
| | | | | | leaving ssl_add_{client,server}hello_tlsext() as pointer to CBB wrappers. ok doug@
* When OCSP status type is unknown, ignore the extension.doug2017-08-291-1/+6
| | | | | | | This needs to skip past the CBS data or it will be treated as a decode error even though it returns 1. ok jsing@
* Actually parse the ALPN extension in a client hello, even if no ALPNjsing2017-08-291-4/+4
| | | | | | | | 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@
* Rewrite SRTP extension using CBB/CBS and the new extension framework.doug2017-08-271-1/+223
| | | | input + ok beck@, jsing@
* Rewrite ALPN extension using CBB/CBS and the new extension framework.doug2017-08-261-1/+148
| | | | | ok bcook@ beck@ input + ok jsing@
* Work around bug in F5's handling of the supported elliptic curves extension.doug2017-08-231-2/+16
| | | | | | | | | | 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@
* Rewrite the TLS status request extension to use the new TLS extension framework.beck2017-08-121-3/+168
| | | | ok jsing@
* Convert TLS signature algorithms extension handling to the new framework.jsing2017-08-121-1/+68
| | | | ok beck@ doug@
* Rewrite session ticket TLS extension handling using CBB/CBS and the newdoug2017-08-121-1/+135
| | | | | | extension framework. ok jsing@ beck@
* Rewrite EllipticCurves TLS extension handling using CBB/CBS and the newdoug2017-08-111-1/+120
| | | | | | 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/+107
| | | | | | new extension framework. input + ok jsing@
* Rewrite and move the last remnants of the ServerHello SNI handling intojsing2017-07-241-1/+23
| | | | | | | | 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@
* Rewrite the TLS Renegotiation Indication extension handling using CBB/CBSjsing2017-07-241-1/+142
| | | | | | | | and the new extension framework. Feedback from doug@ ok inoguchi@
* Start rewriting TLS extension handling.jsing2017-07-161-0/+261
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@