summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix .Xr order. From mandoc -Tlint.tb2021-06-262-7/+7
|
* Garbage collect prototoype for ssl_parse_serverhello_tlsext() whichtb2021-06-231-3/+1
| | | | was removed in t1_lib.c r1.141.
* zap wonky commas;jmc2021-06-221-5/+5
|
* Clarify tls_config_set_*_file() file I/O semanticskn2021-06-221-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
* Add GnuTLS interoperability test in appstest.shinoguchi2021-06-211-1/+109
|
* zap trailing whitespacetb2021-06-191-4/+7
|
* Correctly handle epoch wrapping in dtls1_get_bitmap().jsing2021-06-192-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@
* Add DTLS test cases that use non-zero initial epochs.jsing2021-06-192-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.
* Provide the ability to set the initial DTLS epoch value.jsing2021-06-194-7/+29
| | | | | | This allows for regress to test edge cases for epoch handling. ok tb@
* Initialise the epoch for the DTLS processed and unprocessed queues.jsing2021-06-191-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@
* Add more complex DTLS tests for delay/reordering.jsing2021-06-191-17/+160
| | | | | These tests exercise the various queues and delayed processing that exists in the DTLS code.
* Expand comment that details why two DTLS tests currently fail.jsing2021-06-191-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.
* Provide the ability to delay/reorder DTLS packets.jsing2021-06-191-14/+147
| | | | | Add a test that delays the client CCS, resulting in it arriving after the client Finished message.
* Remove SSL_CTX_set_read_ahead() calls - it is now the default for DTLS.jsing2021-06-181-3/+1
|
* Like ARM, RISC-V does not implement floating point exceptions.kettenis2021-06-173-6/+6
|
* Mop up part of dtls1_dispatch_alert().jsing2021-06-151-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@
* Simplify nonce handling in the TLSv1.2 record layer.jsing2021-06-141-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@
* Remove TLS1_AD_INTERNAL_ERROR from internal visibility againtb2021-06-141-3/+1
| | | | With tls_server.c r1.47 this is no longer needed.
* Use SSL_AD_INTERNAL_ERRORtb2021-06-141-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.
* ugly hack around broken build until people wake up.deraadt2021-06-141-1/+3
|
* Add SSL_AD_MISSING_EXTENSION.jsing2021-06-132-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@
* Define SSL_AD_* as actual values.jsing2021-06-133-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@
* Remove tls1_alert_code().jsing2021-06-133-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@
* Place obsolete alerts under #ifndef LIBRESSL_INTERNAL.jsing2021-06-131-4/+7
| | | | ok tb@
* Remove references to obsolete alerts.jsing2021-06-132-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@
* space between macro args and punctuation;jmc2021-06-122-13/+13
|
* RFC 4507bis can refer to various RFCs but this instance is abouttb2021-06-121-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
* space between RFC and number;jmc2021-06-117-29/+29
|
* Only use SSL_AD_* internally.jsing2021-06-113-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@
* add AES-GCM constants from RFC 7714 for SRTPlandry2021-06-113-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@
* sync cert.pem with Mozilla's CA list generated from certdata.txtsthen2021-06-111-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).
* SSL3_AD_ILLEGAL_PARAMETER is not a valid SSLerror() reason code.jsing2021-06-111-2/+2
| | | | | | Use SSL_R_SSLV3_ALERT_ILLEGAL_PARAMETER instead. ok tb@
* Indent all labels with a single space.jsing2021-06-1111-44/+44
| | | | | | This ensures that diff reports the correct function prototype. Prompted by tb@
* Enable libexecinfo regress.mortimer2021-06-091-1/+4
|
* Simplify tlsext_ecpf_parse()tb2021-06-081-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
* Rewrap a comment to avoid an overlong linetb2021-06-081-3/+3
|
* Ignore the record version for early alertstb2021-06-081-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
* TLSv1.3 server: avoid sending alerts in legacy recordstb2021-06-081-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
* Adjust alert for ECPF without uncompressed point formattb2021-06-081-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
* Fix pkg-config .pc files with LibreSSLinoguchi2021-06-082-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@
* Update RFC reference. RFC 4366 was obsoleted by RFC 6066.tb2021-06-011-2/+2
|
* Avoid sending a trailing dot in SNI as a clienttb2021-06-011-6/+19
| | | | | | | | | | | | | While an FQDN includes a trailing dot for the zero-length label of the root, SNI explicitly does not contain it. Contrary to other TLS implementations, our tlsext_sni_is_valid_hostname() rejects a trailing dot. The result is that LibreSSL TLS servers encountering an SNI with trailing dot abort the connection with an illegal_parameter alert. This fixes an issue reported by danj in nc(1) and by sthen in ftp(1). DNS cluebat from florian. ok jsing
* Remove unnecessary cast in free.tb2021-06-011-2/+2
| | | | ok jsing
* Since our unix receive queue got longer, the test run-t_sendrecvbluhm2021-05-311-24/+30
| | | | | | | did not terminate anymore on some machines. The test counts 100 send errors before it finishes. NetBSD has added sched_yield() in the receiver loop to trigger the errors on the sender side. Although not perfect, it works for me. Get current t_sendrecv.c from NetBSD.
* EVP_Digest*: fix documented return values.tb2021-05-202-10/+6
| | | | | | | | | | EVP_DigestSign{,Init,Update,Final}() and EVP_DigestVerify{Init,Update}() always returned 1 for success and 0 for failure. EVP_DigestVerify() and EVP_DigestVerifyFinal() can return -1 or -2, though. Based on OpenSSL 1.1.1 56c59ddd99da05c2f30832cccaffb873a8481555 ok inoguchi
* Adjust libcrypto obj_xref.txt to obj_xref.hinoguchi2021-05-191-2/+2
| | | | | | | | | | | | To generate current obj_xref.h, third item of lines id_tc26_signwithdigest_gost3410_2012_256/512 should be id_GostR3410_2001. obj_xref.txt r1.2 and obj_xref.h r1.3 were committed at the same time, and these third item were coded different value each other. This adjusts obj_xref.txt to current obj_xref.h. ok tb@
* Absorb SSL_AEAD_CTX into struct tls12_record_protection.jsing2021-05-163-73/+63
| | | | | | | | The information contained in SSL_AEAD_CTX really belongs in the tls12_record_protection struct. Absorb SSL_AEAD_CTX, using more appropriate types in the process. ok tb@
* Zero the tls12_record_protection struct instead of individual fields.jsing2021-05-161-9/+3
| | | | | | | | In tls12_record_protection_clear(), rather than zeroing or NULLing individual fields once a pointer has been freed, zero the entire struct once the pointers have been dealt with. ok tb@
* Avoid including tls13_internal.h in tls13_record.h.jsing2021-05-161-2/+1
| | | | | While the implementation needs tls13_internal.h, consumers of tls13_record.h should not.
* Avoid pulling ssl_locl.h into self-contained code.jsing2021-05-164-8/+4
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 05:05:02 +0000