summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Delete the three sentences listing the ciphers currently includedschwarze2020-04-141-15/+2
| | | | | | | | | in LOW, MEDIUM, and HIGH. That's going to change repeatedly and the extra maintenance effort for keeping it up to date is a waste because people can trivially run "openssl ciphers -v LOW" to look it up. Besides, updating it will usually be forgotten; the LOW entry was already wrong. Suggested by jsing@.
* Document the TLSv1.3 control word, update the description of theschwarze2020-04-111-4/+30
| | | | | | | TLSv1 control word, and explain how TLSv1.3 cipher suites can be configured in LibreSSL and in OpenSSL. While here, also mention how users can inspect the DEFAULT list of cipher suites. Stimulus, feedback and OK from jsing@.
* sync cert.pem with Mozilla's root ca list, ok beck@sthen2020-04-101-276/+343
|
* When printing the serialNumber, fall back to the colon separated hextb2020-04-101-2/+4
| | | | | | | | | bytes in case ASN1_INTEGER_get() failed. This happens more often since asn1/a_int.c -r1.34. Matches OpenSSL behavior. Issue in openssl x509 -text output reported by sthen ok jsing sthen
* Revise test to handle the fact that TLSv1.3 cipher suites are now beingjsing2020-04-091-2/+4
| | | | included in the output from `openssl ciphers`.
* Include TLSv1.3 cipher suites unless cipher string references TLSv1.3.jsing2020-04-091-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL has always taken the approach of enabling almost everything by default. As a result, if you wanted to run a secure TLS client/server you had to specify your own "secure" cipher string, rather than being able to trust the defaults as being sensible and secure. The problem is that with the introduction of TLSv1.3, most of these "secure" cipher strings result in the new TLSv1.3 cipher suites being excluded. The "work around" for this issue in OpenSSL was to add a new TLSv1.3 API (SSL_CTX_set_ciphersuites(), SSL_set_ciphersuites()) and have separate knobs for the pre-TLSv1.3 and TLSv1.3 cipher suites. This of course means that every application now needs to call two APIs, but it does mean that applications that only call SSL_CTX_set_cipher_list()/SSL_set_cipher_list() cannot remove TLSv1.3 cipher suites and prevent TLSv1.3 from working. We've taken a different approach and have allowed TLSv1.3 cipher suites to be manipulated via the existing SSL_set_cipher_list() API. However, in order to avoid problems with hardcoded cipher strings, change this behaviour so that we always include TLSv1.3 cipher suites unless the cipher string has a specific reference to the TLSv1.3 protocol or a TLSv1.3 cipher suite. This means that: $ openssl ciphers -v TLSv1.2:!TLSv1.3 still gives TLSv1.2 only cipher suites and: $ openssl ciphers -v AEAD-CHACHA20-POLY1305-SHA256 only lists a single TLSv1.3 cipher, however: $ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 now includes both TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 and all TLSv1.3 cipher suites (which also matches OpenSSL's openssl(1) behaviour). Issue encountered by kn@ with mumble. ok tb@
* Test both SSLv3 (aka pre-TLSv1.2) and TLSv1.2 cipher suites with TLS.jsing2020-04-091-1/+1
|
* Tidy line wrapping and remove an extra blank line.jsing2020-04-091-4/+3
|
* ssl_aes_is_accelerated() returns a boolean - treat it as such, rather thanjsing2020-04-091-2/+2
| | | | explicitly comparing against a value.
* Ensure legacy session ID is persistent during client TLS session.jsing2020-04-081-9/+14
| | | | | | | | | | | | Generate an unpredictable 32-byte legacy session ID during client initialisation, rather than when the ClientHello message is being created. Otherwise in the case of a HelloRetryRequest the legacy session ID values will differ between the first and second ClientHello messages, which is not permitted by the RFC. Fixes an issue talking TLSv1.3 to smtp.mail.yahoo.com. ok beck@
* Re-enable the client test now that it passes again.jsing2020-04-061-2/+2
|
* Minor code improvements.jsing2020-04-061-3/+3
|
* Add tests that cover TLSv1.2 and disable those that trigger TLSv1.3.jsing2020-04-061-3/+32
| | | | This allows the test to pass again.
* Zero the client random field in the TLSv1.2 golden value.jsing2020-04-061-5/+5
|
* Improve comparision with test data.jsing2020-04-061-7/+9
| | | | | | First check the client random against the zeroed value, then zero the client random in the client hello, before comparing with the golden value. This makes failures more obvious and the test code more readable.
* Dump the test data when the lengths differ in order to aid debugging.jsing2020-04-061-0/+3
|
* Use errx() if we fail to build the client hello.jsing2020-04-061-1/+1
|
* Send a zero-length session identifier if TLSv1.3 is not enabled.jsing2020-04-061-4/+7
| | | | | | | | | If the maximum version is less than TLSv1.3, send a zero-length session identifier (matching the behaviour of the legacy TLS stack), rather than a 32 byte random identifier. The 32 byte random identifier is only needed for "compatibility" mode in TLSv1.3. ok beck@
* "eventually" came and went back in 2004.libressl-v3.1.0martijn2020-03-301-3/+1
| | | | OK schwarze@
* Void functions obviously do not return values; no need to elaborate.schwarze2020-03-305-31/+10
| | | | Patch from Martin Vahlensieck <academicsolutions dot ch>.
* Void functions obviously do not return values; no need to elaborate.schwarze2020-03-295-28/+10
| | | | Patch from Martin Vahlensieck <academicsolutions dot ch>.
* Be concise: do not say that void functions return no values, that's obvious.schwarze2020-03-283-22/+6
| | | | Useless text reported by Martin Vahlensieck (academicsolutions.ch) on tech@.
* Fix ASN1 print functionsinoguchi2020-03-241-6/+13
| | | | | | | | | | | | Check and print out boolean type properly. Based on OpenSSL commit ad72d9fdf7709ddb97a58d7d45d755e6e0504b96. Reduced unneeded parentheses from if condition. Check return value from i2s_ASN1_INTEGER. Based on OpenSSL commit 5e3553c2de9a365479324b8ba8b998f0cce3e527. Added if condition expression and return 0 if NULL is returned. ok tb@
* Add a test program for getopt(3) that is adequate for manual testingschwarze2020-03-234-2/+174
| | | | | | | | and a compact test suite for getopt(3) intended automated regression testing, both written from scratch. The suite is intended to provide full coverage, except that it doesn't test manual changes of optind and optreset and except that it so far avoids the situation where we have a known bug.
* Consistently spell 'unsigned' as 'unsigned int', as style(9) seemstb2020-03-167-44/+45
| | | | | | | | | to prefer that. No binary change except in d1_srtp.c where the generated assembly differs only in line numbers (due to a wrapped long line) and in s3_cbc.c where there is no change in the generated assembly. ok inoguchi jsing
* Adapt to tls13_record_layer.c r1.30 (the sequence number shouldn't wrap).tb2020-03-161-2/+2
|
* The RFC is clear (section 5.3) that sequence number should never wrap.tb2020-03-161-5/+12
| | | | | | | | | We currently throw an error on overflow, but still wrap. Check up front if we would need to wrap and only increment if that case is excluded. This simplifies the increment loop and makes the returns in this function less magic. ok jsing
* Increment a few more sequence numbers where the carry is close totb2020-03-131-1/+41
| | | | crossing a byte boundary.
* Remove dtls1_enc().jsing2020-03-135-222/+11
| | | | | | | | | | | | | Like much of the original DTLS code, dtls1_enc() is effectively a renamed copy of tls1_enc(). Since then tls1_enc() has been modified, however the non-AEAD code remains largely the same. As such, remove dtls1_enc() and instead call tls1_enc() from the DTLS code. The tls1_enc() AEAD code does not currently work correctly with DTLS, however this is a non-issue since we do not support AEAD cipher suites with DTLS currently. ok tb@
* Add regress for TLSv1.3 sequence number handling.jsing2020-03-133-1/+135
|
* Correct TLSv1.3 sequence number increment and wrapping check.jsing2020-03-131-3/+3
| | | | Fix proposed by tb@
* Add missing $OpenBSD$ tag.jsing2020-03-131-0/+1
|
* Add regress for CBB_add_space().jsing2020-03-131-1/+41
|
* Ensure that CBB_add_space() always provides zeroed memory.jsing2020-03-131-1/+2
| | | | ok tb@
* Use calloc() rather than malloc() when allocating initial CBB buffer.jsing2020-03-121-4/+3
| | | | | | | | | | CBB uses recallocarray() to expand buffers, however was still using malloc() for the initial buffer, which could result in memory being leaked in incorrect use cases. While here also use calloc() to allocate internal structs. ok inoguchi@ tb@
* Use calloc() rather than malloc() when allocating buffers.jsing2020-03-121-3/+3
| | | | | | This reduces the chance of accidently leaking stack memory. ok inoguchi@ tb@
* Stop overloading the record type for padding length.jsing2020-03-125-13/+10
| | | | | | | | Currently the CBC related code stuffs the padding length in the upper bits of the type field... stop doing that and add a padding_length field to the record struct instead. ok inoguchi@ tb@
* Use internal versions of SSL3_BUFFER, SSL3_RECORD and DTLS1_RECORD_DATA.jsing2020-03-129-53/+83
| | | | | | | | | SSL3_BUFFER, SSL3_RECORD and DTLS1_RECORD_DATA are currently still in public headers, even though their usage is internal. This moves to using _INTERNAL suffixed versions that are in internal headers, which then allows us to change them without any potential public API fallout. ok inoguchi@ tb@
* Use ctx->hs->secrets rather than the S3I(s) version.jsing2020-03-102-4/+4
| | | | ok inoguchi@ tb@
* Update to follow handshake enum removal.jsing2020-03-101-7/+1
|
* Remove some unnecessary handshake enums/functions.jsing2020-03-104-26/+4
| | | | | | | Both session tickets and key updates are post-handshake handshake messages, which were originally included in the handshake code. ok inoguchi@ tb@
* Add a return value check to tls13_buffer_extend().jsing2020-03-101-1/+4
| | | | | | | | | In the unlikely event that the return value from the read callback is larger than the number of bytes we asked for, we can end up incrementing buf->len beyond capacity. Check the return value from the read callback to prevent this. ok inoguchi@ tb@
* Remove the enc function pointers.jsing2020-03-106-22/+12
| | | | | | | The enc function pointers do not serve any purpose these days - remove a layer of indirection and call dtls1_enc()/tls1_enc() directly. ok inoguchi@ tb@
* Import openssl-1.1.1d test data to base64test.cinoguchi2020-03-101-1/+97
| | | | ok bcook@ tb@
* Modify regress base64test.cinoguchi2020-03-101-11/+14
| | | | | | | | | | | | | | | | | | | | | | | - Don't remove multi line CR/LF from bt->out when NL mode base64_encoding_test removes CR/LF from bt->out to compare with the encoding result. This is fine with NO NL mode, but it goes wrong with NL mode if encoding result is larger than 64 and multi line, like below. "eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4\neHh4eHh4eHh4eHh4\n" - Use memcpy instead of asprintf to avoid lost '\0' at the end of data This test data loses trailing '\0' if using asprintf. "\x61\x47\x56\x73\x62\x47\x38\x3d\x0a\x00" - Print original data if decoding result comparison fails This change is not for importing test data, but I just notice. It prints bt->out if fail to memcmp bt->in with decoding result. ok bcook@ tb@
* cstyle in illumos noticed some weird syntax, which this fixes.dlg2020-03-091-4/+4
| | | | | | | | | | | | | | | | | | | some errx lines in if statements were terminated with commas, which caused the following statement to be considered part of the error handling. while it is bad style, ingo points out it was also a bug which which caused some tests in the code to be skipped. this reminds me of a haiku that Chris Pascoe (cpascoe@) had behind his desk: Also, that comma Should be a semi-colon. Cherry blossoms fall. this was found by Robert Mustacchi when porting the tests to illumos. ok schwarze@ stsp@ thank you robert.
* RFC 8446, section 4.1.3: If a TLSv1.2 client receives a ServerHello fortb2020-03-061-1/+27
| | | | | | | | TLSv1.1 or below, it should check whether the server's random value contains the magic downgrade protection cookie and in that case abort the handshake with an illegal parameter alert. ok inoguchi, jsing
* TLSv1.3 servers that intend to downgrade are required to set the lasttb2020-03-061-4/+8
| | | | | | | | | | | | | eight bytes of the server's random to a magic cookie (RFC 8446, 4.1.3). The TLSv1.3 spec changes the TLSv1.2 spec in that it recommends that TLSv1.2 servers that negotiate TLSv1.1 or below do the same. This gives a limited additional protection against downgrade attacks beyond what is already present in the Finished exchange. The TLSv1.3 part was already implemented in Hobart and can be trivially modified to do the TLSv1.2 bit as well. ok inoguchi, jsing
* Check high bit for base64 decodeinoguchi2020-03-041-2/+10
| | | | | | | Referred to this OpenSSL commit and adopted to the codebase. b785504a10310cb2872270eb409b70971be5e76e suggest and ok tb@
* Fix base64 processing of long linesinoguchi2020-03-031-99/+66
| | | | | | | | | | Fix the problem that long unbroken line of base64 text is not decoded. Referred to this OpenSSL commit and adapted to the codebase. 3cdd1e94b1d71f2ce3002738f9506da91fe2af45 Reported by john.a.passaro <at> gmail.com to the LibreSSL ML. ok tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-16 21:58:12 +0000