summaryrefslogtreecommitdiff
path: root/src/lib/libssl/Makefile (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Add include path for crypto_arch.h.jsing2024-08-111-1/+2
|
* ssl2.h and ssl23.h join the party in the attictb2024-07-131-2/+2
| | | | | | | Now that the SSL2 client hello support is gone, nothing uses this anymore, except that a few ports still need SSL2_VERSION. ok beck
* Actually enable namespaced builds in both libcrypto and libsslbeck2024-07-091-3/+3
| | | | (instead of commiting only one part)
* Implement RSA key exchange in constant time.jsing2024-06-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | RSA key exchange is known to have multiple security weaknesses, including being potentially susceptible to padding oracle and timing attacks. The RSA key exchange code that we inherited from OpenSSL was riddled with timing leaks, many of which we fixed (or minimised) early on. However, a number of issues still remained, particularly those related to libcrypto's RSA decryption and padding checks. Rework the RSA key exchange code such that we decrypt with RSA_NO_PADDING and then check the padding ourselves in constant time. In this case, the pre-master secret is of a known length, hence the padding is also a known length based on the size of the RSA key. This makes it easy to implement a check that is much safer than having RSA_private_decrypt() depad for us. Regardless, we still strongly recommend disabling RSA key exchange and using other key exchange methods that provide perfect forward secrecy and do not depend on client generated keys. Thanks to Marcel Maehren, Nurullah Erinola, Robert Merget, Juraj Somorovsky, Joerg Schwenk and Hubert Kario for raising these issues with us at various points in time. ok tb@
* Unhook and remove the now even more useless ssl_algs.c than it was before.tb2023-11-221-2/+1
| | | | ok jsing
* unifdef the LIBRESSL_HAS_TLS1_3_[CLIENT|SERVER] goobeck2023-07-061-5/+1
| | | | | And remove the tendrils. This was useful for transition but we are now well past this.
* Use -Wshadow with clangtb2023-05-051-2/+2
| | | | ok jsing (a very long time ago)
* Add support for symbol hiding disabled by default.beck2022-11-111-1/+6
| | | | | | | | | | | | Fully explained in libcrypto/README. TL;DR make sure libcrypto and libssl's function calls internally and to each other are via symbol names that won't get overridden by linking other libraries. Mostly work by guenther@, which will currently be gated behind a build setting NAMESPACE=yes. once we convert all the symbols to this method we will do a major bump and pick up the changes. ok tb@ jsing@
* Deduplicate peer certificate chain processing code.jsing2022-08-171-2/+3
| | | | | | | | | | | | | | Rather than reimplement this in each TLS client and server, deduplicate it into a single function. Furthermore, rather than dealing with the API hazard that is SSL_get_peer_cert_chain() in this code, simply produce two chains - one that has the leaf and one that does not. SSL_get_peer_cert_chain() can then return the appropriate one. This also moves the peer cert chain from the SSL_SESSION to the SSL_HANDSHAKE, which makes more sense since it is not available on resumption. ok tb@
* Provide record layer callbacks for QUIC.jsing2022-07-241-1/+2
| | | | | | | | | | | | QUIC uses TLS to complete the handshake, however unlike normal TLS it does not use the TLS record layer, rather it provides its own transport. This means that we need to intercept all communication between the TLS handshake and the record layer. This allows TLS handshake message writes to be directed to QUIC, likewise for TLS handshake message reads. Alerts also need to be sent via QUIC, plus it needs to be provided with the traffic keys that are derived by TLS. ok tb@
* Implement the default security level callbacktb2022-06-281-1/+2
| | | | | | And here is where the fun starts. The tentacles will grow everywhere. ok beck jsing sthen
* bio_ssl.c needs to peek into bio_local.htb2022-01-141-1/+2
|
* Rename tls13_key_share to tls_key_share.jsing2022-01-051-3/+3
| | | | | | | | | In preparation to use the key share code in both the TLSv1.3 and legacy stacks, rename tls13_key_share to tls_key_share, moving it into the shared handshake struct. Further changes will then allow the legacy stack to make use of the same code for ephemeral key exchange. ok inoguchi@ tb@
* Rename tls13_buffer to tls_buffer.jsing2021-10-231-2/+2
| | | | | | | This code will soon be used in the DTLSv1.2 and TLSv1.2 stack. Also introduce tls_internal.h and move/rename the read/write/flush callbacks. ok beck@ tb@
* Factor out the TLSv1.3 code that handles content from TLS records.jsing2021-09-041-2/+3
| | | | | | | | | | | | Currently, the plaintext content from opened TLS records is handled via the rbuf code in the TLSv1.3 record layer. Factor this out and provide a separate struct tls_content, which knows how to track and manipulate the content. This makes the TLSv1.3 code cleaner, however it will also soon also be used to untangle parts of the legacy record layer. ok beck@ tb@
* Rewrite TLSv1.2 key block handling.jsing2021-05-051-1/+2
| | | | | | | | | | | | | For TLSv1.2 a single key block is generated, then partitioned into individual secrets for use as IVs and keys. The previous implementation splits this across two functions tls1_setup_key_block() and tls1_change_cipher_state(), which means that the IV and key sizes have to be known in multiple places. This implementation generates and partitions the key block in a single step, meaning that the secrets are then simply handed out when requested. ok inoguchi@ tb@
* Clean up derivation of finished/peer finished.jsing2021-04-251-1/+2
| | | | | | | | Make this process more readable by having specific client/server functions, calling the correct one based on s->server. This allows to remove various SSL_ST_ACCEPT/SSL_ST_CONNECT checks, along with duplicate code. ok inoguchi@ tb@
* Merge d1_{clnt,srvr}.c into ssl_{clnt,srvr}.cjsing2020-10-031-3/+1
| | | | | | | The d1_{clnt,srvr}.c contain a single function each - merge these into the ssl_{clnt,srvr}.c, renaming them with an ssl3_ prefix for consistency. ok beck@ tb@
* Start replacing the existing TLSv1.2 record layer.jsing2020-08-301-1/+2
| | | | | | | | | | This takes the same design/approach used in TLSv1.3 and provides an opaque struct that is self contained and cannot reach back into other layers. For now this just implements/replaces the writing of records for DTLSv1/TLSv1.0/TLSv1.1/TLSv1.2. In doing so we stop copying the plaintext into the same buffer that is used to transmit to the wire. ok inoguchi@ tb@
* The check_includes step is incorrect dependency management model forderaadt2020-06-091-11/+1
| | | | | | how our tree gets built. If this was done in all the libraries (imagine sys/dev), it would disrupt the development process hugely. So it should not be done here either. use 'make includes' by hand instead.
* Provide an easy way to get debug information from TLSv1.3 handshakes.jsing2020-05-101-1/+4
| | | | | | This makes it easier to debug TLSv1.3 handshake failures. "Yes please!" tb@, ok beck@
* Remove dtls1_enc().jsing2020-03-131-2/+1
| | | | | | | | | | | | | 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@
* Move the TLSv1.3 code that interfaces with the legacy APIs/stack into ajsing2020-02-151-1/+2
| | | | | | separate file. Discussed with beck@ and tb@
* Provide struct/functions for handling TLSv1.3 key shares.jsing2020-01-301-1/+2
| | | | | | | Pull out the key share handling code and provide a clean/self contained interface. This will make it easier to support groups other than X25519. ok beck@ inoguchi@ tb@
* Factor out/rewrite the ECDHE EC point key exchange code.jsing2020-01-301-1/+2
| | | | | | | | | This reduces replication between the existing TLS client/server and allows the code to soon be reused for TLSv1.3. With feedback from inoguchi@ and tb@ ok inoguchi@ tb@
* Add checks to ensure that lib{crypto,ssl,tls} public headers have actuallyjsing2020-01-221-1/+11
| | | | | | been installed prior to building. Requested by and ok tb@
* Split the TLSv1.3 guards into separate client and server guards.jsing2020-01-221-2/+3
| | | | ok beck@ tb@
* Provide an error framework for use with the TLSv1.3 code.jsing2020-01-201-1/+2
| | | | | | | This is based on the libtls error handling code, but adds machine readable codes and subcodes. We then map these codes back to libssl error codes. ok beck@ inoguchi@
* Add the initial framework for the TLSv1.3 server.jsing2019-11-171-2/+3
| | | | ok beck@
* Rename the file that contains the transcript handling code.jsing2019-02-091-2/+2
| | | | ok inoguchi@ tb@
* Make it easier to build with LIBRESSL_HAS_TLS1_3 enabled.jsing2019-02-041-1/+4
| | | | ok tb@
* No need to include <bsd.prog.mk> here.tb2019-01-231-2/+1
| | | | ok bcook
* Provide the initial TLSv1.3 client implementation.jsing2019-01-211-1/+2
| | | | | | | | | Move tls13_connect() to a new tls13_client.c file and provide a legacy wrapper to it, which allocates a struct tls_ctx if necessary. Also move tls13_client_hello_send() to tls13_client.c and actual implement the building of a client hello. ok tb@
* Add ssl_cipher_is_permitted(), an internal helper function thattb2019-01-211-1/+2
| | | | | | | will be used in a few places shortly, e.g. in ssl_cipher_list_to_bytes(). ok jsing
* Provide TLS 1.3 cipher AEAD/hash and legacy I/O handling functions.jsing2019-01-211-1/+2
| | | | | | | | | Provide functionality for determining AEADs and hashes for TLS 1.3 ciphers. Also provide wire read/write callbacks that interface with BIO and functions that interface between SSL_read/SSL_write and the TLS 1.3 record layer API. ok tb@
* Provide a handshake message handling implementation for TLS 1.3.jsing2019-01-201-1/+2
| | | | | | | | It receives handshake messages by reading and parsing data from the record layer. It also provides support for building and sending handshake messages. ok tb@
* Provide an initial implementation of the TLS 1.3 record layer.jsing2019-01-201-3/+3
| | | | | | | | | | | This is entirely self-contained and knows nothing about SSL or BIO. The bottom of the stack is provided by wire read and write callbacks, with the API to the record layer primarily being via tls13_{read,write}_{application,handshake}_data(). This currently lacks some functionality, however will be worked on in tree. ok tb@
* Sort HDRS/SRCS lists and use one line per source file for maintainability.jsing2019-01-191-16/+44
| | | | ok tb@
* Provide a TLS record handling implementation.jsing2019-01-191-2/+2
| | | | | | | | | | This is a self-contained struct and set of functions that knows how to decode and read a TLS record from data supplied via a read callback, and send itself via a write callback. This will soon be used to build the TLSv1.3 record layer handling code. ok beck@ tb@
* Remove this copy, we have decided we can do this in placebeck2019-01-181-2/+2
| | | | ok jsing@
* Provide an extensible buffer implementation that uses a read callback.jsing2019-01-171-2/+3
| | | | | | | | | | | | The read callback returns a TLS13_IO_* value on EOF, failure, want pollin or want pollout, or a positive value indicating the number of bytes read. This will be used by upcoming TLSv1.3 handshake message and record processing code, both of which need the ability to read a fixed size header, before extending the buffer to the number of bytes specified in the header. ok beck@ tb@
* Add a direct copy of the exension parsing code to be modified for tls13.beck2019-01-171-2/+2
| | | | | | At the moment this is mechanical, with the functions renamed. This will be refactored for tls13. ok jsing@
* Reimplement the sigalgs processing code into a new implementationbeck2018-11-091-2/+2
| | | | | that will be usable with TLS 1.3 with less eye bleed. ok jsing@ tb@
* First skeleton of the TLS 1.3 state machine. Based on RFC 8446 andtb2018-11-081-2/+2
| | | | | | inspired by s2n's state machine. Lots of help and input from jsing. ok beck, jsing
* Add initial TLS 1.3 key schedule support with basic regress testsbeck2018-11-071-2/+3
| | | | ok jsing@ tb@
* Consolidate all of the SSL method structs/functions into a single file.jsing2018-11-051-4/+4
| | | | Discussed with tb@
* Bring in compatibility for OpenSSL 1.1 style init functions.beck2018-03-171-2/+2
| | | | | | | | | This adds OPENSSL_init_crypto and OPENSSL_init_ssl, as well thread safety modifications for the existing LibreSSL init functions. The initialization routines are called automatically by the normal entry points into the library, as in newer OpenSSL ok jsing@, nits by tb@ and deraadt@
* Switch to -Werror with clang for libressl.doug2017-08-131-2/+2
| | | | | Discussed with beck@ and jsing@ ok beck@
* Rewrite the TLS Renegotiation Indication extension handling using CBB/CBSjsing2017-07-241-2/+2
| | | | | | | | and the new extension framework. Feedback from doug@ ok inoguchi@
* Start rewriting TLS extension handling.jsing2017-07-161-2/+2
| | | | | | | | | | | | | | | | 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-08-26 22:00:36 +0000