summaryrefslogtreecommitdiff
path: root/src/lib/libssl (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove static from handshakes[][] so it is visible from regress/tb2019-01-231-2/+2
| | | | ok bcook
* No need to include <bsd.prog.mk> here.tb2019-01-231-2/+1
| | | | ok bcook
* bump minors after symbol additiontb2019-01-221-1/+1
|
* Document SSL_get1_supported_ciphers(3) and SSL_get_client_ciphers(3).tb2019-01-221-7/+61
| | | | | | | The text comes from OpenSSL, where it was still published under a free license. from schwarze
* Add a re-implementation of SSL_get1_supported_ciphers().tb2019-01-223-2/+38
| | | | | | | Part of OpenSSL 1.1 API (pre-licence-change). input schwarze ok jsing
* Provide SSL_get_client_ciphers().tb2019-01-223-2/+12
| | | | | | Part of OpenSSL 1.1 API, pre-licence change. ok jsing
* Use the actual handshake message type in the certificate request handler.jsing2019-01-211-4/+2
|
* Move ssl_cipher_list_to_bytes() and ssl_bytes_to_cipher_list() totb2019-01-212-116/+120
| | | | | | | a more appropriately licenced file. jsing and doug have rewritten these functions (including the comments) over the past years. ok jsing
* Provide the initial TLSv1.3 client implementation.jsing2019-01-215-25/+192
| | | | | | | | | 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@
* Wire up the handshake message send and recv actions.jsing2019-01-212-4/+44
| | | | | | | This means that we actually receive and send handshake messages to and from the record layer. ok tb@
* In ssl_lib.c rev. 1.197, jsing@ added TLSv1.3 support to SSL_get_version(3).schwarze2019-01-211-2/+4
| | | | Document it.
* The main handshake loop can be shared between client and server.jsing2019-01-212-29/+15
| | | | | | | Pull the shared code up into a function and call it from tls13_connect() and tls13_accept() instead of duplicating it. "Yes, please!" tb@
* Use ssl_cipher_is_permitted() in ssl_cipher_list_to_bytes().tb2019-01-211-9/+6
| | | | ok jsing
* Add ssl_cipher_is_permitted(), an internal helper function thattb2019-01-213-2/+49
| | | | | | | will be used in a few places shortly, e.g. in ssl_cipher_list_to_bytes(). ok jsing
* Correct some rwstate handling that I broke when refactoring.jsing2019-01-211-3/+13
|
* Provide TLS 1.3 cipher AEAD/hash and legacy I/O handling functions.jsing2019-01-213-2/+210
| | | | | | | | | 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@
* Move struct tls13_ctx into a header since other things need access to it.jsing2019-01-213-21/+21
| | | | | | | | While here, rename struct handshake to struct handshake_stage to avoid potential ambiguity/conflict with the handshake data struct. Also add forward and back pointers between SSL and struct tls13_ctx. ok tb@
* Ensure we free TLS 1.3 handshake state.jsing2019-01-211-6/+11
| | | | | | | | There is no guarantee that ssl3_clear() is called before ssl3_free(), so free things here. Also move the chunk in ssl3_clear() up so that it is with the "free" code rather than the "reinit" code. ok beck@ tb@
* Teach ssl_version_string() about TLS1_3_VERSION.jsing2019-01-211-1/+3
|
* Store the record version and make it available for use.jsing2019-01-212-10/+21
| | | | | | While here correct an int vs size_t mismatch. ok tb@
* Fix header guardtb2019-01-201-2/+5
|
* Provide a handshake message handling implementation for TLS 1.3.jsing2019-01-203-3/+213
| | | | | | | | 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-203-6/+790
| | | | | | | | | | | 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@
* Provide a way to get just the record header.jsing2019-01-202-7/+33
| | | | | | Also check record size limits when reading records and setting data. ok tb@
* revert second hunk of previous that was committed by accidenttb2019-01-201-2/+2
|
* Add missing prototype for tls13_handshake_active_action().tb2019-01-201-2/+4
| | | | ok jsing
* Add some internal consistency checks to the handshake state handling.jsing2019-01-201-9/+23
| | | | | | | | Fix the tls13_handshake_advance_state_machine() return value, which inadvertantly got flipped in an earlier commit. Also move this function to a more suitable location. ok 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@
* Add an explicit flag to indicate a successful handshake insteadtb2019-01-201-8/+6
| | | | | | of overloading/abusing action->sender. ok jsing
* Sort HDRS/SRCS lists and use one line per source file for maintainability.jsing2019-01-191-16/+44
| | | | ok tb@
* Add handshake message type checking and special case certificate requests.jsing2019-01-191-1/+30
| | | | | | | | | | | | | | Check that the handshake message type received matches that required by the state machine. However, thanks to poor state design in the TLSv1.3 RFC, there is no way to know if you're going to receive a certificate request message or not, hence we have to special case it and teach the receive handler how to handle this situation. Discussed at length with beck@ and tb@ during the hackathon. ok tb@
* Tweak return value handling in the TLSv1.3 handshake code.jsing2019-01-192-44/+47
| | | | | | | | | | | | | The I/O paths are from the tls13_handshake_send_action() and tls13_handshake_recv_action() functions - both of these need to propagate I/O conditions (EOF, failure, want poll in, want poll out) up the stack, so we need to capture and return values <= 0. Use an I/O condition to indicate successful handshake completion. Also, the various send/recv functions are currently unimplemented, so return 0 (failure) rather than 1 (success). ok tb@
* Provide a TLS record handling implementation.jsing2019-01-193-2/+220
| | | | | | | | | | 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@
* bump minors after symbol additiontb2019-01-191-1/+1
|
* copyrightbeck2019-01-181-1/+2
|
* bump copyright years appopriatelybeck2019-01-181-3/+3
|
* Add client side of supported versions and keyshare extensions with basic regressbeck2019-01-184-4/+262
| | | | ok jsing@
* Expose some symbols in a new tls13_handshake.h for regression testing.tb2019-01-183-99/+93
| | | | | | | | Update the handshake state tables and flag names according to the design decisions and naming conventions in the hackroom. Garbage collect some things that turn out not to belong here. ok jsing
* Remove this copy, we have decided we can do this in placebeck2019-01-183-1633/+2
| | | | 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-184-220/+228
| | | | | | | | | | | | | | | | | | | | | | | 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@
* Get rid of is_serverhello in preparation for other messagesbeck2019-01-171-13/+24
| | | | ok jsing@ tb@
* Provide an extensible buffer implementation that uses a read callback.jsing2019-01-173-3/+148
| | | | | | | | | | | | 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 support to enforce restrictions on where extensions can appearbeck2019-01-172-12/+38
| | | | | | as per RFC8446 section 4.2. Recognized extensions that appear in an incorrect message must abort the handshake. ok jsing@
* Add a direct copy of the exension parsing code to be modified for tls13.beck2019-01-173-2/+1596
| | | | | | At the moment this is mechanical, with the functions renamed. This will be refactored for tls13. ok jsing@
* Remove an ugly hack in the client certificate verification code that workstb2018-12-071-48/+44
| | | | | | | | | | around broken GOST implementations. It looks like client certificates with GOST have been completely broken since reimport of the GOST code, so no-one is using LibreSSL this way. The client side was fixed only last week for TLSv1.0 and TLSv1.1. This workaround is now in the way of much needed simplifcation and cleanup, so it is time for it to go. suggested by and ok jsing
* Send SSL_AD_DECODE alerts in the case of a bad hello request or antb2018-12-031-7/+7
| | | | | | | invalid change cipher spec. Found due to dead assignment warnings by the Clang static analyzer. ok inoguchi (previous version), jsing
* Refactor a tangle in ssl3_send_client_verify() into one function for eachtb2018-11-291-118/+213
| | | | | | | | | | type, sigalgs/rsa/ec/gost. Move a few special dances for GOST where they belong now. This prompted a fix for a long-standing bug with GOST client certificate authentication where tls1_transcript_data() fails since the transcript was already freed before. Add a bit of missing error checking and leave some further cleanup for later. idea, guidance & ok jsing
* Fix DTLS transcript handling for HelloVerifyRequest.jsing2018-11-214-18/+26
| | | | | | | | | | | | | If DTLS sees a HelloVerifyRequest the transcript is reset - the previous tls1_init_finished_mac() function could be called multiple times and would discard any existing state. The replacement tls1_transcript_init() is more strict and fails if a transcript already exists. Provide an explicit tls1_transcript_reset() function and call it from the appropriate places. This also lets us make DTLS less of a special snowflake and call tls1_transcript_init() in the same place as used for TLS. ok beck@ tb@
* Revert previous - DTLSv1 uses MD5+SHA1 for RSA signature verification.jsing2018-11-192-10/+4
| | | | Discussed with beck@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-22 00:21:38 +0000