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-15 06:48:04 +01:00
|
|
|
#include <openssl/ssl.h>
|
|
|
|
|
2016-09-20 00:57:37 +01:00
|
|
|
#include <assert.h>
|
2016-07-15 04:10:43 +01:00
|
|
|
#include <string.h>
|
|
|
|
|
2016-07-08 17:16:50 +01:00
|
|
|
#include <openssl/buf.h>
|
|
|
|
|
2016-12-13 06:07:13 +00:00
|
|
|
#include "../crypto/internal.h"
|
2015-04-08 03:38:30 +01:00
|
|
|
#include "internal.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
BSSL_NAMESPACE_BEGIN
|
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
|
|
|
|
2017-08-03 01:06:53 +01:00
|
|
|
static void ssl3_on_handshake_complete(SSL *ssl) {
|
2017-08-29 21:33:21 +01:00
|
|
|
// The handshake should have released its final message.
|
2017-08-01 21:32:25 +01:00
|
|
|
assert(!ssl->s3->has_message);
|
2017-08-01 22:35:55 +01:00
|
|
|
|
2017-10-14 00:17:22 +01:00
|
|
|
// During the handshake, |hs_buf| is retained. Release if it there is no
|
2017-10-06 23:26:36 +01:00
|
|
|
// excess in it. There may be excess left if there server sent Finished and
|
|
|
|
// HelloRequest in the same record.
|
2017-08-29 21:33:21 +01:00
|
|
|
//
|
2017-10-06 23:26:36 +01:00
|
|
|
// TODO(davidben): SChannel does not support this. Reject this case.
|
2017-10-14 00:17:22 +01:00
|
|
|
if (ssl->s3->hs_buf && ssl->s3->hs_buf->length == 0) {
|
|
|
|
ssl->s3->hs_buf.reset();
|
2017-08-01 22:35:55 +01:00
|
|
|
}
|
2017-08-03 01:06:53 +01:00
|
|
|
}
|
2016-12-04 04:23:52 +00:00
|
|
|
|
2017-10-07 09:12:35 +01:00
|
|
|
static bool ssl3_set_read_state(SSL *ssl, UniquePtr<SSLAEADContext> aead_ctx) {
|
2017-10-06 23:26:36 +01:00
|
|
|
// Cipher changes are forbidden if the current epoch has leftover data.
|
2017-10-06 22:36:20 +01:00
|
|
|
if (tls_has_unprocessed_handshake_data(ssl)) {
|
2016-07-11 18:19:03 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFERED_MESSAGES_ON_CIPHER_CHANGE);
|
2017-10-06 23:31:15 +01:00
|
|
|
ssl_send_alert(ssl, SSL3_AL_FATAL, SSL_AD_UNEXPECTED_MESSAGE);
|
2017-10-07 09:12:35 +01:00
|
|
|
return false;
|
2016-07-11 18:19:03 +01:00
|
|
|
}
|
2016-07-15 04:10:43 +01:00
|
|
|
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(ssl->s3->read_sequence, 0, sizeof(ssl->s3->read_sequence));
|
2017-10-13 22:18:35 +01:00
|
|
|
ssl->s3->aead_read_ctx = std::move(aead_ctx);
|
2017-10-07 09:12:35 +01:00
|
|
|
return true;
|
2016-07-15 04:10:43 +01:00
|
|
|
}
|
|
|
|
|
2017-10-07 09:12:35 +01:00
|
|
|
static bool ssl3_set_write_state(SSL *ssl, UniquePtr<SSLAEADContext> aead_ctx) {
|
2018-05-24 22:17:34 +01:00
|
|
|
if (!tls_flush_pending_hs_data(ssl)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-10-17 07:56:02 +01:00
|
|
|
OPENSSL_memset(ssl->s3->write_sequence, 0, sizeof(ssl->s3->write_sequence));
|
2017-10-13 22:18:35 +01:00
|
|
|
ssl->s3->aead_write_ctx = std::move(aead_ctx);
|
2017-10-07 09:12:35 +01:00
|
|
|
return true;
|
2016-07-15 04:10:43 +01:00
|
|
|
}
|
|
|
|
|
2016-07-08 17:05:45 +01:00
|
|
|
static const SSL_PROTOCOL_METHOD kTLSProtocolMethod = {
|
2017-10-07 09:12:35 +01:00
|
|
|
false /* is_dtls */,
|
2014-12-12 20:55:27 +00:00
|
|
|
ssl3_new,
|
|
|
|
ssl3_free,
|
|
|
|
ssl3_get_message,
|
2017-08-01 22:35:55 +01:00
|
|
|
ssl3_next_message,
|
2017-10-06 22:36:20 +01:00
|
|
|
ssl3_open_handshake,
|
|
|
|
ssl3_open_change_cipher_spec,
|
|
|
|
ssl3_open_app_data,
|
2015-05-30 21:14:58 +01:00
|
|
|
ssl3_write_app_data,
|
2014-12-12 20:55:27 +00:00
|
|
|
ssl3_dispatch_alert,
|
2016-06-17 23:48:29 +01:00
|
|
|
ssl3_init_message,
|
|
|
|
ssl3_finish_message,
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ssl3_add_message,
|
|
|
|
ssl3_add_change_cipher_spec,
|
2017-01-01 22:41:30 +00:00
|
|
|
ssl3_flush_flight,
|
2017-08-03 00:46:29 +01:00
|
|
|
ssl3_on_handshake_complete,
|
2016-07-15 04:10:43 +01:00
|
|
|
ssl3_set_read_state,
|
|
|
|
ssl3_set_write_state,
|
2014-12-12 20:55:27 +00: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
|
|
|
static int ssl_noop_x509_check_client_CA_names(
|
|
|
|
STACK_OF(CRYPTO_BUFFER) *names) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ssl_noop_x509_clear(CERT *cert) {}
|
|
|
|
static void ssl_noop_x509_free(CERT *cert) {}
|
|
|
|
static void ssl_noop_x509_dup(CERT *new_cert, const CERT *cert) {}
|
|
|
|
static void ssl_noop_x509_flush_cached_leaf(CERT *cert) {}
|
|
|
|
static void ssl_noop_x509_flush_cached_chain(CERT *cert) {}
|
|
|
|
static int ssl_noop_x509_session_cache_objects(SSL_SESSION *sess) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
static int ssl_noop_x509_session_dup(SSL_SESSION *new_session,
|
|
|
|
const SSL_SESSION *session) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
static void ssl_noop_x509_session_clear(SSL_SESSION *session) {}
|
|
|
|
static int ssl_noop_x509_session_verify_cert_chain(SSL_SESSION *session,
|
2018-04-13 23:51:30 +01:00
|
|
|
SSL_HANDSHAKE *hs,
|
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
|
|
|
uint8_t *out_alert) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ssl_noop_x509_hs_flush_cached_ca_names(SSL_HANDSHAKE *hs) {}
|
2018-04-13 23:51:30 +01:00
|
|
|
static int ssl_noop_x509_ssl_new(SSL_HANDSHAKE *hs) { return 1; }
|
|
|
|
static void ssl_noop_x509_ssl_config_free(SSL_CONFIG *cfg) {}
|
|
|
|
static void ssl_noop_x509_ssl_flush_cached_client_CA(SSL_CONFIG *cfg) {}
|
|
|
|
static int ssl_noop_x509_ssl_auto_chain_if_needed(SSL_HANDSHAKE *hs) {
|
|
|
|
return 1;
|
|
|
|
}
|
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
|
|
|
static int ssl_noop_x509_ssl_ctx_new(SSL_CTX *ctx) { return 1; }
|
|
|
|
static void ssl_noop_x509_ssl_ctx_free(SSL_CTX *ctx) { }
|
|
|
|
static void ssl_noop_x509_ssl_ctx_flush_cached_client_CA(SSL_CTX *ctx) {}
|
|
|
|
|
2017-08-04 18:59:24 +01:00
|
|
|
const SSL_X509_METHOD ssl_noop_x509_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
|
|
|
ssl_noop_x509_check_client_CA_names,
|
|
|
|
ssl_noop_x509_clear,
|
|
|
|
ssl_noop_x509_free,
|
|
|
|
ssl_noop_x509_dup,
|
|
|
|
ssl_noop_x509_flush_cached_chain,
|
|
|
|
ssl_noop_x509_flush_cached_leaf,
|
|
|
|
ssl_noop_x509_session_cache_objects,
|
|
|
|
ssl_noop_x509_session_dup,
|
|
|
|
ssl_noop_x509_session_clear,
|
|
|
|
ssl_noop_x509_session_verify_cert_chain,
|
|
|
|
ssl_noop_x509_hs_flush_cached_ca_names,
|
|
|
|
ssl_noop_x509_ssl_new,
|
2018-04-13 23:51:30 +01:00
|
|
|
ssl_noop_x509_ssl_config_free,
|
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
|
|
|
ssl_noop_x509_ssl_flush_cached_client_CA,
|
|
|
|
ssl_noop_x509_ssl_auto_chain_if_needed,
|
|
|
|
ssl_noop_x509_ssl_ctx_new,
|
|
|
|
ssl_noop_x509_ssl_ctx_free,
|
|
|
|
ssl_noop_x509_ssl_ctx_flush_cached_client_CA,
|
|
|
|
};
|
|
|
|
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
BSSL_NAMESPACE_END
|
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
|
|
|
|
|
|
|
using namespace bssl;
|
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLS_method(void) {
|
2016-07-08 17:05:45 +01:00
|
|
|
static const SSL_METHOD kMethod = {
|
2014-12-12 20:55:27 +00:00
|
|
|
0,
|
2016-07-08 17:05:45 +01:00
|
|
|
&kTLSProtocolMethod,
|
2017-02-01 19:59:18 +00:00
|
|
|
&ssl_crypto_x509_method,
|
2014-12-12 20:55:27 +00:00
|
|
|
};
|
2016-07-08 17:05:45 +01:00
|
|
|
return &kMethod;
|
2014-12-12 20:55:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const SSL_METHOD *SSLv23_method(void) {
|
|
|
|
return TLS_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
|
|
|
const SSL_METHOD *TLS_with_buffers_method(void) {
|
|
|
|
static const SSL_METHOD kMethod = {
|
|
|
|
0,
|
|
|
|
&kTLSProtocolMethod,
|
|
|
|
&ssl_noop_x509_method,
|
|
|
|
};
|
|
|
|
return &kMethod;
|
|
|
|
}
|
|
|
|
|
2017-08-29 21:33:21 +01:00
|
|
|
// Legacy version-locked methods.
|
2014-12-12 20:55:27 +00:00
|
|
|
|
|
|
|
const SSL_METHOD *TLSv1_2_method(void) {
|
2016-07-08 17:05:45 +01:00
|
|
|
static const SSL_METHOD kMethod = {
|
2014-12-12 20:55:27 +00:00
|
|
|
TLS1_2_VERSION,
|
2016-07-08 17:05:45 +01:00
|
|
|
&kTLSProtocolMethod,
|
2017-02-01 19:59:18 +00:00
|
|
|
&ssl_crypto_x509_method,
|
2014-12-12 20:55:27 +00:00
|
|
|
};
|
2016-07-08 17:05:45 +01:00
|
|
|
return &kMethod;
|
2014-12-12 20:55:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const SSL_METHOD *TLSv1_1_method(void) {
|
2016-07-08 17:05:45 +01:00
|
|
|
static const SSL_METHOD kMethod = {
|
2014-12-12 20:55:27 +00:00
|
|
|
TLS1_1_VERSION,
|
2016-07-08 17:05:45 +01:00
|
|
|
&kTLSProtocolMethod,
|
2017-02-01 19:59:18 +00:00
|
|
|
&ssl_crypto_x509_method,
|
2014-12-12 20:55:27 +00:00
|
|
|
};
|
2016-07-08 17:05:45 +01:00
|
|
|
return &kMethod;
|
2014-12-12 20:55:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const SSL_METHOD *TLSv1_method(void) {
|
2016-07-08 17:05:45 +01:00
|
|
|
static const SSL_METHOD kMethod = {
|
2014-12-12 20:55:27 +00:00
|
|
|
TLS1_VERSION,
|
2016-07-08 17:05:45 +01:00
|
|
|
&kTLSProtocolMethod,
|
2017-02-01 19:59:18 +00:00
|
|
|
&ssl_crypto_x509_method,
|
2014-12-12 20:55:27 +00:00
|
|
|
};
|
2016-07-08 17:05:45 +01:00
|
|
|
return &kMethod;
|
2014-12-12 20:55:27 +00:00
|
|
|
}
|
|
|
|
|
2017-08-29 21:33:21 +01:00
|
|
|
// Legacy side-specific methods.
|
2014-09-24 21:27:30 +01:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_2_server_method(void) {
|
|
|
|
return TLSv1_2_method();
|
|
|
|
}
|
2014-09-24 21:27:30 +01:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_1_server_method(void) {
|
|
|
|
return TLSv1_1_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_server_method(void) {
|
|
|
|
return TLSv1_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_2_client_method(void) {
|
|
|
|
return TLSv1_2_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_1_client_method(void) {
|
|
|
|
return TLSv1_1_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *TLSv1_client_method(void) {
|
|
|
|
return TLSv1_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *SSLv23_server_method(void) {
|
|
|
|
return SSLv23_method();
|
|
|
|
}
|
2014-11-23 20:47:20 +00:00
|
|
|
|
2014-12-12 20:55:27 +00:00
|
|
|
const SSL_METHOD *SSLv23_client_method(void) {
|
|
|
|
return SSLv23_method();
|
|
|
|
}
|
2016-08-05 15:41:07 +01:00
|
|
|
|
|
|
|
const SSL_METHOD *TLS_server_method(void) {
|
|
|
|
return TLS_method();
|
|
|
|
}
|
|
|
|
|
|
|
|
const SSL_METHOD *TLS_client_method(void) {
|
|
|
|
return TLS_method();
|
|
|
|
}
|