Mirror of BoringSSL (grpc依赖) https://boringssl.googlesource.com/boringssl
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

411 lines
12 KiB

/* Copyright (c) 2017, Google Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
#include <openssl/ssl.h>
#include <assert.h>
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
#include <algorithm>
#include <openssl/bytestring.h>
#include <openssl/err.h>
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
#include <openssl/span.h>
#include "internal.h"
#include "../crypto/internal.h"
BSSL_NAMESPACE_BEGIN
bool ssl_protocol_version_from_wire(uint16_t *out, uint16_t version) {
switch (version) {
case TLS1_VERSION:
case TLS1_1_VERSION:
case TLS1_2_VERSION:
case TLS1_3_VERSION:
*out = version;
return true;
case DTLS1_VERSION:
// DTLS 1.0 is analogous to TLS 1.1, not TLS 1.0.
*out = TLS1_1_VERSION;
return true;
case DTLS1_2_VERSION:
*out = TLS1_2_VERSION;
return true;
default:
return false;
}
}
// The follow arrays are the supported versions for TLS and DTLS, in order of
// decreasing preference.
static const uint16_t kTLSVersions[] = {
TLS1_3_VERSION,
TLS1_2_VERSION,
TLS1_1_VERSION,
TLS1_VERSION,
};
static const uint16_t kDTLSVersions[] = {
DTLS1_2_VERSION,
DTLS1_VERSION,
};
static Span<const uint16_t> get_method_versions(
const SSL_PROTOCOL_METHOD *method) {
return method->is_dtls ? Span<const uint16_t>(kDTLSVersions)
: Span<const uint16_t>(kTLSVersions);
}
bool ssl_method_supports_version(const SSL_PROTOCOL_METHOD *method,
uint16_t version) {
for (uint16_t supported : get_method_versions(method)) {
if (supported == version) {
return true;
}
}
return false;
}
// The following functions map between API versions and wire versions. The
// public API works on wire versions.
static const char* kUnknownVersion = "unknown";
struct VersionInfo {
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
uint16_t version;
const char *name;
};
static const VersionInfo kVersionNames[] = {
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
{TLS1_3_VERSION, "TLSv1.3"},
{TLS1_2_VERSION, "TLSv1.2"},
{TLS1_1_VERSION, "TLSv1.1"},
{TLS1_VERSION, "TLSv1"},
{DTLS1_VERSION, "DTLSv1"},
{DTLS1_2_VERSION, "DTLSv1.2"},
};
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
static const char *ssl_version_to_string(uint16_t version) {
for (const auto &v : kVersionNames) {
if (v.version == version) {
return v.name;
}
}
return kUnknownVersion;
}
static uint16_t wire_version_to_api(uint16_t version) {
return version;
}
// api_version_to_wire maps |version| to some representative wire version.
static bool api_version_to_wire(uint16_t *out, uint16_t version) {
// Check it is a real protocol version.
uint16_t unused;
if (!ssl_protocol_version_from_wire(&unused, version)) {
return false;
}
*out = version;
return true;
}
static bool set_version_bound(const SSL_PROTOCOL_METHOD *method, uint16_t *out,
uint16_t version) {
if (!api_version_to_wire(&version, version) ||
!ssl_method_supports_version(method, version)) {
OPENSSL_PUT_ERROR(SSL, SSL_R_UNKNOWN_SSL_VERSION);
return false;
}
*out = version;
return true;
}
static bool set_min_version(const SSL_PROTOCOL_METHOD *method, uint16_t *out,
uint16_t version) {
// Zero is interpreted as the default minimum version.
if (version == 0) {
*out = method->is_dtls ? DTLS1_VERSION : TLS1_VERSION;
return true;
}
return set_version_bound(method, out, version);
}
static bool set_max_version(const SSL_PROTOCOL_METHOD *method, uint16_t *out,
uint16_t version) {
// Zero is interpreted as the default maximum version.
if (version == 0) {
*out = method->is_dtls ? DTLS1_2_VERSION : TLS1_3_VERSION;
return true;
}
return set_version_bound(method, out, version);
}
const struct {
uint16_t version;
uint32_t flag;
} kProtocolVersions[] = {
{TLS1_VERSION, SSL_OP_NO_TLSv1},
{TLS1_1_VERSION, SSL_OP_NO_TLSv1_1},
{TLS1_2_VERSION, SSL_OP_NO_TLSv1_2},
{TLS1_3_VERSION, SSL_OP_NO_TLSv1_3},
};
bool ssl_get_version_range(const SSL_HANDSHAKE *hs, uint16_t *out_min_version,
uint16_t *out_max_version) {
// For historical reasons, |SSL_OP_NO_DTLSv1| aliases |SSL_OP_NO_TLSv1|, but
// DTLS 1.0 should be mapped to TLS 1.1.
uint32_t options = hs->ssl->options;
if (SSL_is_dtls(hs->ssl)) {
options &= ~SSL_OP_NO_TLSv1_1;
if (options & SSL_OP_NO_DTLSv1) {
options |= SSL_OP_NO_TLSv1_1;
}
}
uint16_t min_version, max_version;
if (!ssl_protocol_version_from_wire(&min_version,
hs->config->conf_min_version) ||
!ssl_protocol_version_from_wire(&max_version,
hs->config->conf_max_version)) {
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
return false;
}
// QUIC requires TLS 1.3.
if (hs->ssl->quic_method && min_version < TLS1_3_VERSION) {
min_version = TLS1_3_VERSION;
}
// The |SSL_OP_NO_*| flags disable individual protocols. This has two
// problems. First, prior to TLS 1.3, the protocol can only express a
// contiguous range of versions. Second, a library consumer trying to set a
// maximum version cannot disable protocol versions that get added in a future
// version of the library.
//
// To account for both of these, OpenSSL interprets the client-side bitmask
// as a min/max range by picking the lowest contiguous non-empty range of
// enabled protocols. Note that this means it is impossible to set a maximum
// version of the higest supported TLS version in a future-proof way.
bool any_enabled = false;
for (size_t i = 0; i < OPENSSL_ARRAY_SIZE(kProtocolVersions); i++) {
// Only look at the versions already enabled.
if (min_version > kProtocolVersions[i].version) {
continue;
}
if (max_version < kProtocolVersions[i].version) {
break;
}
if (!(options & kProtocolVersions[i].flag)) {
// The minimum version is the first enabled version.
if (!any_enabled) {
any_enabled = true;
min_version = kProtocolVersions[i].version;
}
continue;
}
// If there is a disabled version after the first enabled one, all versions
// after it are implicitly disabled.
if (any_enabled) {
max_version = kProtocolVersions[i-1].version;
break;
}
}
if (!any_enabled) {
OPENSSL_PUT_ERROR(SSL, SSL_R_NO_SUPPORTED_VERSIONS_ENABLED);
return false;
}
*out_min_version = min_version;
*out_max_version = max_version;
return true;
}
static uint16_t ssl_version(const SSL *ssl) {
// In early data, we report the predicted version.
if (SSL_in_early_data(ssl) && !ssl->server) {
return ssl->s3->hs->early_session->ssl_version;
}
return ssl->version;
}
uint16_t ssl_protocol_version(const SSL *ssl) {
assert(ssl->s3->have_version);
uint16_t version;
if (!ssl_protocol_version_from_wire(&version, ssl->version)) {
// |ssl->version| will always be set to a valid version.
assert(0);
return 0;
}
return version;
}
bool ssl_supports_version(const SSL_HANDSHAKE *hs, uint16_t version) {
const SSL *const ssl = hs->ssl;
uint16_t protocol_version;
if (!ssl_method_supports_version(ssl->method, version) ||
!ssl_protocol_version_from_wire(&protocol_version, version) ||
hs->min_version > protocol_version ||
protocol_version > hs->max_version) {
return false;
}
return true;
}
Add most of an ECH client implementation. Based on an initial implementation by Dan McArdle at https://boringssl-review.googlesource.com/c/boringssl/+/46784 This CL contains most of a client implementation for draft-ietf-tls-esni-10. The pieces missing so far, which will be done in follow-up CLs are: 1. While the ClientHelloInner is padded, the server Certificate message is not. I'll add that once we resolve the spec discussions on how to do that. (We were originally going to use TLS record-level padding, but that doesn't work well with QUIC.) 2. The client should check the public name is a valid DNS name before copying it into ClientHelloOuter.server_name. 3. The ClientHelloOuter handshake flow is not yet implemented. This CL can detect when the server selects ClientHelloOuter, but for now the handshake immediately fails. A follow-up CL will remove that logic and instead add the APIs and extra checks needed. Otherwise, this should be complete, including padding and compression. The main interesting point design-wise is that we run through ClientHello construction multiple times. We need to construct ClientHelloInner and ClientHelloOuter. Then each of those has slight variants: EncodedClientHelloInner is the compressed form, and ClientHelloOuterAAD just has the ECH extension erased to avoid a circular dependency. I've computed ClientHelloInner and EncodedClientHelloInner concurrently because the compression scheme requires shifting the extensions around to be contiguous. However, I've computed ClientHelloOuterAAD and ClientHelloOuter by running through the logic twice. This probably can be done better, but the next draft revises the construction anyway, so I'm thinking I'll rework it then. (In the next draft, we use a placeholder payload of the same length, so we can construct the ClientHello once and fill in the payload.) Additionally, now that we have a client available in ssl_test, this adds a threading test to confirm that SSL_CTX_set1_ech_keys is properly synchronized. (Confirmed that, if I drop the lock in SSL_CTX_set1_ech_keys, TSan notices.) Change-Id: Icaff68b595035bdcc73c468ff638e67c84239ef4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48004 Reviewed-by: Adam Langley <agl@google.com>
4 years ago
bool ssl_add_supported_versions(const SSL_HANDSHAKE *hs, CBB *cbb,
uint16_t extra_min_version) {
for (uint16_t version : get_method_versions(hs->ssl->method)) {
Add most of an ECH client implementation. Based on an initial implementation by Dan McArdle at https://boringssl-review.googlesource.com/c/boringssl/+/46784 This CL contains most of a client implementation for draft-ietf-tls-esni-10. The pieces missing so far, which will be done in follow-up CLs are: 1. While the ClientHelloInner is padded, the server Certificate message is not. I'll add that once we resolve the spec discussions on how to do that. (We were originally going to use TLS record-level padding, but that doesn't work well with QUIC.) 2. The client should check the public name is a valid DNS name before copying it into ClientHelloOuter.server_name. 3. The ClientHelloOuter handshake flow is not yet implemented. This CL can detect when the server selects ClientHelloOuter, but for now the handshake immediately fails. A follow-up CL will remove that logic and instead add the APIs and extra checks needed. Otherwise, this should be complete, including padding and compression. The main interesting point design-wise is that we run through ClientHello construction multiple times. We need to construct ClientHelloInner and ClientHelloOuter. Then each of those has slight variants: EncodedClientHelloInner is the compressed form, and ClientHelloOuterAAD just has the ECH extension erased to avoid a circular dependency. I've computed ClientHelloInner and EncodedClientHelloInner concurrently because the compression scheme requires shifting the extensions around to be contiguous. However, I've computed ClientHelloOuterAAD and ClientHelloOuter by running through the logic twice. This probably can be done better, but the next draft revises the construction anyway, so I'm thinking I'll rework it then. (In the next draft, we use a placeholder payload of the same length, so we can construct the ClientHello once and fill in the payload.) Additionally, now that we have a client available in ssl_test, this adds a threading test to confirm that SSL_CTX_set1_ech_keys is properly synchronized. (Confirmed that, if I drop the lock in SSL_CTX_set1_ech_keys, TSan notices.) Change-Id: Icaff68b595035bdcc73c468ff638e67c84239ef4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48004 Reviewed-by: Adam Langley <agl@google.com>
4 years ago
uint16_t protocol_version;
if (ssl_supports_version(hs, version) &&
Add most of an ECH client implementation. Based on an initial implementation by Dan McArdle at https://boringssl-review.googlesource.com/c/boringssl/+/46784 This CL contains most of a client implementation for draft-ietf-tls-esni-10. The pieces missing so far, which will be done in follow-up CLs are: 1. While the ClientHelloInner is padded, the server Certificate message is not. I'll add that once we resolve the spec discussions on how to do that. (We were originally going to use TLS record-level padding, but that doesn't work well with QUIC.) 2. The client should check the public name is a valid DNS name before copying it into ClientHelloOuter.server_name. 3. The ClientHelloOuter handshake flow is not yet implemented. This CL can detect when the server selects ClientHelloOuter, but for now the handshake immediately fails. A follow-up CL will remove that logic and instead add the APIs and extra checks needed. Otherwise, this should be complete, including padding and compression. The main interesting point design-wise is that we run through ClientHello construction multiple times. We need to construct ClientHelloInner and ClientHelloOuter. Then each of those has slight variants: EncodedClientHelloInner is the compressed form, and ClientHelloOuterAAD just has the ECH extension erased to avoid a circular dependency. I've computed ClientHelloInner and EncodedClientHelloInner concurrently because the compression scheme requires shifting the extensions around to be contiguous. However, I've computed ClientHelloOuterAAD and ClientHelloOuter by running through the logic twice. This probably can be done better, but the next draft revises the construction anyway, so I'm thinking I'll rework it then. (In the next draft, we use a placeholder payload of the same length, so we can construct the ClientHello once and fill in the payload.) Additionally, now that we have a client available in ssl_test, this adds a threading test to confirm that SSL_CTX_set1_ech_keys is properly synchronized. (Confirmed that, if I drop the lock in SSL_CTX_set1_ech_keys, TSan notices.) Change-Id: Icaff68b595035bdcc73c468ff638e67c84239ef4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48004 Reviewed-by: Adam Langley <agl@google.com>
4 years ago
ssl_protocol_version_from_wire(&protocol_version, version) &&
protocol_version >= extra_min_version && //
!CBB_add_u16(cbb, version)) {
return false;
}
}
return true;
}
bool ssl_negotiate_version(SSL_HANDSHAKE *hs, uint8_t *out_alert,
uint16_t *out_version, const CBS *peer_versions) {
for (uint16_t version : get_method_versions(hs->ssl->method)) {
if (!ssl_supports_version(hs, version)) {
continue;
}
// JDK 11, prior to 11.0.2, has a buggy TLS 1.3 implementation which fails
// to send SNI when offering 1.3 sessions. Disable TLS 1.3 for such
// clients. We apply this logic here rather than |ssl_supports_version| so
// the downgrade signal continues to query the true capabilities. (The
// workaround is a limitation of the peer's capabilities rather than our
// own.)
//
// See https://bugs.openjdk.java.net/browse/JDK-8211806.
if (version == TLS1_3_VERSION && hs->apply_jdk11_workaround) {
continue;
}
CBS copy = *peer_versions;
while (CBS_len(&copy) != 0) {
uint16_t peer_version;
if (!CBS_get_u16(&copy, &peer_version)) {
OPENSSL_PUT_ERROR(SSL, SSL_R_DECODE_ERROR);
*out_alert = SSL_AD_DECODE_ERROR;
return false;
}
if (peer_version == version) {
*out_version = version;
return true;
}
}
}
OPENSSL_PUT_ERROR(SSL, SSL_R_UNSUPPORTED_PROTOCOL);
*out_alert = SSL_AD_PROTOCOL_VERSION;
return false;
}
BSSL_NAMESPACE_END
using namespace bssl;
int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, uint16_t version) {
return set_min_version(ctx->method, &ctx->conf_min_version, version);
}
int SSL_CTX_set_max_proto_version(SSL_CTX *ctx, uint16_t version) {
return set_max_version(ctx->method, &ctx->conf_max_version, version);
}
uint16_t SSL_CTX_get_min_proto_version(const SSL_CTX *ctx) {
return ctx->conf_min_version;
}
uint16_t SSL_CTX_get_max_proto_version(const SSL_CTX *ctx) {
return ctx->conf_max_version;
}
int SSL_set_min_proto_version(SSL *ssl, uint16_t version) {
if (!ssl->config) {
return 0;
}
return set_min_version(ssl->method, &ssl->config->conf_min_version, version);
}
int SSL_set_max_proto_version(SSL *ssl, uint16_t version) {
if (!ssl->config) {
return 0;
}
return set_max_version(ssl->method, &ssl->config->conf_max_version, version);
}
uint16_t SSL_get_min_proto_version(const SSL *ssl) {
if (!ssl->config) {
return 0;
}
return ssl->config->conf_min_version;
}
uint16_t SSL_get_max_proto_version(const SSL *ssl) {
if (!ssl->config) {
return 0;
}
return ssl->config->conf_max_version;
}
int SSL_version(const SSL *ssl) {
return wire_version_to_api(ssl_version(ssl));
}
const char *SSL_get_version(const SSL *ssl) {
return ssl_version_to_string(ssl_version(ssl));
}
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
size_t SSL_get_all_version_names(const char **out, size_t max_out) {
return GetAllNames(out, max_out, MakeConstSpan(&kUnknownVersion, 1),
&VersionInfo::name, MakeConstSpan(kVersionNames));
Add APIs to query a list of possible strings for TLS features Envoy needs to have the possible cipher, etc., strings predeclared to reduce synchronization needs in the steady state. It currently does this by (1) iterating over SSL_CTX_get_ciphers at SSL_CTX creation time and (2) hard-coding a lists of known TLS 1.3 ciphers, TLS versions, NamedGroups, etc. (1) would work for some applications, but it breaks any applications that configure ciphers on the SSL on a certificate callback, etc. If the callback configures a cipher that wasn't configured on the SSL_CTX (e.g. if the SSL_CTX were left at defaults), Envoy's logging breaks and we hit an ENVOY_BUG assertion. (2) breaks whenever BoringSSL adds a new feature. In principle, we could update Envoy when updating BoringSSL, but this is an unresasonable development overhead for just one of many BoringSSL consumers to impose. Such costs are particularly high when considering needing to coordinate updates to Envoy and BoringSSL across different repositories. Add APIs to enumerate the possible strings these functions can return. These string lists are a superset of those that any one application may care about (e.g. we may have a deprecated cipher that Envoy no longer needs, or an experimental cipher that's not yet ready for Envoy's stability goals), but this is fine provided this is just used to initialize the table. In particular, they are *not* intended to enumerate supported features. Bump BORINGSSL_API_VERSION to aid in patching these into Envoy. Bug: b:280350955 Change-Id: I4d11db980eebed5620d3657778c09dbec004653c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59667 Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2 years ago
}
const char *SSL_SESSION_get_version(const SSL_SESSION *session) {
return ssl_version_to_string(session->ssl_version);
}
uint16_t SSL_SESSION_get_protocol_version(const SSL_SESSION *session) {
return wire_version_to_api(session->ssl_version);
}
int SSL_SESSION_set_protocol_version(SSL_SESSION *session, uint16_t version) {
// This picks a representative TLS 1.3 version, but this API should only be
// used on unit test sessions anyway.
return api_version_to_wire(&session->ssl_version, version);
}
int SSL_CTX_set_record_protocol_version(SSL_CTX *ctx, int version) {
return version == 0;
}