summaryrefslogtreecommitdiffstats
path: root/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* tls13_record_layer internal functions to static in libsslinoguchi2020-04-291-4/+4
| | | | | | | We might remove static again for further regress around record layer in the future. ok jsing@ tb@
* tls13_handshake internal functions to static in libsslinoguchi2020-04-291-11/+12
| | | | ok jsing@ tb@
* Move legacy stack interfacing functions into tls13_legacy.c.jsing2020-04-284-199/+206
| | | | | | No functional change. ok inoguchi@ tb@
* Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c.jsing2020-04-283-47/+48
| | | | | | | | The server-side will need to use the same function. No functional change. ok inoguchi@ tb@
* Shuffle some functions around.jsing2020-04-272-329/+328
| | | | | | | | | | Move functions so that they are in the order that the TLSv1.3 messages are processed. While here, also move tls13_client_end_of_early_data_send() from tls13_client.c to tls13_server.c. No functional change. ok beck@ tb@
* Disallow the use of zero length IVs in AES-GCM viatb2020-04-273-3/+15
| | | | | | | | | | | EVP_AEAD_CTX_{open,seal}, as this leaks the authentication key. Issue reported and fix tested by Guido Vranken. ok beck, jsing This commit adds a constant to a public header despite library lock, as discussed with deraadt and sthen.
* Minimal maintenance to make this mess slightly less confusing:schwarze2020-04-261-10/+10
| | | | | | | queue -> list; mention "intrusive"; element -> member at one place; delete a bogus remark that maybe referred to a long-gone implementation in VAX assembly code. Much more could be improved, but i don't want to waste too much time here.
* fix the description; from andras farkasjmc2020-04-261-5/+4
| | | | | | ok schwarze kill a Tn while here...
* A comma is not appropriate here, use a semicolonjca2020-04-251-2/+2
| | | | Suggested by Evan Silberman, confirmed by jmc@
* Switch to NEGOTIATED when using WITHOUT_HRR.jsing2020-04-251-4/+9
| | | | | | | | | | This ensures that we remain in a valid handshake state in the TLSv1.3 server. Ideally we would not switch to NEGOTIATED until after record protection has been enabled, but we'll revisit this later. Issue noted by inoguchi@ ok tb@
* Discourage use of RES_USE_INET6jca2020-04-251-1/+5
| | | | Suggested by eric@, input from deraadt@, ok deraadt@ eric@
* Fix RES_USE_INET6 descriptionjca2020-04-251-7/+9
| | | | | | | | | | The previous wording implied this option does nothing, which is wrong. This option does affect the way gethostbyname(3) works on OpenBSD (return IPv6 addresses if available). On some systems, it also introduces IPv4-mapped IPv6 addresses, a "feature" that we don't support. ok deraadt@ eric@
* Move unsupported, obsolete ciphers and deprecated aliases out ofschwarze2020-04-251-31/+29
| | | | | | | | | | | the main list of words to make it more readable, even though it remains long. Avoid using deprecated aliases in explanations what other words mean. Stop documenting aDSS because it is *both* a deprecated alias *and* no longer matches anything at all. General direction discussed with jsing@ some time ago.
* tweak the wording to make it clearer under which conditions exactlyschwarze2020-04-251-4/+4
| | | | | the TLSv1.3 cipher suites are made available, too; related to ssl_ciph.c rev. 1.115
* Clairify the point at which unveil first makes restricitons on thebeck2020-04-251-9/+4
| | | | | | filesystem, and remove the BUGS section, as this was fixed by making realpath() a system call. ok ingo@ deraadt@
* Remove the deprecation notice for timegm().schwarze2020-04-241-4/+57
| | | | | | | | | | | | | | | | | | | | | The tzcode package marked it dprecated in the late 1980ies but it is universally supported and here to stay. Triggered by a question from Rodrigo <hruodr at gmail dot com> on misc@. William Ahern <william at 25thandclement dot com> listed a number of sound arguments why it shouldn't be considered deprecated, in particular that there is no better alternative, in particular none that is thread-safe. While here, fix the non-standard section name "NOTES", add the missing STANDARDS section and provide additional information in the HISTORY section, based on inspection of C89, C11, POSIX 2008, UNIX v4 and v5 at TUHS, Tahoe and Reno at the CSRG archives, amd the SunOS 3.5 and 4.0 manuals on bitsavers. Reasearch on tzcode and SunOS history done by millert@. OK millert@ on an earlier version of this patch, and deraadt@ agrees with the general direction.
* ce examples of "Ar arg Ar arg" with "Ar arg arg" and stop the spread;jmc2020-04-231-4/+4
|
* Improve TLSv1.3 state machine for HelloRetryRequest handling.jsing2020-04-225-66/+104
| | | | | | | | | | | | | | | | | | | The state machine currently handles the HelloRetryRequest case by using WITH_HRR - in other words, we're explicitly indicating when we transition to the alternate path. The problem here is that we do not know if we're going to receive a ServerHello or a HelloRetryRequest until we process the message. This means that the ServerHello processing code has to handle both types of messages. The state machine and associated processing code becomes cleaner if we flip this around so that we assume we are going to receive a HelloRetryRequest and upon discovering that it is not, trigger WITHOUT_HRR and hand off to the ServerHello processing function. In particular, this makes the logic much more straight forward on the server side, when adding support for HRR. With feedback from tb@ ok tb@
* move mixerctl and audioctl man pages to section 8, as these workderaadt2020-04-212-6/+6
| | | | against root-only device nodes.
* Handle TLSv1.3 key shares other than X25519 on the server side.jsing2020-04-212-16/+34
| | | | | | | | Previously we would only select an X25519 key share from the client, ignoring any others. Change this so that we will select the first of the key shares that matches one of our supported groups. ok beck@ inoguchi@ tb@
* Consolidate TLSv1.3 constants.jsing2020-04-213-40/+47
| | | | | | | Move all of the TLSv1.3 constants to the top of tls13_lib.c. Also mark these all as const so that they end up in .rodata rather than .data. ok tb@
* Prevent infinite for loop since i went from ssize_t to size_t. Patch fromdtucker2020-04-211-3/+3
| | | | eagleoflqj via OpenSSH github PR#178, ok djm@, feedback & ok millert@
* Provide TLSv1.3 cipher suite aliases to match the names used in RFC 8446.jsing2020-04-191-2/+25
| | | | ok beck@ inoguchi@ tb@
* spelling fix;jmc2020-04-191-2/+2
|
* Mention SIO_DEVANY instead of nonexistent SIOCTL_DEVANY constantfeinerer2020-04-191-3/+3
| | | | OK ratchov@
* When opening a completely empty file with gzopen(3), treat it as anschwarze2020-04-181-2/+2
| | | | | | | | | | | uncompressed file, such that the first gzread(3) results in Z_STREAM_END rather than in the misleading Z_BUF_ERROR. I checked that none of the many copies of libz in our tree suffer from the same bug, after deraadt@ asked. Bugfix patch from Olivier Taibi <oli at olitb dot net> on bugs@. OK millert@.
* Fix wrapping/indentation.jsing2020-04-181-4/+3
|
* Expose the peer ephemeral public key used for TLSv1.3 key exchange.jsing2020-04-185-36/+79
| | | | | | | | | SSL_get_server_tmp_key() provides the peer ephemeral public key used for key exchange. In the case of TLSv1.3 this is essentially the peer public key from the key share used for TLSv1.3 key exchange, hence make it availaable via SSL_get_server_tmp_key(). ok inoguchi@ tb@
* Tweak previous active cipher suite code.jsing2020-04-181-6/+5
| | | | | | | Use a boolean value rather than using a counter, as suggested by tb@ during the previous review. ok tb@
* Allow more key share groups for TLSv1.3.jsing2020-04-181-21/+12
| | | | | | | | The key share code previously only allowed for key shares to be generated using one of the groups in our default list (X25519, secp256r1, secp384r1). Relax this and allow key shares using any of the groups in our NID list. ok inoguchi@ tb@
* Only include TLSv1.3 cipher suites if there are active cipher suites.jsing2020-04-171-2/+10
| | | | | | | | | | Revise the previous so that we only include TLSv1.3 cipher suites if the cipher rule string resulted in at least one active cipher suite. This more closely matches OpenSSL behaviour. Noted and fix tested by schwarze@ ok beck@ tb@
* Generate client key share using our preferred group.jsing2020-04-174-25/+37
| | | | | | | | Generate a client key share using our preferred group, rather than always using X25519. This means that the key share group can be controlled via SSL{_CTX,}_set1_groups() and SSL{_CTX,}_set1_groups_list(). ok beck@
* Remove AUTHORS section. This follows what is done in strstr.3claudio2020-04-161-4/+2
|
* Replace the simple memmem() implementation with a version that is O(n)claudio2020-04-161-47/+167
| | | | | based on code from musl and now similar to our strstr(). OK tb@ millert@
* Resync our strstr.c with the musl version. Removes some debug code andclaudio2020-04-161-11/+3
| | | | | optimizes one statement in two-way string compare. OK tb@ millert@
* Update in several respects:schwarze2020-04-141-13/+11
| | | | | | | | * mention TLSv1.3 * remove DSS, DES(56), RC4(64), and IDEA(128), which are no longer supported * remove ChaCha20-Poly1305-Old and STREEBOG512 which don't exist in LibreSSL * correct the instruction for printing the complete list OK jsing@
* add the missing sentence "LibreSSL no longer provides any suchschwarze2020-04-141-2/+3
| | | | | cipher suites" to the DES entry and use the same wording for DSS; OK jsing@
* 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
|
* Update ARG_MAX bytes countjca2020-04-101-3/+3
| | | | ok deraadt@
* 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
* 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@
* 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@
* 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@
* Update my email address.pirofti2020-04-0611-29/+29
|
* Make libcxxabi provide __register_frame, _Unwind_Backtrace and friendsjca2020-04-042-2/+2
| | | | | | | | | | on sparc64 Discrepancy spotted in http://build-failures.rhaalovely.net/sparc64/2020-04-03/devel/llvm,,-main.log Input from gkoehler@, ok kettenis@ deraadt@
* Implement __atomic_is_lock_free for powerpc. Needed because thekettenis2020-04-042-2/+25
| | | | | | | | | architecture doesn't implement 64-bit atomic operations. This implementation is pessimistic and only flags naturally aligned operations up to and including 32-bit as lock free. tested by cwen@ ok gkoehler@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.