summaryrefslogtreecommitdiff
path: root/src/lib/libssl/ssl_tlsext.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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@