summaryrefslogtreecommitdiff
path: root/src/lib/libssl/tls1.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Provide TLSEXT_TYPE_* aliases for TLS 1.3.jsing2020-01-021-1/+10
| | | | | | | | | | | OpenSSL decided to use their own names for two of the TLS 1.3 extensions, rather than using the names given in the RFC. Provide aliases for these so that code written to work with OpenSSL also works with LibreSSL (otherwise everyone gets to provide their own workarounds). Issue noted by d3x0r on github. ok inoguchi@ tb@
* Revert TLS1_get{,_client}_version simplification because DTLS.jsing2019-03-191-5/+6
|
* Partially clean up the TLS1_get_{,client}_version macros.jsing2019-03-171-6/+5
| | | | | | | | | LibreSSL only supports TLSv1.0 and above, hence the checks the macros are performing are useless. Simplify them to their effective code. Also place both under #ifndef LIBRESSL_INTERNAL and use the variables directly in our code, which improves readability. ok tb@
* Reimplement the sigalgs processing code into a new implementationbeck2018-11-091-24/+1
| | | | | that will be usable with TLS 1.3 with less eye bleed. ok jsing@ tb@
* Add TLSv1.3 cipher suites (with appropriate guards).jsing2018-11-071-2/+19
| | | | ok beck@ tb@
* Add TLS extension type values for TLSv1.3 (under guards).jsing2018-11-061-2/+16
| | | | ok tb@
* Add TLS1_3_VERSION and SSL_OP_NO_TLSv1_3 defines under guards.jsing2018-11-061-1/+7
| | | | ok beck@ bluhm@ tb@
* Rename the TLS Supported Elliptic Curves extension to Supported Groups.jsing2018-11-051-2/+7
| | | | | | | | | RFC 7919 renamed the Supported Elliptic Curves TLS extension to Supported Groups and redefined it to include finite field DH (FFDH) in addition to elliptic curve DH (ECDH). As such, rename the TLS extension and change the associated code to refer to groups rather than curves. ok beck@ tb@
* Provide SSL_CTX_get_tlsext_status_cb() and SSL_CTX_get_tlsext_status_arg().jsing2018-02-171-2/+6
|
* Completely remove NPN remnants.jsing2017-08-281-4/+1
| | | | Based on a diff from doug@, similar diff from inoguchi@
* Remove the original (pre-IETF) chacha20-poly1305 cipher suites.jsing2017-08-281-7/+1
| | | | | | | | | | Support for the IETF standardised chacha20-poly1305 cipher suites was added 16 months ago, which means they exist in both of the currently supported OpenBSD releases. Also prompted by Andreas Bartelt <obsd at bartula dot de>. ok beck@ doug@
* Update RFC reference for TLSEXT_TYPE_padding.jsing2017-03-251-5/+2
|
* Implement the IETF ChaCha20-Poly1305 cipher suites.jsing2016-04-281-4/+10
| | | | | | | | | Rename the existing ChaCha20-Poly1305 cipher suites with an "-OLD" suffix, effectively replaces the original Google implementation. We continue to support both the IETF and Google versions, however the existing names now refer to the ciphers from draft-ietf-tls-chacha20-poly1305-04. Feedback from doug@
* http -> https for IETF/IANA URLs in commentsmmcc2016-03-071-4/+4
|
* Clean up alert codes and add references.jsing2015-06-171-21/+29
|
* Reluctantly add server-side support for TLS_FALLBACK_SCSV.jsing2015-02-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This allows for clients that willingly choose to perform a downgrade and attempt to establish a second connection at a lower protocol after the previous attempt unexpectedly failed, to be notified and have the second connection aborted, if the server does in fact support a higher protocol. TLS has perfectly good version negotiation and client-side fallback is dangerous. Despite this, in order to maintain maximum compatability with broken web servers, most mainstream browsers implement this. Furthermore, TLS_FALLBACK_SCSV only works if both the client and server support it and there is effectively no way to tell if this is the case, unless you control both ends. Unfortunately, various auditors and vulnerability scanners (including certain online assessment websites) consider the presence of a not yet standardised feature to be important for security, even if the clients do not perform client-side downgrade or the server only supports current TLS protocols. Diff is loosely based on OpenSSL with some inspiration from BoringSSL. Discussed with beck@ and miod@. ok bcook@
* unifdef -m -UOPENSSL_NO_NEXTPROTONEG - NPN is being replaced with ALPN,jsing2015-02-121-3/+1
| | | | | | however it is not likely to be removed any time soon. ok beck@ miod@
* Now that we have Camellia support in libcrypto, bring in the SHA256 flavour ofmiod2014-12-161-1/+31
| | | | the Camellia ciphersuites for TLS 1.2 introduced in RFC 5932. From OpenSSL HEAD.
* Update the GOST code in libssl, as contributed by Dmitry Eremin-Solenikov.miod2014-11-181-2/+12
| | | | | This causes a libssl major version bump as this affects the layout of some internal-but-unfortunately-made-visible structs.
* Remove an outdated comment re EDH vs DHE - DHE is now used consistently andjsing2014-10-311-8/+1
| | | | there are backwards compatible names/aliases for EDH.
* Update comments for TLS ExtensionType values - many of the referencedjsing2014-10-311-38/+46
| | | | | drafts are now RFCs. Also add the TLS extension type for ALPN and be consistent with RFC reference formatting.
* Add ChaCha20-Poly1305 based ciphersuites.jsing2014-06-131-2/+11
| | | | | | Based on Adam Langley's chromium patches. Tested by and ok sthen@
* Remove support for the `opaque PRF input' extension, which draft has expiredmiod2014-06-131-8/+1
| | | | | | | | 7 years ago and never made it into an RFC. That code wasn't compiled in anyway unless one would define the actual on-the-wire extension id bytes; crank libssl major. With help and enlightenment from Brendan MacDonell.
* tags as requested by miod and teduderaadt2014-06-121-1/+1
|
* TLS would not be entirely functional without extensions, so unifdefjsing2014-05-311-2/+0
| | | | | | OPENSSL_NO_TLSEXT. ok tedu@
* remove some #if 0 code. we don't need any more reminders that we're usingtedu2014-05-301-7/+0
| | | | a not quite appropriate data structure. ok jsing
* More KNF.jsing2014-04-191-10/+10
|
* Send the rotIBM stream cipher (ebcdic) to Valhalla to party for eternitybeck2014-04-151-19/+0
| | | | | with the bearded ones... some API's that nobody should be using will dissapear with this commit.
* First pass at applying KNF to the OpenSSL code, which almost makes itjsing2014-04-151-8/+7
| | | | | | | readable. This pass is whitespace only and can readily be verified using tr and md5. There is still a huge amount of inconsistency within these headers.
* make OPENSSL_NO_HEARTBLEED the default and only option. ok deraadt miodtedu2014-04-141-10/+0
|
* Merge conflicts; remove MacOS, Netware, OS/2, VMS and Windows build machinery.miod2014-04-131-0/+6
|
* resolve conflictsdjm2012-10-131-3/+206
|
* resolve conflicts, fix local changesdjm2010-10-011-11/+136
|
* resolve conflictsdjm2008-09-061-2/+214
|
* merge openssl-0.9.7-beta3, tested on vax by miod@markus2002-09-101-15/+16
|
* OpenSSL 0.9.7 stable 2002 05 08 mergebeck2002-05-151-0/+30
|
* openssl-engine-0.9.6 mergebeck2000-12-151-0/+11
|
* OpenSSL 0.9.5 mergebeck2000-03-191-3/+3
| | | | | | *warning* this bumps shared lib minors for libssl and libcrypto from 2.1 to 2.2 if you are using the ssl26 packages for ssh and other things to work you will need to get new ones (see ~beck/libsslsnap/<arch>) on cvs or ~beck/src-patent.tar.gz on cvs
* OpenSSL 0.9.4 mergebeck1999-09-291-1/+39
|
* Import of SSLeay-0.9.0b with RSA and IDEA stubbed + OpenBSD buildryker1998-10-051-0/+115
functionality for shared libs. Note that routines such as sslv2_init and friends that use RSA will not work due to lack of RSA in this library. Needs documentation and help from ports for easy upgrade to full functionality where legally possible.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-20 05:07:16 +0000