2014-06-20 20:00:00 +01:00
|
|
|
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This package is an SSL implementation written
|
|
|
|
* by Eric Young (eay@cryptsoft.com).
|
|
|
|
* The implementation was written so as to conform with Netscapes SSL.
|
|
|
|
*
|
|
|
|
* This library is free for commercial and non-commercial use as long as
|
|
|
|
* the following conditions are aheared to. The following conditions
|
|
|
|
* apply to all code found in this distribution, be it the RC4, RSA,
|
|
|
|
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
|
|
|
|
* included with this distribution is covered by the same copyright terms
|
|
|
|
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
|
|
|
|
*
|
|
|
|
* Copyright remains Eric Young's, and as such any Copyright notices in
|
|
|
|
* the code are not to be removed.
|
|
|
|
* If this package is used in a product, Eric Young should be given attribution
|
|
|
|
* as the author of the parts of the library used.
|
|
|
|
* This can be in the form of a textual message at program startup or
|
|
|
|
* in documentation (online or textual) provided with the package.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* "This product includes cryptographic software written by
|
|
|
|
* Eric Young (eay@cryptsoft.com)"
|
|
|
|
* The word 'cryptographic' can be left out if the rouines from the library
|
|
|
|
* being used are not cryptographic related :-).
|
|
|
|
* 4. If you include any Windows specific code (or a derivative thereof) from
|
|
|
|
* the apps directory (application code) you must include an acknowledgement:
|
|
|
|
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* The licence and distribution terms for any publically available version or
|
|
|
|
* derivative of this code cannot be changed. i.e. this code cannot simply be
|
|
|
|
* copied and put under another distribution licence
|
|
|
|
* [including the GNU Public Licence.] */
|
|
|
|
|
2015-09-04 20:05:05 +01:00
|
|
|
#include <openssl/ssl.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2017-06-17 18:20:59 +01:00
|
|
|
#include <assert.h>
|
2015-11-12 17:25:30 +00:00
|
|
|
#include <limits.h>
|
|
|
|
|
2016-07-09 02:52:12 +01:00
|
|
|
#include <openssl/ec.h>
|
|
|
|
#include <openssl/ec_key.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
|
2015-04-08 03:38:30 +01:00
|
|
|
#include "internal.h"
|
2017-03-30 22:37:54 +01:00
|
|
|
#include "../crypto/internal.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2015-09-04 20:05:05 +01:00
|
|
|
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
namespace bssl {
|
|
|
|
|
2017-02-01 20:40:31 +00:00
|
|
|
int ssl_is_key_type_supported(int key_type) {
|
2017-03-28 21:38:29 +01:00
|
|
|
return key_type == EVP_PKEY_RSA || key_type == EVP_PKEY_EC ||
|
|
|
|
key_type == EVP_PKEY_ED25519;
|
2015-07-05 16:54:09 +01:00
|
|
|
}
|
|
|
|
|
2017-02-01 20:40:31 +00:00
|
|
|
static int ssl_set_pkey(CERT *cert, EVP_PKEY *pkey) {
|
|
|
|
if (!ssl_is_key_type_supported(pkey->type)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_UNKNOWN_CERTIFICATE_TYPE);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-12 21:11:15 +01:00
|
|
|
if (cert->chain != nullptr &&
|
|
|
|
sk_CRYPTO_BUFFER_value(cert->chain.get(), 0) != nullptr &&
|
2017-08-29 21:33:21 +01:00
|
|
|
// Sanity-check that the private key and the certificate match.
|
2017-02-01 20:40:31 +00:00
|
|
|
!ssl_cert_check_private_key(cert, pkey)) {
|
2014-12-19 01:42:32 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-29 22:46:42 +01:00
|
|
|
cert->privatekey = UpRef(pkey);
|
2017-02-01 20:40:31 +00:00
|
|
|
return 1;
|
2014-12-19 01:42:32 +00:00
|
|
|
}
|
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
typedef struct {
|
|
|
|
uint16_t sigalg;
|
|
|
|
int pkey_type;
|
|
|
|
int curve;
|
|
|
|
const EVP_MD *(*digest_func)(void);
|
|
|
|
char is_rsa_pss;
|
|
|
|
} SSL_SIGNATURE_ALGORITHM;
|
|
|
|
|
|
|
|
static const SSL_SIGNATURE_ALGORITHM kSignatureAlgorithms[] = {
|
|
|
|
{SSL_SIGN_RSA_PKCS1_MD5_SHA1, EVP_PKEY_RSA, NID_undef, &EVP_md5_sha1, 0},
|
|
|
|
{SSL_SIGN_RSA_PKCS1_SHA1, EVP_PKEY_RSA, NID_undef, &EVP_sha1, 0},
|
|
|
|
{SSL_SIGN_RSA_PKCS1_SHA256, EVP_PKEY_RSA, NID_undef, &EVP_sha256, 0},
|
|
|
|
{SSL_SIGN_RSA_PKCS1_SHA384, EVP_PKEY_RSA, NID_undef, &EVP_sha384, 0},
|
|
|
|
{SSL_SIGN_RSA_PKCS1_SHA512, EVP_PKEY_RSA, NID_undef, &EVP_sha512, 0},
|
|
|
|
|
2018-04-13 21:01:02 +01:00
|
|
|
{SSL_SIGN_RSA_PSS_RSAE_SHA256, EVP_PKEY_RSA, NID_undef, &EVP_sha256, 1},
|
|
|
|
{SSL_SIGN_RSA_PSS_RSAE_SHA384, EVP_PKEY_RSA, NID_undef, &EVP_sha384, 1},
|
|
|
|
{SSL_SIGN_RSA_PSS_RSAE_SHA512, EVP_PKEY_RSA, NID_undef, &EVP_sha512, 1},
|
2017-03-30 22:37:54 +01:00
|
|
|
|
|
|
|
{SSL_SIGN_ECDSA_SHA1, EVP_PKEY_EC, NID_undef, &EVP_sha1, 0},
|
|
|
|
{SSL_SIGN_ECDSA_SECP256R1_SHA256, EVP_PKEY_EC, NID_X9_62_prime256v1,
|
|
|
|
&EVP_sha256, 0},
|
|
|
|
{SSL_SIGN_ECDSA_SECP384R1_SHA384, EVP_PKEY_EC, NID_secp384r1, &EVP_sha384,
|
|
|
|
0},
|
|
|
|
{SSL_SIGN_ECDSA_SECP521R1_SHA512, EVP_PKEY_EC, NID_secp521r1, &EVP_sha512,
|
|
|
|
0},
|
2017-03-28 21:38:29 +01:00
|
|
|
|
|
|
|
{SSL_SIGN_ED25519, EVP_PKEY_ED25519, NID_undef, NULL, 0},
|
2017-03-30 22:37:54 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static const SSL_SIGNATURE_ALGORITHM *get_signature_algorithm(uint16_t sigalg) {
|
|
|
|
for (size_t i = 0; i < OPENSSL_ARRAY_SIZE(kSignatureAlgorithms); i++) {
|
|
|
|
if (kSignatureAlgorithms[i].sigalg == sigalg) {
|
|
|
|
return &kSignatureAlgorithms[i];
|
|
|
|
}
|
2016-07-08 23:07:02 +01:00
|
|
|
}
|
2017-03-30 22:37:54 +01:00
|
|
|
return NULL;
|
2016-07-08 23:42:16 +01:00
|
|
|
}
|
2016-07-08 23:07:02 +01:00
|
|
|
|
2018-04-13 23:51:30 +01:00
|
|
|
int ssl_has_private_key(const SSL_CONFIG *cfg) {
|
|
|
|
return cfg->cert->privatekey != nullptr || cfg->cert->key_method != nullptr;
|
2016-07-08 23:42:16 +01:00
|
|
|
}
|
2016-07-08 23:07:02 +01:00
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
static int pkey_supports_algorithm(const SSL *ssl, EVP_PKEY *pkey,
|
|
|
|
uint16_t sigalg) {
|
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
|
|
|
if (alg == NULL ||
|
|
|
|
EVP_PKEY_id(pkey) != alg->pkey_type) {
|
|
|
|
return 0;
|
2016-07-08 23:07:02 +01:00
|
|
|
}
|
|
|
|
|
2017-10-06 23:31:15 +01:00
|
|
|
if (ssl_protocol_version(ssl) >= TLS1_3_VERSION) {
|
2017-08-29 21:33:21 +01:00
|
|
|
// RSA keys may only be used with RSA-PSS.
|
2017-03-30 22:37:54 +01:00
|
|
|
if (alg->pkey_type == EVP_PKEY_RSA && !alg->is_rsa_pss) {
|
2017-03-28 20:17:01 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2016-07-08 23:42:16 +01:00
|
|
|
|
2017-08-29 21:33:21 +01:00
|
|
|
// EC keys have a curve requirement.
|
2017-03-30 22:37:54 +01:00
|
|
|
if (alg->pkey_type == EVP_PKEY_EC &&
|
|
|
|
(alg->curve == NID_undef ||
|
|
|
|
EC_GROUP_get_curve_name(
|
|
|
|
EC_KEY_get0_group(EVP_PKEY_get0_EC_KEY(pkey))) != alg->curve)) {
|
2017-03-28 20:17:01 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2017-03-30 22:37:54 +01:00
|
|
|
}
|
2016-07-09 00:15:32 +01:00
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-06-01 00:07:31 +01:00
|
|
|
static int setup_ctx(SSL *ssl, EVP_MD_CTX *ctx, EVP_PKEY *pkey, uint16_t sigalg,
|
|
|
|
int is_verify) {
|
|
|
|
if (!pkey_supports_algorithm(ssl, pkey, sigalg)) {
|
2017-03-30 22:37:54 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_WRONG_SIGNATURE_TYPE);
|
|
|
|
return 0;
|
2017-03-28 20:17:01 +01:00
|
|
|
}
|
2016-07-08 23:42:16 +01:00
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
2017-06-01 00:07:31 +01:00
|
|
|
const EVP_MD *digest = alg->digest_func != NULL ? alg->digest_func() : NULL;
|
|
|
|
EVP_PKEY_CTX *pctx;
|
|
|
|
if (is_verify) {
|
|
|
|
if (!EVP_DigestVerifyInit(ctx, &pctx, digest, NULL, pkey)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
} else if (!EVP_DigestSignInit(ctx, &pctx, digest, NULL, pkey)) {
|
2017-03-30 22:37:54 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2016-07-06 19:24:47 +01:00
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
if (alg->is_rsa_pss) {
|
2017-06-01 00:07:31 +01:00
|
|
|
if (!EVP_PKEY_CTX_set_rsa_padding(pctx, RSA_PKCS1_PSS_PADDING) ||
|
|
|
|
!EVP_PKEY_CTX_set_rsa_pss_saltlen(pctx, -1 /* salt len = hash len */)) {
|
2017-03-28 20:17:01 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2016-07-06 19:24:47 +01:00
|
|
|
}
|
|
|
|
|
2017-03-30 22:37:54 +01:00
|
|
|
return 1;
|
2016-07-06 19:24:47 +01:00
|
|
|
}
|
|
|
|
|
2015-05-29 22:11:21 +01:00
|
|
|
enum ssl_private_key_result_t ssl_private_key_sign(
|
2017-06-17 18:20:59 +01:00
|
|
|
SSL_HANDSHAKE *hs, uint8_t *out, size_t *out_len, size_t max_out,
|
2017-10-11 22:19:19 +01:00
|
|
|
uint16_t sigalg, Span<const uint8_t> in) {
|
2017-06-17 18:20:59 +01:00
|
|
|
SSL *const ssl = hs->ssl;
|
2018-04-13 23:51:30 +01:00
|
|
|
if (hs->config->cert->key_method != NULL) {
|
2017-06-17 18:20:59 +01:00
|
|
|
enum ssl_private_key_result_t ret;
|
|
|
|
if (hs->pending_private_key_op) {
|
2018-04-13 23:51:30 +01:00
|
|
|
ret = hs->config->cert->key_method->complete(ssl, out, out_len, max_out);
|
2017-06-17 18:20:59 +01:00
|
|
|
} else {
|
2018-04-13 23:51:30 +01:00
|
|
|
ret = hs->config->cert->key_method->sign(ssl, out, out_len, max_out,
|
|
|
|
sigalg, in.data(), in.size());
|
2016-07-08 23:42:16 +01:00
|
|
|
}
|
2018-02-01 20:07:30 +00:00
|
|
|
if (ret == ssl_private_key_failure) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_PRIVATE_KEY_OPERATION_FAILED);
|
|
|
|
}
|
2017-06-17 18:20:59 +01:00
|
|
|
hs->pending_private_key_op = ret == ssl_private_key_retry;
|
|
|
|
return ret;
|
2015-05-29 22:11:21 +01:00
|
|
|
}
|
|
|
|
|
2017-03-28 20:17:01 +01:00
|
|
|
*out_len = max_out;
|
2017-07-20 04:57:40 +01:00
|
|
|
ScopedEVP_MD_CTX ctx;
|
2018-04-13 23:51:30 +01:00
|
|
|
if (!setup_ctx(ssl, ctx.get(), hs->config->cert->privatekey.get(), sigalg,
|
2018-04-12 21:11:15 +01:00
|
|
|
0 /* sign */) ||
|
2017-10-11 22:19:19 +01:00
|
|
|
!EVP_DigestSign(ctx.get(), out, out_len, in.data(), in.size())) {
|
2017-07-20 04:57:40 +01:00
|
|
|
return ssl_private_key_failure;
|
|
|
|
}
|
|
|
|
return ssl_private_key_success;
|
2015-05-29 22:11:21 +01:00
|
|
|
}
|
|
|
|
|
2017-10-11 22:19:19 +01:00
|
|
|
bool ssl_public_key_verify(SSL *ssl, Span<const uint8_t> signature,
|
|
|
|
uint16_t sigalg, EVP_PKEY *pkey,
|
|
|
|
Span<const uint8_t> in) {
|
2017-07-20 04:57:40 +01:00
|
|
|
ScopedEVP_MD_CTX ctx;
|
|
|
|
return setup_ctx(ssl, ctx.get(), pkey, sigalg, 1 /* verify */) &&
|
2017-10-11 22:19:19 +01:00
|
|
|
EVP_DigestVerify(ctx.get(), signature.data(), signature.size(),
|
|
|
|
in.data(), in.size());
|
2016-06-30 18:27:23 +01:00
|
|
|
}
|
|
|
|
|
2017-10-11 22:19:19 +01:00
|
|
|
enum ssl_private_key_result_t ssl_private_key_decrypt(SSL_HANDSHAKE *hs,
|
|
|
|
uint8_t *out,
|
|
|
|
size_t *out_len,
|
|
|
|
size_t max_out,
|
|
|
|
Span<const uint8_t> in) {
|
2017-06-17 18:20:59 +01:00
|
|
|
SSL *const ssl = hs->ssl;
|
2018-04-13 23:51:30 +01:00
|
|
|
if (hs->config->cert->key_method != NULL) {
|
2017-06-17 18:20:59 +01:00
|
|
|
enum ssl_private_key_result_t ret;
|
|
|
|
if (hs->pending_private_key_op) {
|
2018-04-13 23:51:30 +01:00
|
|
|
ret = hs->config->cert->key_method->complete(ssl, out, out_len, max_out);
|
2017-06-17 18:20:59 +01:00
|
|
|
} else {
|
2018-04-13 23:51:30 +01:00
|
|
|
ret = hs->config->cert->key_method->decrypt(ssl, out, out_len, max_out,
|
|
|
|
in.data(), in.size());
|
2017-06-17 18:20:59 +01:00
|
|
|
}
|
2018-02-01 20:07:30 +00:00
|
|
|
if (ret == ssl_private_key_failure) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_PRIVATE_KEY_OPERATION_FAILED);
|
|
|
|
}
|
2017-06-17 18:20:59 +01:00
|
|
|
hs->pending_private_key_op = ret == ssl_private_key_retry;
|
|
|
|
return ret;
|
2015-08-07 22:07:52 +01:00
|
|
|
}
|
|
|
|
|
2018-04-13 23:51:30 +01:00
|
|
|
RSA *rsa = EVP_PKEY_get0_RSA(hs->config->cert->privatekey.get());
|
2015-11-20 22:47:25 +00:00
|
|
|
if (rsa == NULL) {
|
2017-08-29 21:33:21 +01:00
|
|
|
// Decrypt operations are only supported for RSA keys.
|
2015-08-07 22:07:52 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return ssl_private_key_failure;
|
|
|
|
}
|
|
|
|
|
2017-08-29 21:33:21 +01:00
|
|
|
// Decrypt with no padding. PKCS#1 padding will be removed as part of the
|
|
|
|
// timing-sensitive code by the caller.
|
2017-10-11 22:19:19 +01:00
|
|
|
if (!RSA_decrypt(rsa, out_len, out, max_out, in.data(), in.size(),
|
|
|
|
RSA_NO_PADDING)) {
|
2015-11-20 22:47:25 +00:00
|
|
|
return ssl_private_key_failure;
|
2015-08-07 22:07:52 +01:00
|
|
|
}
|
2015-11-20 22:47:25 +00:00
|
|
|
return ssl_private_key_success;
|
2015-08-07 22:07:52 +01:00
|
|
|
}
|
|
|
|
|
2017-10-11 22:19:19 +01:00
|
|
|
bool ssl_private_key_supports_signature_algorithm(SSL_HANDSHAKE *hs,
|
|
|
|
uint16_t sigalg) {
|
2017-03-30 21:51:53 +01:00
|
|
|
SSL *const ssl = hs->ssl;
|
2017-07-20 19:49:15 +01:00
|
|
|
if (!pkey_supports_algorithm(ssl, hs->local_pubkey.get(), sigalg)) {
|
2017-10-11 22:19:19 +01:00
|
|
|
return false;
|
2016-07-09 02:52:12 +01:00
|
|
|
}
|
|
|
|
|
2017-08-29 21:33:21 +01:00
|
|
|
// Ensure the RSA key is large enough for the hash. RSASSA-PSS requires that
|
|
|
|
// emLen be at least hLen + sLen + 2. Both hLen and sLen are the size of the
|
|
|
|
// hash in TLS. Reasonable RSA key sizes are large enough for the largest
|
|
|
|
// defined RSASSA-PSS algorithm, but 1024-bit RSA is slightly too small for
|
|
|
|
// SHA-512. 1024-bit RSA is sometimes used for test credentials, so check the
|
|
|
|
// size so that we can fall back to another algorithm in that case.
|
2017-03-30 22:37:54 +01:00
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
2017-07-20 19:49:15 +01:00
|
|
|
if (alg->is_rsa_pss && (size_t)EVP_PKEY_size(hs->local_pubkey.get()) <
|
|
|
|
2 * EVP_MD_size(alg->digest_func()) + 2) {
|
2017-10-11 22:19:19 +01:00
|
|
|
return false;
|
2017-03-28 21:38:29 +01:00
|
|
|
}
|
2016-07-13 03:27:01 +01:00
|
|
|
|
2017-10-11 22:19:19 +01:00
|
|
|
return true;
|
2016-07-09 02:52:12 +01:00
|
|
|
}
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
|
|
|
|
} // namespace bssl
|
|
|
|
|
|
|
|
using namespace bssl;
|
|
|
|
|
|
|
|
int SSL_use_RSAPrivateKey(SSL *ssl, RSA *rsa) {
|
2018-04-13 23:51:30 +01:00
|
|
|
if (rsa == NULL || ssl->config == NULL) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_PASSED_NULL_PARAMETER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-02 22:16:31 +01:00
|
|
|
UniquePtr<EVP_PKEY> pkey(EVP_PKEY_new());
|
|
|
|
if (!pkey ||
|
|
|
|
!EVP_PKEY_set1_RSA(pkey.get(), rsa)) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_EVP_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-03 01:24:40 +01:00
|
|
|
return ssl_set_pkey(ssl->config->cert.get(), pkey.get());
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_use_RSAPrivateKey_ASN1(SSL *ssl, const uint8_t *der, size_t der_len) {
|
|
|
|
UniquePtr<RSA> rsa(RSA_private_key_from_bytes(der, der_len));
|
|
|
|
if (!rsa) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_ASN1_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return SSL_use_RSAPrivateKey(ssl, rsa.get());
|
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_use_PrivateKey(SSL *ssl, EVP_PKEY *pkey) {
|
2018-04-13 23:51:30 +01:00
|
|
|
if (pkey == NULL || ssl->config == NULL) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_PASSED_NULL_PARAMETER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-03 01:24:40 +01:00
|
|
|
return ssl_set_pkey(ssl->config->cert.get(), pkey);
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_use_PrivateKey_ASN1(int type, SSL *ssl, const uint8_t *der,
|
|
|
|
size_t der_len) {
|
|
|
|
if (der_len > LONG_MAX) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_OVERFLOW);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint8_t *p = der;
|
2017-08-02 22:16:31 +01:00
|
|
|
UniquePtr<EVP_PKEY> pkey(d2i_PrivateKey(type, NULL, &p, (long)der_len));
|
|
|
|
if (!pkey || p != der + der_len) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_ASN1_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-02 22:16:31 +01:00
|
|
|
return SSL_use_PrivateKey(ssl, pkey.get());
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_CTX_use_RSAPrivateKey(SSL_CTX *ctx, RSA *rsa) {
|
|
|
|
if (rsa == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_PASSED_NULL_PARAMETER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-02 22:16:31 +01:00
|
|
|
UniquePtr<EVP_PKEY> pkey(EVP_PKEY_new());
|
|
|
|
if (!pkey ||
|
|
|
|
!EVP_PKEY_set1_RSA(pkey.get(), rsa)) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_EVP_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-03 01:24:40 +01:00
|
|
|
return ssl_set_pkey(ctx->cert.get(), pkey.get());
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_CTX_use_RSAPrivateKey_ASN1(SSL_CTX *ctx, const uint8_t *der,
|
|
|
|
size_t der_len) {
|
2017-08-02 22:16:31 +01:00
|
|
|
UniquePtr<RSA> rsa(RSA_private_key_from_bytes(der, der_len));
|
|
|
|
if (!rsa) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_ASN1_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-02 22:16:31 +01:00
|
|
|
return SSL_CTX_use_RSAPrivateKey(ctx, rsa.get());
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_CTX_use_PrivateKey(SSL_CTX *ctx, EVP_PKEY *pkey) {
|
|
|
|
if (pkey == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_PASSED_NULL_PARAMETER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-03 01:24:40 +01:00
|
|
|
return ssl_set_pkey(ctx->cert.get(), pkey);
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_CTX_use_PrivateKey_ASN1(int type, SSL_CTX *ctx, const uint8_t *der,
|
|
|
|
size_t der_len) {
|
|
|
|
if (der_len > LONG_MAX) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_OVERFLOW);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const uint8_t *p = der;
|
2017-08-02 22:16:31 +01:00
|
|
|
UniquePtr<EVP_PKEY> pkey(d2i_PrivateKey(type, NULL, &p, (long)der_len));
|
|
|
|
if (!pkey || p != der + der_len) {
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_ASN1_LIB);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-08-02 22:16:31 +01:00
|
|
|
return SSL_CTX_use_PrivateKey(ctx, pkey.get());
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void SSL_set_private_key_method(SSL *ssl,
|
|
|
|
const SSL_PRIVATE_KEY_METHOD *key_method) {
|
2018-04-13 23:51:30 +01:00
|
|
|
if (!ssl->config) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
ssl->config->cert->key_method = key_method;
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void SSL_CTX_set_private_key_method(SSL_CTX *ctx,
|
|
|
|
const SSL_PRIVATE_KEY_METHOD *key_method) {
|
|
|
|
ctx->cert->key_method = key_method;
|
|
|
|
}
|
|
|
|
|
2017-11-02 21:21:39 +00:00
|
|
|
const char *SSL_get_signature_algorithm_name(uint16_t sigalg,
|
|
|
|
int include_curve) {
|
|
|
|
switch (sigalg) {
|
2017-11-05 21:37:07 +00:00
|
|
|
case SSL_SIGN_RSA_PKCS1_MD5_SHA1:
|
|
|
|
return "rsa_pkcs1_md5_sha1";
|
2017-11-02 21:21:39 +00:00
|
|
|
case SSL_SIGN_RSA_PKCS1_SHA1:
|
|
|
|
return "rsa_pkcs1_sha1";
|
|
|
|
case SSL_SIGN_RSA_PKCS1_SHA256:
|
|
|
|
return "rsa_pkcs1_sha256";
|
|
|
|
case SSL_SIGN_RSA_PKCS1_SHA384:
|
|
|
|
return "rsa_pkcs1_sha384";
|
|
|
|
case SSL_SIGN_RSA_PKCS1_SHA512:
|
|
|
|
return "rsa_pkcs1_sha512";
|
|
|
|
case SSL_SIGN_ECDSA_SHA1:
|
|
|
|
return "ecdsa_sha1";
|
|
|
|
case SSL_SIGN_ECDSA_SECP256R1_SHA256:
|
|
|
|
return include_curve ? "ecdsa_secp256r1_sha256" : "ecdsa_sha256";
|
|
|
|
case SSL_SIGN_ECDSA_SECP384R1_SHA384:
|
|
|
|
return include_curve ? "ecdsa_secp384r1_sha384" : "ecdsa_sha384";
|
|
|
|
case SSL_SIGN_ECDSA_SECP521R1_SHA512:
|
|
|
|
return include_curve ? "ecdsa_secp521r1_sha512" : "ecdsa_sha512";
|
2018-04-13 21:01:02 +01:00
|
|
|
case SSL_SIGN_RSA_PSS_RSAE_SHA256:
|
|
|
|
return "rsa_pss_rsae_sha256";
|
|
|
|
case SSL_SIGN_RSA_PSS_RSAE_SHA384:
|
|
|
|
return "rsa_pss_rsae_sha384";
|
|
|
|
case SSL_SIGN_RSA_PSS_RSAE_SHA512:
|
|
|
|
return "rsa_pss_rsae_sha512";
|
2017-11-02 21:21:39 +00:00
|
|
|
case SSL_SIGN_ED25519:
|
|
|
|
return "ed25519";
|
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_get_signature_algorithm_key_type(uint16_t sigalg) {
|
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
|
|
|
return alg != nullptr ? alg->pkey_type : EVP_PKEY_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
const EVP_MD *SSL_get_signature_algorithm_digest(uint16_t sigalg) {
|
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
|
|
|
if (alg == nullptr || alg->digest_func == nullptr) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return alg->digest_func();
|
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_is_signature_algorithm_rsa_pss(uint16_t sigalg) {
|
|
|
|
const SSL_SIGNATURE_ALGORITHM *alg = get_signature_algorithm(sigalg);
|
|
|
|
return alg != nullptr && alg->is_rsa_pss;
|
|
|
|
}
|
|
|
|
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
int SSL_CTX_set_signing_algorithm_prefs(SSL_CTX *ctx, const uint16_t *prefs,
|
|
|
|
size_t num_prefs) {
|
2018-04-12 21:11:15 +01:00
|
|
|
return ctx->cert->sigalgs.CopyFrom(MakeConstSpan(prefs, num_prefs));
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_set_signing_algorithm_prefs(SSL *ssl, const uint16_t *prefs,
|
|
|
|
size_t num_prefs) {
|
2018-04-13 23:51:30 +01:00
|
|
|
if (!ssl->config) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return ssl->config->cert->sigalgs.CopyFrom(MakeConstSpan(prefs, num_prefs));
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int SSL_CTX_set_verify_algorithm_prefs(SSL_CTX *ctx, const uint16_t *prefs,
|
|
|
|
size_t num_prefs) {
|
2018-07-03 01:24:40 +01:00
|
|
|
return ctx->verify_sigalgs.CopyFrom(MakeConstSpan(prefs, num_prefs));
|
Move libssl's internals into the bssl namespace.
This is horrible, but everything else I tried was worse. The goal with
this CL is to take the extern "C" out of ssl/internal.h and move most
symbols to namespace bssl, so we can start using C++ helpers and
destructors without worry.
Complications:
- Public API functions must be extern "C" and match their declaration in
ssl.h, which is unnamespaced. C++ really does not want you to
interleave namespaced and unnamespaced things. One can actually write
a namespaced extern "C" function, but this means, from C++'s
perspective, the function is namespaced. Trying to namespace the
public header would worked but ended up too deep a rabbithole.
- Our STACK_OF macros do not work right in namespaces.
- The typedefs for our exposed but opaque types are visible in the
header files and copied into consuming projects as forward
declarations. We ultimately want to give SSL a destructor, but
clobbering an unnamespaced ssl_st::~ssl_st seems bad manners.
- MSVC complains about ambiguous names if one typedefs SSL to bssl::SSL.
This CL opts for:
- ssl/*.cc must begin with #define BORINGSSL_INTERNAL_CXX_TYPES. This
informs the public headers to create forward declarations which are
compatible with our namespaces.
- For now, C++-defined type FOO ends up at bssl::FOO with a typedef
outside. Later I imagine we'll rename many of them.
- Internal functions get namespace bssl, so we stop worrying about
stomping the tls1_prf symbol. Exported C functions are stuck as they
are. Rather than try anything weird, bite the bullet and reorder files
which have a mix of public and private functions. I expect that over
time, the public functions will become fairly small as we move logic
to more idiomatic C++.
Files without any public C functions can just be written normally.
- To avoid MSVC troubles, some bssl types are renamed to CPlusPlusStyle
in advance of them being made idiomatic C++.
Bug: 132
Change-Id: Ic931895e117c38b14ff8d6e5a273e868796c7581
Reviewed-on: https://boringssl-review.googlesource.com/18124
Reviewed-by: David Benjamin <davidben@google.com>
2017-07-18 21:34:25 +01:00
|
|
|
}
|