summaryrefslogtreecommitdiff
path: root/src/lib/libc/stdlib/malloc.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2021-06-27Tidy some comments and simplify some code.jsing1-15/+7
ok tb@
2021-06-27Keep sigalg initialiser order consistent - key type, then hash.jsing2-20/+20
This matches the order that sigalgs are specified in. ok tb@
2021-06-27Add test coverage for TLSv1.3 client hellos.jsing1-13/+166
This is a little bit clunky due to the number of things that vary (largely thanks to middlebox compatibility mode, along with the versions and key share extensions), however it works and can be improved at a later date.
2021-06-27Add test coverage for DTLSv1.2 client hellos.jsing1-7/+102
2021-06-27Improve test coverage for SSL_OP_NO_DTLSv1.jsing1-1/+9
2021-06-27Correct handling of SSL_OP_NO_DTLSv1.jsing1-3/+3
When converting to TLS flags, we need to also include SSL_OP_NO_TLSv1, otherwise the TLS equivalent of SSL_OP_NO_DTLSv1 is TLSv1.0 only, which does not work so well when we try to switch back to DTLS versions.
2021-06-27Teach hexdump() how to identify differing bytes.jsing1-9/+13
This allows differences between the received data and the test data to be more readily identified.
2021-06-27More appropriately set cipher_list_len when AES acceleration is available.jsing1-5/+6
2021-06-27Tweak some data types and sprinkle some const.jsing1-15/+15
2021-06-26Fix .Xr order. From mandoc -Tlint.tb2-7/+7
2021-06-23Garbage collect prototoype for ssl_parse_serverhello_tlsext() whichtb1-3/+1
was removed in t1_lib.c r1.141.
2021-06-22zap wonky commas;jmc1-5/+5
2021-06-22Clarify tls_config_set_*_file() file I/O semanticskn1-13/+11
tls_config_set_*_file(3) do not just set the file paths like tls_config_set_*_path(3) do, they do load the given file(s) into memory directly using tls_config_load_file(). This distinction is important because it means a later tls_connect(3) will not do any file I/O (at least wrt. those files), which is relevant when for example pleding without "[rwc]path" after loading files into memory and before doing tls_connect(3). The manual's current wording made me use the following due to above way of pledging a program: tls_load_file() tls_config_set_ca_mem() tls_unload_file() While in fact a single tls_config_set_ca_file() call does the same. tls_config.c r1.26 (Aug 2016) change the code but forgot to amend the manual as noted by tb, thanks. Feedback OK tb
2021-06-21Add GnuTLS interoperability test in appstest.shinoguchi1-1/+109
2021-06-19zap trailing whitespacetb1-4/+7
2021-06-19Correctly handle epoch wrapping in dtls1_get_bitmap().jsing2-4/+5
Due to a type bug that has been present in DTLS since the code was first committed in 2005, dtls1_get_bitmap() fails to handle next epoch correctly when the epoch is currently 0xffff (and wraps to zero). For various reasons unknown, the epoch field in the SSL3_RECORD_INTERNAL (formerly SSL3_RECORD) was added as unsigned long (even though the value is an unsigned 16 bit value on the wire, hence cannot exceed 0xffff), however was added to other code as unsigned short. Due to integer promotion, the r_epoch value is incremented by one to become 0x10000, before being cast to an unsigned long and compared to the value pulled from the DTLS record header (which is zero). Strangely 0x10000 != 0, meaning that we drop the DTLS record, instead of queueing it for the next epoch. Fix this issue by using more appropriate types and pulling up the calculation of the next epoch value for improved readability. ok inoguchi@ tb@
2021-06-19Add DTLS test cases that use non-zero initial epochs.jsing2-5/+44
In particular, test handling of 0xfffe and 0xffff - the latter results in wrapping to zero for the next epoch. One of these tests triggers a known bug in libssl, which will be fixed following this commit.
2021-06-19Provide the ability to set the initial DTLS epoch value.jsing4-7/+29
This allows for regress to test edge cases for epoch handling. ok tb@
2021-06-19Initialise the epoch for the DTLS processed and unprocessed queues.jsing1-1/+4
Currently these only get correctly initialised when dtls1_process_buffered_records() is called - while this works it is more accidental than intentional. ok tb@
2021-06-19Add more complex DTLS tests for delay/reordering.jsing1-17/+160
These tests exercise the various queues and delayed processing that exists in the DTLS code.
2021-06-19Expand comment that details why two DTLS tests currently fail.jsing1-2/+5
Two tests currently fail (and are disabled) due to a flaw in the DTLSv1.0 specification - this flaw was addressed in DTLSv1.2, however our DTLS server code still needs to support the fix. Quoting RFC 6347 section 4.2.4: "This requirement applies to DTLS 1.0 as well, and though not explicit in [DTLS1], it was always required for the state machine to function correctly." In otherwords, both the original DTLS implementation and the DTLSv1.0 specification have a broken state machine, resulting in possible dead lock.
2021-06-19Provide the ability to delay/reorder DTLS packets.jsing1-14/+147
Add a test that delays the client CCS, resulting in it arriving after the client Finished message.
2021-06-18Remove SSL_CTX_set_read_ahead() calls - it is now the default for DTLS.jsing1-3/+1
2021-06-17Like ARM, RISC-V does not implement floating point exceptions.kettenis3-6/+6
2021-06-15Mop up part of dtls1_dispatch_alert().jsing1-9/+2
The original DTLS code had some strange alert handling code (basically one type of alert included extra data) - a few years later this was "fixed", however the rest of the code was left as is. This means that rather than sending the alert data from send_alert (like ssl3_dispatch_alert() does), we have a local buffer on the stack, which we memset, copy the send_alert bytes into, then send from. ok inoguchi@ tb@
2021-06-14Simplify nonce handling in the TLSv1.2 record layer.jsing1-13/+16
Pass the CBS for the sequence number through, which also allows us to do more sensible length checks. Also, add a missing length check while here. ok inoguchi@ tb@
2021-06-14Remove TLS1_AD_INTERNAL_ERROR from internal visibility againtb1-3/+1
With tls_server.c r1.47 this is no longer needed.
2021-06-14Use SSL_AD_INTERNAL_ERRORtb1-2/+2
One instance of TLS1_AD_* was missed and broke the tree in the recent switch to using only one version of alert defines internally.
2021-06-14ugly hack around broken build until people wake up.deraadt1-1/+3
2021-06-13Add SSL_AD_MISSING_EXTENSION.jsing2-2/+9
This is an alert that was added in TLSv1.3 - we already use it internally, but did not provide the SSL_AD_* define previously. ok tb@
2021-06-13Define SSL_AD_* as actual values.jsing3-42/+49
Rather than having SSL_AD_* as defines that refer to SSL3_AD_* or TLS1_AD_*, just give them actual values directly since it is more readable and the indirection provides no value. Place SSL3_AD_* and TLS1_AD_* under #ifndef LIBRESSL_INTERNAL to prevent further usage. ok tb@
2021-06-13Remove tls1_alert_code().jsing3-73/+3
After running the preprocessor, this function becomes: switch (code) { case 0: return (0); case 10: return (10); case 20: return (20); ... } Its intended purpose was to prevent SSLv3 alerts being sent from TLS code, however now that we've removed "no_certificate" from LibreSSL's reach, it no longer does anything useful. ok tb@
2021-06-13Place obsolete alerts under #ifndef LIBRESSL_INTERNAL.jsing1-4/+7
ok tb@
2021-06-13Remove references to obsolete alerts.jsing2-26/+2
The "no_certificate" alert only existed in SSLv3, while the "decryption_failed" and "export_restriction" alerts were removed in TLSv1.1. ok tb@
2021-06-12space between macro args and punctuation;jmc2-13/+13
2021-06-12RFC 4507bis can refer to various RFCs but this instance is abouttb1-4/+5
RFC 5077. Note that session resumption via session tickets is only for TLSv1.2 and earlier. prompted by a question by/ok jmc
2021-06-11space between RFC and number;jmc7-29/+29
2021-06-11Only use SSL_AD_* internally.jsing3-88/+88
Due to hysterical raisins there are three different types of defines for alerts. SSL3_AD_* are from SSLv3, TLS1_AD_* are from TLSv1.0 onwards and SSL_AD_* currently map to either an SSL3_AD_* or TLS1_AD_* define. Currently, all three of these are used in various places - switch to using just SSL_AD_* values internally, as a first step in cleaning this up. ok tb@
2021-06-11add AES-GCM constants from RFC 7714 for SRTPlandry3-4/+20
SRTP_AEAD_AES_128_GCM/SRTP_AEAD_AES_256_GCM can be used as DTLS-SRTP protection profiles - seen with an update of telephony/baresip i'm working on. adapted from openssl commit 43e5faa2539ae8aae6ef55be2239b9b1a77fea45 ok tb@ jsing@
2021-06-11sync cert.pem with Mozilla's CA list generated from certdata.txtsthen1-476/+163
(certificates with the "server auth" trust purpose permitted). ok tb@ -AC Camerfirma S.A. - /C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008 - /C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Global Chambersign Root - 2008 - FNMT-RCM /C=ES/O=FNMT-RCM/OU=AC RAIZ FNMT-RCM + /C=ES/O=FNMT-RCM/OU=Ceres/2.5.4.97=VATES-Q2826004J/CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS -GeoTrust Inc. - /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA - /C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2 - GlobalSign nv-sa + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root E46 + /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Root R46 /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA Staat der Nederlanden /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden EV Root CA - /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G3 Unizeto Technologies S.A. /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA + /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA 2 - -VeriSign, Inc. - /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority (Note, "Staat der Nederlanden Root CA - G3" was changed to email trust only, so is removed from this due to it only listing "server auth" purposes).
2021-06-11SSL3_AD_ILLEGAL_PARAMETER is not a valid SSLerror() reason code.jsing1-2/+2
Use SSL_R_SSLV3_ALERT_ILLEGAL_PARAMETER instead. ok tb@
2021-06-11Indent all labels with a single space.jsing11-44/+44
This ensures that diff reports the correct function prototype. Prompted by tb@
2021-06-09Enable libexecinfo regress.mortimer1-1/+4
2021-06-08Simplify tlsext_ecpf_parse()tb1-8/+4
The default alert in the tlsext parsing code is a decode_error, so there's no need for an error path that only sets that alert. suggested by/ok jsing
2021-06-08Rewrap a comment to avoid an overlong linetb1-3/+3
2021-06-08Ignore the record version for early alertstb1-4/+10
On receiving the first flight from the peer, we do not yet know if we are using TLSv1.3. In particular, we might get an alert record with record version 0x0300 from a pre-TLSv1.2 peer in response to our client hello. Ignore the record version instead of sending a protocol version alert in that situtation. This may also be hit when talking to a LibreSSL 3.3 server with an illegal SNI. Part of an issue reported by danj. ok jsing
2021-06-08TLSv1.3 server: avoid sending alerts in legacy recordstb1-3/+4
As soon as we know that we're dealing with a TLSv1.3 client, set the legacy version in the record layer to 0x0303 so that we send alerts with the correct record version. Previously we would send early alerts with a record version of 0x0300. ok jsing
2021-06-08Adjust alert for ECPF without uncompressed point formattb1-3/+4
According to RFC 8422, we must send an illegal_parameter alert on receiving an ECPF extension that doesn't include the uncompressed format, not a decode_error. Reported via GitHub issue #675. ok jsing
2021-06-08Fix pkg-config .pc files with LibreSSLinoguchi2-9/+7
In libssl.pc, Libs: should not have '-lcrypto', and Requires.private: should have it as 'libcrypto'. openssl.pc does not need Libs: and Cflags:, but should have Requires:. OK millert@
2021-06-01Update RFC reference. RFC 4366 was obsoleted by RFC 6066.tb1-2/+2
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-19 09:43:47 +0000