| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
ok tedu@
|
|
|
|
| |
ok beck@ doug@
|
| |
|
|
|
|
|
|
| |
extension framework.
ok jsing@ beck@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NPN was never standardised and the last draft expired in October 2012.
ALPN was standardised in July 2014 and has been supported in LibreSSL
since December 2014. NPN has also been removed from Chromium in May 2016.
TLS clients and servers that try to use/enable NPN will fail gracefully and
fallback to the default protocol, since it will essentially appear that the
otherside does not support NPN. At some point in the future we will
actually remove the NPN related symbols entirely.
ok bcook@ beck@ doug@
|
|
|
|
|
|
| |
the read accessors we don't have and fixing the prototypes - the
data type of each and every argument differs in the OpenSSL manuals.
Reference the new page from SSL_set_tmp_ecdh(3) as suggested by jsing@.
|
|
|
|
| |
Feedback and OK jsing@.
|
|
|
|
| |
OK jsing.
|
| |
|
| |
|
|
|
|
|
|
| |
back.
ok guenther@
|
|
|
|
|
|
| |
hanging around to potentially invalid address space.
Discussed with beck@ and doug@
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
extension framework.
input + ok jsing@
|
|
|
|
| |
ok beck@ doug@
|
| |
|
| |
|
|
|
|
| |
Prompted by jsg@, since I apparently left it sitting in my tree...
|
|
|
|
|
|
| |
new extension framework.
input + ok jsing@
|
|
|
|
|
|
|
|
|
|
| |
names of the elliptic curves that may be used during client and server
key exchange to be specified.
This deprecates tls_config_set_ecdhecurve(), which could only be used to
specify a single supported curve.
ok beck@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Over the years OpenSSL grew multiple ways of being able to specify EC keys
(and/or curves) for use with ECDH and ECDHE key exchange. You could specify
a static EC key (SSL{_CTX,}_set_tmp_ecdh()), use that as a curve and
generate ephemeral keys (SSL_OP_SINGLE_ECDH_USE), provide the EC key via
a callback that was provided with insufficient information
(SSL{_CTX,}_set_tmp_ecdh_cb()) or enable automatic selection and generation
of EC keys via SSL{_CTX,}_set_ecdh_auto(). This complexity leads to
problems (like ECDHE not being enabled) and potential weird configuration
(like being able to do ECDHE without the ephemeral part...).
We no longer support ECDH and ECDHE can be disabled by removing ECDHE
ciphers from the cipher list. As such, permanently enable automatic EC
curve selection and generation, effectively disabling all of the
configuration knobs. The only exception is the
SSL{_CTX,}_set_tmp_ecdh() functions, which retain part of their previous
behaviour by configuring the curve of the given EC key as the only curve
being enabled. Everything else becomes a no-op.
ok beck@ doug@
|
|
|
|
|
|
|
| |
list or if we are negotiating an ECC cipher in the handshake. This dedups
some of the existing code and will make the EC extension rewrites easier.
ok doug@
|
|
|
|
|
|
|
|
| |
for the TLS privsep code. Instead use X509_pubkey_digest() because only the
key should be used as identifier. Relayd is rewriting certificates and then
the hash would change. Rename the hash is struct tls_keypair to pubkey_hash
to make clear what this hash is about.
With input and OK jsing@
|
|
|
|
| |
breaking from some and returning from others.
|
| |
|
|
|
|
| |
they can eventually be exposed as direct functions/symbols.
|
|
|
|
| |
from some.
|
| |
|
| |
|
|
|
|
| |
eventually be exposed as direct functions/symbols.
|
|
|
|
| |
for readability.
|
| |
|
|
|
|
|
| |
found with regress/usr.bin/mandoc/db/dbm_dump;
OK jmc@
|
|
|
|
| |
from carlos cardenas
|
|
|
|
|
|
| |
tricky, especially since the manpage is full of lies.
Try to make readers think twice before using them.
With oks and help from schwarze@, tedu@, sthen@, jmc@
|
|
|
|
|
|
|
|
| |
tlsext_sni_serverhello_parse(). This also adds a check to ensure that
if we have an existing session, the name matches what we specified via
SNI.
ok doug@
|
|
|
|
|
|
|
|
| |
and the new extension framework.
Feedback from doug@
ok inoguchi@
|
|
|
|
| |
Missed in the original commit.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a TLS extension handling framework that has per-extension type
functions to determine if an extension is needed, to build the extension
data and parse the extension data. This is somewhat analogous to BoringSSL,
however these build and parse functions are intentionally symetrical. The
framework is hooked into the existing TLS handling code in such a way that
we can gradual convert the extension handling code.
Convert the TLS Server Name Indication extension to the new framework,
while rewriting it to use CBB/CBS and be more strict in the process.
Discussed with beck@
ok inoguchi@
|
|
|
|
| |
Reported by <dravion at ht-foss dot net>
|
|
|
|
| |
okay millert@
|
|
|
|
| |
definite value in the size == 0 case
|
|
|
|
| |
what the reader is using.
|
|
|
|
| |
is not initialized. Problem spotted by Carlin Bingham; ok phessler@ tedu@
|