Age | Commit message (Collapse) | Author |
|
|
|
And here goes a bunch of unused macros that just had to be in two
headers so they could get out of sync. Three of these constants
are used in a single function...
ok jsing
|
|
Also move the prototypes to the correct header.
Oversight reported by Frank Lichtenheld, thanks!
Fixes https://github.com/libressl/openbsd/issues/147
ok jsing
|
|
This version of GOST is old and not anywhere close to compliant with
modern GOST standards. It is also very intrusive in libssl and
makes a mess everywhere. Efforts to entice a suitably minded anyone
to care about it have been unsuccessful.
At this point it is probably best to remove this, and if someone
ever showed up who truly needed a working version, it should be
a clean implementation from scratch, and have it use something
closer to the typical API in libcrypto so it would integrate less
painfully here.
This removes it from libssl in preparation for it's removal from
libcrypto with a future major bump
ok tb@
|
|
Use the correct value for TLSEXT_TYPE_quic_transport_parameters according
to RFC 9001 section 8.2. Also move the define under LIBRESSL_HAS_QUIC to
avoid things finding it prematurely.
ok beck@ tb@
|
|
We do not intend to make this a compile-time option.
Reminded by schwarze who asked about it
ok jsing
|
|
ok jsing
|
|
This is the start of adding the boringssl API for QUIC support,
and the TLS extensions necessary to send and receive QUIC transport
data.
Inspired by boringssl's https://boringssl-review.googlesource.com/24464
ok jsing@ tb@
|
|
ok beck jsing sthen
|
|
OpenSSL chose to break the previous naming convention for ciphers and
to adopt TLS_* "RFC" names instead. Unfortunately, these names are
exposed in several APIs and some language bindings test for these
non-standard names instead of cipher values, which is ... unfortunate
(others would say "plain crazy").
We currently have to maintain patches in regress and ports (p5-Net-SSLeay,
openssl-ruby-tests - which means that Ruby will pick this up at some point)
to work around this difference and that's just not worth the effort.
The old AEAD- names will become aliases and continue to work, but in
openssl ciphers and netcat output the TLS_* names will now be displayed.
"I would be very happy if this gets committed" bluhm
ok beck inoguchi, begrudgingly ok jsing
|
|
These were already under LIBRESSL_INTERNAL hence no ABI change.
ok tb@
|
|
ok beck jsing
|
|
ok jsing
|
|
from public visibility.
with/ok jsing
|
|
Needed for nginx-lua to build with opaque SSL.
ok inoguchi jsing
|
|
With tls_server.c r1.47 this is no longer needed.
|
|
|
|
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@
|
|
These are no longer used (and should not be used) internally.
|
|
IANA has allocated numbers for GOST ClientCertificateType. Use them in
addition to private values (left in place for compatibility).
Diff from Dmitry Baryshkov <dbaryshkov@gmail.com>
Sponsored by ROSA Linux
ok inoguchi@ tb@
|
|
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@
|
|
|
|
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@
|
|
that will be usable with TLS 1.3 with less eye bleed.
ok jsing@ tb@
|
|
ok beck@ tb@
|
|
ok tb@
|
|
ok beck@ bluhm@ tb@
|
|
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@
|
|
|
|
Based on a diff from doug@, similar diff from inoguchi@
|
|
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@
|
|
|
|
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@
|
|
|
|
|
|
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@
|
|
however it is not likely to be removed any time soon.
ok beck@ miod@
|
|
the Camellia ciphersuites for TLS 1.2 introduced in RFC 5932. From OpenSSL HEAD.
|
|
This causes a libssl major version bump as this affects the layout of some
internal-but-unfortunately-made-visible structs.
|
|
there are backwards compatible names/aliases for EDH.
|
|
drafts are now RFCs. Also add the TLS extension type for ALPN and be
consistent with RFC reference formatting.
|
|
Based on Adam Langley's chromium patches.
Tested by and ok sthen@
|
|
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.
|
|
|
|
OPENSSL_NO_TLSEXT.
ok tedu@
|
|
a not quite appropriate data structure. ok jsing
|
|
|
|
with the bearded ones...
some API's that nobody should be using will dissapear with this commit.
|
|
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.
|
|
|