2014-05-13 18:00:26 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2004 The WebRTC Project Authors. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license
|
|
|
|
|
* that can be found in the LICENSE file in the root of the source
|
|
|
|
|
* tree. An additional intellectual property rights grant can be found
|
|
|
|
|
* in the file PATENTS. All contributing project authors may
|
|
|
|
|
* be found in the AUTHORS file in the root of the source tree.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-06-30 10:45:21 -07:00
|
|
|
#include "webrtc/rtc_base/opensslstreamadapter.h"
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
#include <openssl/bio.h>
|
|
|
|
|
#include <openssl/crypto.h>
|
|
|
|
|
#include <openssl/err.h>
|
|
|
|
|
#include <openssl/rand.h>
|
2015-02-11 22:34:36 +00:00
|
|
|
#include <openssl/tls1.h>
|
2014-05-13 18:00:26 +00:00
|
|
|
#include <openssl/x509v3.h>
|
2016-04-07 08:55:28 -07:00
|
|
|
#ifndef OPENSSL_IS_BORINGSSL
|
|
|
|
|
#include <openssl/dtls1.h>
|
2016-12-11 18:42:07 -08:00
|
|
|
#include <openssl/ssl.h>
|
2016-04-07 08:55:28 -07:00
|
|
|
#endif
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-04-26 03:13:22 -07:00
|
|
|
#include <memory>
|
2014-05-13 18:00:26 +00:00
|
|
|
#include <vector>
|
|
|
|
|
|
2017-06-30 10:45:21 -07:00
|
|
|
#include "webrtc/rtc_base/checks.h"
|
|
|
|
|
#include "webrtc/rtc_base/logging.h"
|
|
|
|
|
#include "webrtc/rtc_base/openssl.h"
|
|
|
|
|
#include "webrtc/rtc_base/openssladapter.h"
|
|
|
|
|
#include "webrtc/rtc_base/openssldigest.h"
|
|
|
|
|
#include "webrtc/rtc_base/opensslidentity.h"
|
|
|
|
|
#include "webrtc/rtc_base/safe_conversions.h"
|
|
|
|
|
#include "webrtc/rtc_base/stream.h"
|
|
|
|
|
#include "webrtc/rtc_base/stringutils.h"
|
|
|
|
|
#include "webrtc/rtc_base/thread.h"
|
|
|
|
|
#include "webrtc/rtc_base/timeutils.h"
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-11-28 17:38:34 -08:00
|
|
|
namespace {
|
|
|
|
|
bool g_use_time_callback_for_testing = false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
namespace rtc {
|
|
|
|
|
|
2017-01-23 19:39:57 -08:00
|
|
|
#if (OPENSSL_VERSION_NUMBER < 0x10001000L)
|
|
|
|
|
#error "webrtc requires at least OpenSSL version 1.0.1, to support DTLS-SRTP"
|
2016-03-24 14:05:06 +01:00
|
|
|
#endif
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
// SRTP cipher suite table. |internal_name| is used to construct a
|
|
|
|
|
// colon-separated profile strings which is needed by
|
|
|
|
|
// SSL_CTX_set_tlsext_use_srtp().
|
2014-05-13 18:00:26 +00:00
|
|
|
struct SrtpCipherMapEntry {
|
|
|
|
|
const char* internal_name;
|
2015-11-18 19:41:53 -08:00
|
|
|
const int id;
|
2014-05-13 18:00:26 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// This isn't elegant, but it's better than an external reference
|
|
|
|
|
static SrtpCipherMapEntry SrtpCipherMap[] = {
|
2015-11-18 19:41:53 -08:00
|
|
|
{"SRTP_AES128_CM_SHA1_80", SRTP_AES128_CM_SHA1_80},
|
|
|
|
|
{"SRTP_AES128_CM_SHA1_32", SRTP_AES128_CM_SHA1_32},
|
2016-08-04 05:20:32 -07:00
|
|
|
{"SRTP_AEAD_AES_128_GCM", SRTP_AEAD_AES_128_GCM},
|
|
|
|
|
{"SRTP_AEAD_AES_256_GCM", SRTP_AEAD_AES_256_GCM},
|
2015-11-18 19:41:53 -08:00
|
|
|
{nullptr, 0}};
|
2016-03-24 14:05:06 +01:00
|
|
|
|
2016-06-15 17:15:23 -07:00
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2016-11-28 17:38:34 -08:00
|
|
|
// Not used in production code. Actual time should be relative to Jan 1, 1970.
|
|
|
|
|
static void TimeCallbackForTesting(const SSL* ssl, struct timeval* out_clock) {
|
2016-11-28 01:54:54 -08:00
|
|
|
int64_t time = TimeNanos();
|
2016-06-15 17:15:23 -07:00
|
|
|
out_clock->tv_sec = time / kNumNanosecsPerSec;
|
2016-11-21 14:33:57 -08:00
|
|
|
out_clock->tv_usec = (time % kNumNanosecsPerSec) / kNumNanosecsPerMicrosec;
|
2016-06-15 17:15:23 -07:00
|
|
|
}
|
|
|
|
|
#else // #ifdef OPENSSL_IS_BORINGSSL
|
2016-03-24 14:05:06 +01:00
|
|
|
|
|
|
|
|
// Cipher name table. Maps internal OpenSSL cipher ids to the RFC name.
|
|
|
|
|
struct SslCipherMapEntry {
|
|
|
|
|
uint32_t openssl_id;
|
|
|
|
|
const char* rfc_name;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DEFINE_CIPHER_ENTRY_SSL3(name) {SSL3_CK_##name, "TLS_"#name}
|
|
|
|
|
#define DEFINE_CIPHER_ENTRY_TLS1(name) {TLS1_CK_##name, "TLS_"#name}
|
|
|
|
|
|
|
|
|
|
// There currently is no method available to get a RFC-compliant name for a
|
|
|
|
|
// cipher suite from BoringSSL, so we need to define the mapping manually here.
|
|
|
|
|
// This should go away once BoringSSL supports "SSL_CIPHER_standard_name"
|
|
|
|
|
// (as available in OpenSSL if compiled with tracing enabled) or a similar
|
|
|
|
|
// method.
|
|
|
|
|
static const SslCipherMapEntry kSslCipherMap[] = {
|
2017-02-27 14:06:41 -08:00
|
|
|
// TLS v1.0 ciphersuites from RFC2246.
|
|
|
|
|
DEFINE_CIPHER_ENTRY_SSL3(RSA_RC4_128_SHA),
|
|
|
|
|
{SSL3_CK_RSA_DES_192_CBC3_SHA, "TLS_RSA_WITH_3DES_EDE_CBC_SHA"},
|
|
|
|
|
|
|
|
|
|
// AES ciphersuites from RFC3268.
|
|
|
|
|
{TLS1_CK_RSA_WITH_AES_128_SHA, "TLS_RSA_WITH_AES_128_CBC_SHA"},
|
|
|
|
|
{TLS1_CK_DHE_RSA_WITH_AES_128_SHA, "TLS_DHE_RSA_WITH_AES_128_CBC_SHA"},
|
|
|
|
|
{TLS1_CK_RSA_WITH_AES_256_SHA, "TLS_RSA_WITH_AES_256_CBC_SHA"},
|
|
|
|
|
{TLS1_CK_DHE_RSA_WITH_AES_256_SHA, "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"},
|
|
|
|
|
|
|
|
|
|
// ECC ciphersuites from RFC4492.
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_ECDSA_WITH_RC4_128_SHA),
|
|
|
|
|
{TLS1_CK_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA,
|
|
|
|
|
"TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"},
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_ECDSA_WITH_AES_128_CBC_SHA),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_ECDSA_WITH_AES_256_CBC_SHA),
|
|
|
|
|
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_RSA_WITH_RC4_128_SHA),
|
|
|
|
|
{TLS1_CK_ECDHE_RSA_WITH_DES_192_CBC3_SHA,
|
|
|
|
|
"TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"},
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_RSA_WITH_AES_128_CBC_SHA),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_RSA_WITH_AES_256_CBC_SHA),
|
|
|
|
|
|
|
|
|
|
// TLS v1.2 ciphersuites.
|
|
|
|
|
{TLS1_CK_RSA_WITH_AES_128_SHA256, "TLS_RSA_WITH_AES_128_CBC_SHA256"},
|
|
|
|
|
{TLS1_CK_RSA_WITH_AES_256_SHA256, "TLS_RSA_WITH_AES_256_CBC_SHA256"},
|
|
|
|
|
{TLS1_CK_DHE_RSA_WITH_AES_128_SHA256,
|
|
|
|
|
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA256"},
|
|
|
|
|
{TLS1_CK_DHE_RSA_WITH_AES_256_SHA256,
|
|
|
|
|
"TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"},
|
|
|
|
|
|
|
|
|
|
// TLS v1.2 GCM ciphersuites from RFC5288.
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(RSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(RSA_WITH_AES_256_GCM_SHA384),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(DHE_RSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(DHE_RSA_WITH_AES_256_GCM_SHA384),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(DH_RSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(DH_RSA_WITH_AES_256_GCM_SHA384),
|
|
|
|
|
|
|
|
|
|
// ECDH HMAC based ciphersuites from RFC5289.
|
|
|
|
|
{TLS1_CK_ECDHE_ECDSA_WITH_AES_128_SHA256,
|
|
|
|
|
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"},
|
|
|
|
|
{TLS1_CK_ECDHE_ECDSA_WITH_AES_256_SHA384,
|
|
|
|
|
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"},
|
|
|
|
|
{TLS1_CK_ECDHE_RSA_WITH_AES_128_SHA256,
|
|
|
|
|
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"},
|
|
|
|
|
{TLS1_CK_ECDHE_RSA_WITH_AES_256_SHA384,
|
|
|
|
|
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"},
|
|
|
|
|
|
|
|
|
|
// ECDH GCM based ciphersuites from RFC5289.
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_ECDSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_ECDSA_WITH_AES_256_GCM_SHA384),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_RSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
DEFINE_CIPHER_ENTRY_TLS1(ECDHE_RSA_WITH_AES_256_GCM_SHA384),
|
|
|
|
|
|
|
|
|
|
{0, nullptr}};
|
2016-03-24 14:05:06 +01:00
|
|
|
#endif // #ifndef OPENSSL_IS_BORINGSSL
|
2015-02-11 22:34:36 +00:00
|
|
|
|
2015-09-30 21:48:54 -07:00
|
|
|
#if defined(_MSC_VER)
|
|
|
|
|
#pragma warning(push)
|
|
|
|
|
#pragma warning(disable : 4309)
|
|
|
|
|
#pragma warning(disable : 4310)
|
|
|
|
|
#endif // defined(_MSC_VER)
|
|
|
|
|
|
|
|
|
|
#if defined(_MSC_VER)
|
|
|
|
|
#pragma warning(pop)
|
|
|
|
|
#endif // defined(_MSC_VER)
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
//////////////////////////////////////////////////////////////////////
|
|
|
|
|
// StreamBIO
|
|
|
|
|
//////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
static int stream_write(BIO* h, const char* buf, int num);
|
|
|
|
|
static int stream_read(BIO* h, char* buf, int size);
|
|
|
|
|
static int stream_puts(BIO* h, const char* str);
|
|
|
|
|
static long stream_ctrl(BIO* h, int cmd, long arg1, void* arg2);
|
|
|
|
|
static int stream_new(BIO* h);
|
|
|
|
|
static int stream_free(BIO* data);
|
|
|
|
|
|
2015-01-22 23:06:17 +00:00
|
|
|
// TODO(davidben): This should be const once BoringSSL is assumed.
|
|
|
|
|
static BIO_METHOD methods_stream = {
|
2017-02-27 14:06:41 -08:00
|
|
|
BIO_TYPE_BIO, "stream", stream_write, stream_read, stream_puts, 0,
|
|
|
|
|
stream_ctrl, stream_new, stream_free, nullptr,
|
2014-05-13 18:00:26 +00:00
|
|
|
};
|
|
|
|
|
|
2015-01-22 23:06:17 +00:00
|
|
|
static BIO_METHOD* BIO_s_stream() { return(&methods_stream); }
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
static BIO* BIO_new_stream(StreamInterface* stream) {
|
|
|
|
|
BIO* ret = BIO_new(BIO_s_stream());
|
2017-02-27 14:06:41 -08:00
|
|
|
if (ret == nullptr)
|
|
|
|
|
return nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
ret->ptr = stream;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// bio methods return 1 (or at least non-zero) on success and 0 on failure.
|
|
|
|
|
|
|
|
|
|
static int stream_new(BIO* b) {
|
|
|
|
|
b->shutdown = 0;
|
|
|
|
|
b->init = 1;
|
|
|
|
|
b->num = 0; // 1 means end-of-stream
|
|
|
|
|
b->ptr = 0;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int stream_free(BIO* b) {
|
2017-02-27 14:06:41 -08:00
|
|
|
if (b == nullptr)
|
2014-05-13 18:00:26 +00:00
|
|
|
return 0;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int stream_read(BIO* b, char* out, int outl) {
|
|
|
|
|
if (!out)
|
|
|
|
|
return -1;
|
|
|
|
|
StreamInterface* stream = static_cast<StreamInterface*>(b->ptr);
|
|
|
|
|
BIO_clear_retry_flags(b);
|
|
|
|
|
size_t read;
|
|
|
|
|
int error;
|
|
|
|
|
StreamResult result = stream->Read(out, outl, &read, &error);
|
|
|
|
|
if (result == SR_SUCCESS) {
|
2014-11-06 17:23:09 +00:00
|
|
|
return checked_cast<int>(read);
|
2014-05-13 18:00:26 +00:00
|
|
|
} else if (result == SR_EOS) {
|
|
|
|
|
b->num = 1;
|
|
|
|
|
} else if (result == SR_BLOCK) {
|
|
|
|
|
BIO_set_retry_read(b);
|
|
|
|
|
}
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int stream_write(BIO* b, const char* in, int inl) {
|
|
|
|
|
if (!in)
|
|
|
|
|
return -1;
|
|
|
|
|
StreamInterface* stream = static_cast<StreamInterface*>(b->ptr);
|
|
|
|
|
BIO_clear_retry_flags(b);
|
|
|
|
|
size_t written;
|
|
|
|
|
int error;
|
|
|
|
|
StreamResult result = stream->Write(in, inl, &written, &error);
|
|
|
|
|
if (result == SR_SUCCESS) {
|
2014-11-06 17:23:09 +00:00
|
|
|
return checked_cast<int>(written);
|
2014-05-13 18:00:26 +00:00
|
|
|
} else if (result == SR_BLOCK) {
|
|
|
|
|
BIO_set_retry_write(b);
|
|
|
|
|
}
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int stream_puts(BIO* b, const char* str) {
|
2014-11-06 17:23:09 +00:00
|
|
|
return stream_write(b, str, checked_cast<int>(strlen(str)));
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static long stream_ctrl(BIO* b, int cmd, long num, void* ptr) {
|
|
|
|
|
switch (cmd) {
|
|
|
|
|
case BIO_CTRL_RESET:
|
|
|
|
|
return 0;
|
|
|
|
|
case BIO_CTRL_EOF:
|
|
|
|
|
return b->num;
|
|
|
|
|
case BIO_CTRL_WPENDING:
|
|
|
|
|
case BIO_CTRL_PENDING:
|
|
|
|
|
return 0;
|
|
|
|
|
case BIO_CTRL_FLUSH:
|
|
|
|
|
return 1;
|
2015-06-10 09:45:58 +02:00
|
|
|
case BIO_CTRL_DGRAM_QUERY_MTU:
|
|
|
|
|
// openssl defaults to mtu=256 unless we return something here.
|
|
|
|
|
// The handshake doesn't actually need to send packets above 1k,
|
|
|
|
|
// so this seems like a sensible value that should work in most cases.
|
|
|
|
|
// Webrtc uses the same value for video packets.
|
|
|
|
|
return 1200;
|
2014-05-13 18:00:26 +00:00
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
// OpenSSLStreamAdapter
|
|
|
|
|
/////////////////////////////////////////////////////////////////////////////
|
|
|
|
|
|
|
|
|
|
OpenSSLStreamAdapter::OpenSSLStreamAdapter(StreamInterface* stream)
|
|
|
|
|
: SSLStreamAdapter(stream),
|
|
|
|
|
state_(SSL_NONE),
|
|
|
|
|
role_(SSL_CLIENT),
|
2016-01-11 15:27:03 -08:00
|
|
|
ssl_read_needs_write_(false),
|
|
|
|
|
ssl_write_needs_read_(false),
|
2017-02-27 14:06:41 -08:00
|
|
|
ssl_(nullptr),
|
|
|
|
|
ssl_ctx_(nullptr),
|
2015-05-20 12:48:41 +02:00
|
|
|
ssl_mode_(SSL_MODE_TLS),
|
2016-01-11 15:27:03 -08:00
|
|
|
ssl_max_version_(SSL_PROTOCOL_TLS_12) {}
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
OpenSSLStreamAdapter::~OpenSSLStreamAdapter() {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Cleanup(0);
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::SetIdentity(SSLIdentity* identity) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(!identity_);
|
2014-05-13 18:00:26 +00:00
|
|
|
identity_.reset(static_cast<OpenSSLIdentity*>(identity));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::SetServerRole(SSLRole role) {
|
|
|
|
|
role_ = role;
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<SSLCertificate> OpenSSLStreamAdapter::GetPeerCertificate()
|
2016-04-06 05:15:06 -07:00
|
|
|
const {
|
2016-04-26 03:13:22 -07:00
|
|
|
return peer_certificate_ ? std::unique_ptr<SSLCertificate>(
|
2016-04-06 05:15:06 -07:00
|
|
|
peer_certificate_->GetReference())
|
|
|
|
|
: nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
bool OpenSSLStreamAdapter::SetPeerCertificateDigest(
|
|
|
|
|
const std::string& digest_alg,
|
|
|
|
|
const unsigned char* digest_val,
|
|
|
|
|
size_t digest_len,
|
|
|
|
|
SSLPeerCertificateDigestError* error) {
|
|
|
|
|
RTC_DCHECK(!peer_certificate_verified_);
|
|
|
|
|
RTC_DCHECK(!has_peer_certificate_digest());
|
2014-05-13 18:00:26 +00:00
|
|
|
size_t expected_len;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (error) {
|
|
|
|
|
*error = SSLPeerCertificateDigestError::NONE;
|
|
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
if (!OpenSSLDigest::GetDigestSize(digest_alg, &expected_len)) {
|
|
|
|
|
LOG(LS_WARNING) << "Unknown digest algorithm: " << digest_alg;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (error) {
|
|
|
|
|
*error = SSLPeerCertificateDigestError::UNKNOWN_ALGORITHM;
|
|
|
|
|
}
|
Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
2016-09-19 17:20:52 -07:00
|
|
|
return false;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (expected_len != digest_len) {
|
|
|
|
|
if (error) {
|
|
|
|
|
*error = SSLPeerCertificateDigestError::INVALID_LENGTH;
|
|
|
|
|
}
|
Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
2016-09-19 17:20:52 -07:00
|
|
|
return false;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
peer_certificate_digest_value_.SetData(digest_val, digest_len);
|
|
|
|
|
peer_certificate_digest_algorithm_ = digest_alg;
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (!peer_certificate_) {
|
|
|
|
|
// Normal case, where the digest is set before we obtain the certificate
|
|
|
|
|
// from the handshake.
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!VerifyPeerCertificate()) {
|
|
|
|
|
Error("SetPeerCertificateDigest", -1, SSL_AD_BAD_CERTIFICATE, false);
|
|
|
|
|
if (error) {
|
|
|
|
|
*error = SSLPeerCertificateDigestError::VERIFICATION_FAILED;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (state_ == SSL_CONNECTED) {
|
|
|
|
|
// Post the event asynchronously to unwind the stack. The caller
|
|
|
|
|
// of ContinueSSL may be the same object listening for these
|
|
|
|
|
// events and may not be prepared for reentrancy.
|
|
|
|
|
PostEvent(SE_OPEN | SE_READ | SE_WRITE, 0);
|
|
|
|
|
}
|
|
|
|
|
|
Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
2016-09-19 17:20:52 -07:00
|
|
|
return true;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
std::string OpenSSLStreamAdapter::SslCipherSuiteToName(int cipher_suite) {
|
2016-03-24 14:05:06 +01:00
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2015-11-18 19:41:53 -08:00
|
|
|
const SSL_CIPHER* ssl_cipher = SSL_get_cipher_by_value(cipher_suite);
|
2015-09-30 21:48:54 -07:00
|
|
|
if (!ssl_cipher) {
|
|
|
|
|
return std::string();
|
|
|
|
|
}
|
|
|
|
|
char* cipher_name = SSL_CIPHER_get_rfc_name(ssl_cipher);
|
|
|
|
|
std::string rfc_name = std::string(cipher_name);
|
|
|
|
|
OPENSSL_free(cipher_name);
|
|
|
|
|
return rfc_name;
|
2016-03-24 14:05:06 +01:00
|
|
|
#else
|
|
|
|
|
for (const SslCipherMapEntry* entry = kSslCipherMap; entry->rfc_name;
|
|
|
|
|
++entry) {
|
|
|
|
|
if (cipher_suite == static_cast<int>(entry->openssl_id)) {
|
|
|
|
|
return entry->rfc_name;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return std::string();
|
|
|
|
|
#endif
|
2015-09-30 21:48:54 -07:00
|
|
|
}
|
2015-02-11 22:34:36 +00:00
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
bool OpenSSLStreamAdapter::GetSslCipherSuite(int* cipher_suite) {
|
2015-02-11 22:34:36 +00:00
|
|
|
if (state_ != SSL_CONNECTED)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
const SSL_CIPHER* current_cipher = SSL_get_current_cipher(ssl_);
|
2017-02-27 14:06:41 -08:00
|
|
|
if (current_cipher == nullptr) {
|
2015-02-11 22:34:36 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
*cipher_suite = static_cast<uint16_t>(SSL_CIPHER_get_id(current_cipher));
|
2015-02-11 22:34:36 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-11 00:06:47 -08:00
|
|
|
int OpenSSLStreamAdapter::GetSslVersion() const {
|
|
|
|
|
if (state_ != SSL_CONNECTED)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
int ssl_version = SSL_version(ssl_);
|
|
|
|
|
if (ssl_mode_ == SSL_MODE_DTLS) {
|
|
|
|
|
if (ssl_version == DTLS1_VERSION)
|
|
|
|
|
return SSL_PROTOCOL_DTLS_10;
|
|
|
|
|
else if (ssl_version == DTLS1_2_VERSION)
|
|
|
|
|
return SSL_PROTOCOL_DTLS_12;
|
|
|
|
|
} else {
|
|
|
|
|
if (ssl_version == TLS1_VERSION)
|
|
|
|
|
return SSL_PROTOCOL_TLS_10;
|
|
|
|
|
else if (ssl_version == TLS1_1_VERSION)
|
|
|
|
|
return SSL_PROTOCOL_TLS_11;
|
|
|
|
|
else if (ssl_version == TLS1_2_VERSION)
|
|
|
|
|
return SSL_PROTOCOL_TLS_12;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
// Key Extractor interface
|
|
|
|
|
bool OpenSSLStreamAdapter::ExportKeyingMaterial(const std::string& label,
|
Use suffixed {uint,int}{8,16,32,64}_t types.
Removes the use of uint8, etc. in favor of uint8_t.
BUG=webrtc:5024
R=henrik.lundin@webrtc.org, henrikg@webrtc.org, perkj@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1362503003 .
Cr-Commit-Position: refs/heads/master@{#10196}
2015-10-07 12:23:21 +02:00
|
|
|
const uint8_t* context,
|
2014-05-13 18:00:26 +00:00
|
|
|
size_t context_len,
|
|
|
|
|
bool use_context,
|
Use suffixed {uint,int}{8,16,32,64}_t types.
Removes the use of uint8, etc. in favor of uint8_t.
BUG=webrtc:5024
R=henrik.lundin@webrtc.org, henrikg@webrtc.org, perkj@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1362503003 .
Cr-Commit-Position: refs/heads/master@{#10196}
2015-10-07 12:23:21 +02:00
|
|
|
uint8_t* result,
|
2014-05-13 18:00:26 +00:00
|
|
|
size_t result_len) {
|
|
|
|
|
int i;
|
|
|
|
|
|
Use suffixed {uint,int}{8,16,32,64}_t types.
Removes the use of uint8, etc. in favor of uint8_t.
BUG=webrtc:5024
R=henrik.lundin@webrtc.org, henrikg@webrtc.org, perkj@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, tina.legrand@webrtc.org
Review URL: https://codereview.webrtc.org/1362503003 .
Cr-Commit-Position: refs/heads/master@{#10196}
2015-10-07 12:23:21 +02:00
|
|
|
i = SSL_export_keying_material(ssl_, result, result_len, label.c_str(),
|
|
|
|
|
label.length(), const_cast<uint8_t*>(context),
|
2014-05-13 18:00:26 +00:00
|
|
|
context_len, use_context);
|
|
|
|
|
|
|
|
|
|
if (i != 1)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
bool OpenSSLStreamAdapter::SetDtlsSrtpCryptoSuites(
|
|
|
|
|
const std::vector<int>& ciphers) {
|
2014-05-13 18:00:26 +00:00
|
|
|
std::string internal_ciphers;
|
|
|
|
|
|
|
|
|
|
if (state_ != SSL_NONE)
|
|
|
|
|
return false;
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
for (std::vector<int>::const_iterator cipher = ciphers.begin();
|
2014-05-13 18:00:26 +00:00
|
|
|
cipher != ciphers.end(); ++cipher) {
|
|
|
|
|
bool found = false;
|
2015-11-18 19:41:53 -08:00
|
|
|
for (SrtpCipherMapEntry* entry = SrtpCipherMap; entry->internal_name;
|
2014-05-13 18:00:26 +00:00
|
|
|
++entry) {
|
2015-11-18 19:41:53 -08:00
|
|
|
if (*cipher == entry->id) {
|
2014-05-13 18:00:26 +00:00
|
|
|
found = true;
|
|
|
|
|
if (!internal_ciphers.empty())
|
|
|
|
|
internal_ciphers += ":";
|
|
|
|
|
internal_ciphers += entry->internal_name;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!found) {
|
|
|
|
|
LOG(LS_ERROR) << "Could not find cipher: " << *cipher;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (internal_ciphers.empty())
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
srtp_ciphers_ = internal_ciphers;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
bool OpenSSLStreamAdapter::GetDtlsSrtpCryptoSuite(int* crypto_suite) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(state_ == SSL_CONNECTED);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (state_ != SSL_CONNECTED)
|
|
|
|
|
return false;
|
|
|
|
|
|
2015-01-07 17:59:28 +00:00
|
|
|
const SRTP_PROTECTION_PROFILE *srtp_profile =
|
2014-05-13 18:00:26 +00:00
|
|
|
SSL_get_selected_srtp_profile(ssl_);
|
|
|
|
|
|
|
|
|
|
if (!srtp_profile)
|
|
|
|
|
return false;
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
*crypto_suite = srtp_profile->id;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(!SrtpCryptoSuiteToName(*crypto_suite).empty());
|
2015-11-18 19:41:53 -08:00
|
|
|
return true;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
bool OpenSSLStreamAdapter::IsTlsConnected() {
|
|
|
|
|
return state_ == SSL_CONNECTED;
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-11 12:01:49 -07:00
|
|
|
int OpenSSLStreamAdapter::StartSSL() {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (state_ != SSL_NONE) {
|
|
|
|
|
// Don't allow StartSSL to be called twice.
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2016-08-11 12:01:49 -07:00
|
|
|
|
|
|
|
|
if (StreamAdapterInterface::GetState() != SS_OPEN) {
|
|
|
|
|
state_ = SSL_WAIT;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-08-11 12:01:49 -07:00
|
|
|
state_ = SSL_CONNECTING;
|
|
|
|
|
if (int err = BeginSSL()) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("BeginSSL", err, 0, false);
|
2016-08-11 12:01:49 -07:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::SetMode(SSLMode mode) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(state_ == SSL_NONE);
|
2014-05-13 18:00:26 +00:00
|
|
|
ssl_mode_ = mode;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-20 12:48:41 +02:00
|
|
|
void OpenSSLStreamAdapter::SetMaxProtocolVersion(SSLProtocolVersion version) {
|
2017-02-27 14:06:41 -08:00
|
|
|
RTC_DCHECK(ssl_ctx_ == nullptr);
|
2015-05-20 12:48:41 +02:00
|
|
|
ssl_max_version_ = version;
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-02 17:18:37 -08:00
|
|
|
void OpenSSLStreamAdapter::SetInitialRetransmissionTimeout(
|
|
|
|
|
int timeout_ms) {
|
2017-02-27 14:06:41 -08:00
|
|
|
RTC_DCHECK(ssl_ctx_ == nullptr);
|
2017-02-02 17:18:37 -08:00
|
|
|
dtls_handshake_timeout_ms_ = timeout_ms;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
//
|
|
|
|
|
// StreamInterface Implementation
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
StreamResult OpenSSLStreamAdapter::Write(const void* data, size_t data_len,
|
|
|
|
|
size_t* written, int* error) {
|
|
|
|
|
LOG(LS_VERBOSE) << "OpenSSLStreamAdapter::Write(" << data_len << ")";
|
|
|
|
|
|
|
|
|
|
switch (state_) {
|
|
|
|
|
case SSL_NONE:
|
|
|
|
|
// pass-through in clear text
|
|
|
|
|
return StreamAdapterInterface::Write(data, data_len, written, error);
|
|
|
|
|
|
|
|
|
|
case SSL_WAIT:
|
|
|
|
|
case SSL_CONNECTING:
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
|
|
|
|
|
case SSL_CONNECTED:
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (waiting_to_verify_peer_certificate()) {
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR:
|
|
|
|
|
case SSL_CLOSED:
|
|
|
|
|
default:
|
|
|
|
|
if (error)
|
|
|
|
|
*error = ssl_error_code_;
|
|
|
|
|
return SR_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// OpenSSL will return an error if we try to write zero bytes
|
|
|
|
|
if (data_len == 0) {
|
|
|
|
|
if (written)
|
|
|
|
|
*written = 0;
|
|
|
|
|
return SR_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ssl_write_needs_read_ = false;
|
|
|
|
|
|
2014-11-06 17:23:09 +00:00
|
|
|
int code = SSL_write(ssl_, data, checked_cast<int>(data_len));
|
2014-05-13 18:00:26 +00:00
|
|
|
int ssl_error = SSL_get_error(ssl_, code);
|
|
|
|
|
switch (ssl_error) {
|
|
|
|
|
case SSL_ERROR_NONE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- success";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(0 < code && static_cast<unsigned>(code) <= data_len);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (written)
|
|
|
|
|
*written = code;
|
|
|
|
|
return SR_SUCCESS;
|
|
|
|
|
case SSL_ERROR_WANT_READ:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want read";
|
|
|
|
|
ssl_write_needs_read_ = true;
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
case SSL_ERROR_WANT_WRITE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want write";
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR_ZERO_RETURN:
|
|
|
|
|
default:
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("SSL_write", (ssl_error ? ssl_error : -1), 0, false);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (error)
|
|
|
|
|
*error = ssl_error_code_;
|
|
|
|
|
return SR_ERROR;
|
|
|
|
|
}
|
|
|
|
|
// not reached
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StreamResult OpenSSLStreamAdapter::Read(void* data, size_t data_len,
|
|
|
|
|
size_t* read, int* error) {
|
|
|
|
|
LOG(LS_VERBOSE) << "OpenSSLStreamAdapter::Read(" << data_len << ")";
|
|
|
|
|
switch (state_) {
|
|
|
|
|
case SSL_NONE:
|
|
|
|
|
// pass-through in clear text
|
|
|
|
|
return StreamAdapterInterface::Read(data, data_len, read, error);
|
|
|
|
|
|
|
|
|
|
case SSL_WAIT:
|
|
|
|
|
case SSL_CONNECTING:
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
|
|
|
|
|
case SSL_CONNECTED:
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (waiting_to_verify_peer_certificate()) {
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SSL_CLOSED:
|
|
|
|
|
return SR_EOS;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR:
|
|
|
|
|
default:
|
|
|
|
|
if (error)
|
|
|
|
|
*error = ssl_error_code_;
|
|
|
|
|
return SR_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Don't trust OpenSSL with zero byte reads
|
|
|
|
|
if (data_len == 0) {
|
|
|
|
|
if (read)
|
|
|
|
|
*read = 0;
|
|
|
|
|
return SR_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ssl_read_needs_write_ = false;
|
|
|
|
|
|
2014-11-06 17:23:09 +00:00
|
|
|
int code = SSL_read(ssl_, data, checked_cast<int>(data_len));
|
2014-05-13 18:00:26 +00:00
|
|
|
int ssl_error = SSL_get_error(ssl_, code);
|
|
|
|
|
switch (ssl_error) {
|
|
|
|
|
case SSL_ERROR_NONE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- success";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(0 < code && static_cast<unsigned>(code) <= data_len);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (read)
|
|
|
|
|
*read = code;
|
|
|
|
|
|
|
|
|
|
if (ssl_mode_ == SSL_MODE_DTLS) {
|
|
|
|
|
// Enforce atomic reads -- this is a short read
|
|
|
|
|
unsigned int pending = SSL_pending(ssl_);
|
|
|
|
|
|
|
|
|
|
if (pending) {
|
|
|
|
|
LOG(LS_INFO) << " -- short DTLS read. flushing";
|
|
|
|
|
FlushInput(pending);
|
|
|
|
|
if (error)
|
|
|
|
|
*error = SSE_MSG_TRUNC;
|
|
|
|
|
return SR_ERROR;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return SR_SUCCESS;
|
|
|
|
|
case SSL_ERROR_WANT_READ:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want read";
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
case SSL_ERROR_WANT_WRITE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want write";
|
|
|
|
|
ssl_read_needs_write_ = true;
|
|
|
|
|
return SR_BLOCK;
|
|
|
|
|
case SSL_ERROR_ZERO_RETURN:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- remote side closed";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Close();
|
2014-05-13 18:00:26 +00:00
|
|
|
return SR_EOS;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error " << code;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("SSL_read", (ssl_error ? ssl_error : -1), 0, false);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (error)
|
|
|
|
|
*error = ssl_error_code_;
|
|
|
|
|
return SR_ERROR;
|
|
|
|
|
}
|
|
|
|
|
// not reached
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::FlushInput(unsigned int left) {
|
|
|
|
|
unsigned char buf[2048];
|
|
|
|
|
|
|
|
|
|
while (left) {
|
|
|
|
|
// This should always succeed
|
|
|
|
|
int toread = (sizeof(buf) < left) ? sizeof(buf) : left;
|
|
|
|
|
int code = SSL_read(ssl_, buf, toread);
|
|
|
|
|
|
|
|
|
|
int ssl_error = SSL_get_error(ssl_, code);
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(ssl_error == SSL_ERROR_NONE);
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
if (ssl_error != SSL_ERROR_NONE) {
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error " << code;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("SSL_read", (ssl_error ? ssl_error : -1), 0, false);
|
2014-05-13 18:00:26 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LOG(LS_VERBOSE) << " -- flushed " << code << " bytes";
|
|
|
|
|
left -= code;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::Close() {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Cleanup(0);
|
|
|
|
|
RTC_DCHECK(state_ == SSL_CLOSED || state_ == SSL_ERROR);
|
|
|
|
|
// When we're closed at SSL layer, also close the stream level which
|
|
|
|
|
// performs necessary clean up. Otherwise, a new incoming packet after
|
|
|
|
|
// this could overflow the stream buffer.
|
2014-05-13 18:00:26 +00:00
|
|
|
StreamAdapterInterface::Close();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StreamState OpenSSLStreamAdapter::GetState() const {
|
|
|
|
|
switch (state_) {
|
|
|
|
|
case SSL_WAIT:
|
|
|
|
|
case SSL_CONNECTING:
|
|
|
|
|
return SS_OPENING;
|
|
|
|
|
case SSL_CONNECTED:
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (waiting_to_verify_peer_certificate()) {
|
|
|
|
|
return SS_OPENING;
|
|
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
return SS_OPEN;
|
|
|
|
|
default:
|
|
|
|
|
return SS_CLOSED;
|
|
|
|
|
};
|
|
|
|
|
// not reached
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::OnEvent(StreamInterface* stream, int events,
|
|
|
|
|
int err) {
|
|
|
|
|
int events_to_signal = 0;
|
|
|
|
|
int signal_error = 0;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(stream == this->stream());
|
2014-05-13 18:00:26 +00:00
|
|
|
if ((events & SE_OPEN)) {
|
|
|
|
|
LOG(LS_VERBOSE) << "OpenSSLStreamAdapter::OnEvent SE_OPEN";
|
|
|
|
|
if (state_ != SSL_WAIT) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(state_ == SSL_NONE);
|
2014-05-13 18:00:26 +00:00
|
|
|
events_to_signal |= SE_OPEN;
|
|
|
|
|
} else {
|
|
|
|
|
state_ = SSL_CONNECTING;
|
|
|
|
|
if (int err = BeginSSL()) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("BeginSSL", err, 0, true);
|
2014-05-13 18:00:26 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ((events & (SE_READ|SE_WRITE))) {
|
|
|
|
|
LOG(LS_VERBOSE) << "OpenSSLStreamAdapter::OnEvent"
|
|
|
|
|
<< ((events & SE_READ) ? " SE_READ" : "")
|
|
|
|
|
<< ((events & SE_WRITE) ? " SE_WRITE" : "");
|
|
|
|
|
if (state_ == SSL_NONE) {
|
|
|
|
|
events_to_signal |= events & (SE_READ|SE_WRITE);
|
|
|
|
|
} else if (state_ == SSL_CONNECTING) {
|
|
|
|
|
if (int err = ContinueSSL()) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Error("ContinueSSL", err, 0, true);
|
2014-05-13 18:00:26 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
} else if (state_ == SSL_CONNECTED) {
|
|
|
|
|
if (((events & SE_READ) && ssl_write_needs_read_) ||
|
|
|
|
|
(events & SE_WRITE)) {
|
|
|
|
|
LOG(LS_VERBOSE) << " -- onStreamWriteable";
|
|
|
|
|
events_to_signal |= SE_WRITE;
|
|
|
|
|
}
|
|
|
|
|
if (((events & SE_WRITE) && ssl_read_needs_write_) ||
|
|
|
|
|
(events & SE_READ)) {
|
|
|
|
|
LOG(LS_VERBOSE) << " -- onStreamReadable";
|
|
|
|
|
events_to_signal |= SE_READ;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if ((events & SE_CLOSE)) {
|
|
|
|
|
LOG(LS_VERBOSE) << "OpenSSLStreamAdapter::OnEvent(SE_CLOSE, " << err << ")";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Cleanup(0);
|
2014-05-13 18:00:26 +00:00
|
|
|
events_to_signal |= SE_CLOSE;
|
|
|
|
|
// SE_CLOSE is the only event that uses the final parameter to OnEvent().
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(signal_error == 0);
|
2014-05-13 18:00:26 +00:00
|
|
|
signal_error = err;
|
|
|
|
|
}
|
|
|
|
|
if (events_to_signal)
|
|
|
|
|
StreamAdapterInterface::OnEvent(stream, events_to_signal, signal_error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int OpenSSLStreamAdapter::BeginSSL() {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(state_ == SSL_CONNECTING);
|
2016-08-11 12:01:49 -07:00
|
|
|
// The underlying stream has opened.
|
|
|
|
|
LOG(LS_INFO) << "BeginSSL with peer.";
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2017-02-27 14:06:41 -08:00
|
|
|
BIO* bio = nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-08-11 12:01:49 -07:00
|
|
|
// First set up the context.
|
2017-02-27 14:06:41 -08:00
|
|
|
RTC_DCHECK(ssl_ctx_ == nullptr);
|
2014-05-13 18:00:26 +00:00
|
|
|
ssl_ctx_ = SetupSSLContext();
|
|
|
|
|
if (!ssl_ctx_)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
bio = BIO_new_stream(static_cast<StreamInterface*>(stream()));
|
|
|
|
|
if (!bio)
|
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
|
|
ssl_ = SSL_new(ssl_ctx_);
|
|
|
|
|
if (!ssl_) {
|
|
|
|
|
BIO_free(bio);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SSL_set_app_data(ssl_, this);
|
|
|
|
|
|
|
|
|
|
SSL_set_bio(ssl_, bio, bio); // the SSL object owns the bio now.
|
2016-03-24 14:05:06 +01:00
|
|
|
if (ssl_mode_ == SSL_MODE_DTLS) {
|
2016-06-15 17:15:23 -07:00
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2017-02-02 17:18:37 -08:00
|
|
|
DTLSv1_set_initial_timeout_duration(ssl_, dtls_handshake_timeout_ms_);
|
2016-06-15 17:15:23 -07:00
|
|
|
#else
|
2016-03-24 14:05:06 +01:00
|
|
|
// Enable read-ahead for DTLS so whole packets are read from internal BIO
|
|
|
|
|
// before parsing. This is done internally by BoringSSL for DTLS.
|
|
|
|
|
SSL_set_read_ahead(ssl_, 1);
|
2016-05-24 01:49:43 -07:00
|
|
|
#endif
|
2016-06-15 17:15:23 -07:00
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
SSL_set_mode(ssl_, SSL_MODE_ENABLE_PARTIAL_WRITE |
|
|
|
|
|
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER);
|
|
|
|
|
|
2016-03-24 13:28:25 -04:00
|
|
|
#if !defined(OPENSSL_IS_BORINGSSL)
|
|
|
|
|
// Specify an ECDH group for ECDHE ciphers, otherwise OpenSSL cannot
|
|
|
|
|
// negotiate them when acting as the server. Use NIST's P-256 which is
|
|
|
|
|
// commonly supported. BoringSSL doesn't need explicit configuration and has
|
|
|
|
|
// a reasonable default set.
|
2014-08-28 16:14:38 +00:00
|
|
|
EC_KEY* ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
|
2017-02-27 14:06:41 -08:00
|
|
|
if (ecdh == nullptr)
|
2014-08-28 16:14:38 +00:00
|
|
|
return -1;
|
|
|
|
|
SSL_set_options(ssl_, SSL_OP_SINGLE_ECDH_USE);
|
|
|
|
|
SSL_set_tmp_ecdh(ssl_, ecdh);
|
|
|
|
|
EC_KEY_free(ecdh);
|
2016-03-24 13:28:25 -04:00
|
|
|
#endif
|
2014-08-28 16:14:38 +00:00
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
// Do the connect
|
|
|
|
|
return ContinueSSL();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int OpenSSLStreamAdapter::ContinueSSL() {
|
|
|
|
|
LOG(LS_VERBOSE) << "ContinueSSL";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
RTC_DCHECK(state_ == SSL_CONNECTING);
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
// Clear the DTLS timer
|
|
|
|
|
Thread::Current()->Clear(this, MSG_TIMEOUT);
|
|
|
|
|
|
|
|
|
|
int code = (role_ == SSL_CLIENT) ? SSL_connect(ssl_) : SSL_accept(ssl_);
|
|
|
|
|
int ssl_error;
|
|
|
|
|
switch (ssl_error = SSL_get_error(ssl_, code)) {
|
|
|
|
|
case SSL_ERROR_NONE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- success";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
// By this point, OpenSSL should have given us a certificate, or errored
|
|
|
|
|
// out if one was missing.
|
|
|
|
|
RTC_DCHECK(peer_certificate_ || !client_auth_enabled());
|
Revert of Allow the DTLS fingerprint verification to occur after the handshake. (patchset #11 id:200001 of https://codereview.webrtc.org/2163683003/ )
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
2016-09-19 17:20:52 -07:00
|
|
|
|
|
|
|
|
state_ = SSL_CONNECTED;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (!waiting_to_verify_peer_certificate()) {
|
|
|
|
|
// We have everything we need to start the connection, so signal
|
|
|
|
|
// SE_OPEN. If we need a client certificate fingerprint and don't have
|
|
|
|
|
// it yet, we'll instead signal SE_OPEN in SetPeerCertificateDigest.
|
|
|
|
|
//
|
2016-09-30 17:34:32 -07:00
|
|
|
// TODO(deadbeef): Post this event asynchronously to unwind the stack.
|
|
|
|
|
// The caller of ContinueSSL may be the same object listening for these
|
|
|
|
|
// events and may not be prepared for reentrancy.
|
|
|
|
|
// PostEvent(SE_OPEN | SE_READ | SE_WRITE, 0);
|
|
|
|
|
StreamAdapterInterface::OnEvent(stream(), SE_OPEN | SE_READ | SE_WRITE,
|
|
|
|
|
0);
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
}
|
2014-05-13 18:00:26 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR_WANT_READ: {
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want read";
|
|
|
|
|
struct timeval timeout;
|
|
|
|
|
if (DTLSv1_get_timeout(ssl_, &timeout)) {
|
|
|
|
|
int delay = timeout.tv_sec * 1000 + timeout.tv_usec/1000;
|
|
|
|
|
|
2016-06-10 14:17:27 -07:00
|
|
|
Thread::Current()->PostDelayed(RTC_FROM_HERE, delay, this,
|
|
|
|
|
MSG_TIMEOUT, 0);
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR_WANT_WRITE:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error want write";
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SSL_ERROR_ZERO_RETURN:
|
|
|
|
|
default:
|
|
|
|
|
LOG(LS_VERBOSE) << " -- error " << code;
|
2016-08-26 11:25:05 -07:00
|
|
|
SSLHandshakeError ssl_handshake_err = SSLHandshakeError::UNKNOWN;
|
|
|
|
|
int err_code = ERR_peek_last_error();
|
|
|
|
|
if (err_code != 0 && ERR_GET_REASON(err_code) == SSL_R_NO_SHARED_CIPHER) {
|
|
|
|
|
ssl_handshake_err = SSLHandshakeError::INCOMPATIBLE_CIPHERSUITE;
|
|
|
|
|
}
|
|
|
|
|
SignalSSLHandshakeError(ssl_handshake_err);
|
2014-05-13 18:00:26 +00:00
|
|
|
return (ssl_error != 0) ? ssl_error : -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
void OpenSSLStreamAdapter::Error(const char* context,
|
|
|
|
|
int err,
|
|
|
|
|
uint8_t alert,
|
|
|
|
|
bool signal) {
|
|
|
|
|
LOG(LS_WARNING) << "OpenSSLStreamAdapter::Error(" << context << ", " << err
|
|
|
|
|
<< ", " << static_cast<int>(alert) << ")";
|
2014-05-13 18:00:26 +00:00
|
|
|
state_ = SSL_ERROR;
|
|
|
|
|
ssl_error_code_ = err;
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
Cleanup(alert);
|
2014-05-13 18:00:26 +00:00
|
|
|
if (signal)
|
|
|
|
|
StreamAdapterInterface::OnEvent(stream(), SE_CLOSE, err);
|
|
|
|
|
}
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
void OpenSSLStreamAdapter::Cleanup(uint8_t alert) {
|
2014-05-13 18:00:26 +00:00
|
|
|
LOG(LS_INFO) << "Cleanup";
|
|
|
|
|
|
|
|
|
|
if (state_ != SSL_ERROR) {
|
|
|
|
|
state_ = SSL_CLOSED;
|
|
|
|
|
ssl_error_code_ = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ssl_) {
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
int ret;
|
|
|
|
|
// SSL_send_fatal_alert is only available in BoringSSL.
|
|
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
|
|
|
|
if (alert) {
|
|
|
|
|
ret = SSL_send_fatal_alert(ssl_, alert);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
LOG(LS_WARNING) << "SSL_send_fatal_alert failed, error = "
|
|
|
|
|
<< SSL_get_error(ssl_, ret);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
#endif
|
|
|
|
|
ret = SSL_shutdown(ssl_);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
LOG(LS_WARNING) << "SSL_shutdown failed, error = "
|
|
|
|
|
<< SSL_get_error(ssl_, ret);
|
|
|
|
|
}
|
|
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2014-09-25 16:38:46 +00:00
|
|
|
}
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
#endif
|
2014-05-13 18:00:26 +00:00
|
|
|
SSL_free(ssl_);
|
2017-02-27 14:06:41 -08:00
|
|
|
ssl_ = nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
if (ssl_ctx_) {
|
|
|
|
|
SSL_CTX_free(ssl_ctx_);
|
2017-02-27 14:06:41 -08:00
|
|
|
ssl_ctx_ = nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
identity_.reset();
|
|
|
|
|
peer_certificate_.reset();
|
|
|
|
|
|
|
|
|
|
// Clear the DTLS timer
|
|
|
|
|
Thread::Current()->Clear(this, MSG_TIMEOUT);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void OpenSSLStreamAdapter::OnMessage(Message* msg) {
|
|
|
|
|
// Process our own messages and then pass others to the superclass
|
|
|
|
|
if (MSG_TIMEOUT == msg->message_id) {
|
|
|
|
|
LOG(LS_INFO) << "DTLS timeout expired";
|
|
|
|
|
DTLSv1_handle_timeout(ssl_);
|
|
|
|
|
ContinueSSL();
|
|
|
|
|
} else {
|
|
|
|
|
StreamInterface::OnMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SSL_CTX* OpenSSLStreamAdapter::SetupSSLContext() {
|
2017-02-27 14:06:41 -08:00
|
|
|
SSL_CTX* ctx = nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-03-24 14:05:06 +01:00
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2014-05-13 18:00:26 +00:00
|
|
|
ctx = SSL_CTX_new(ssl_mode_ == SSL_MODE_DTLS ?
|
2015-05-20 12:48:41 +02:00
|
|
|
DTLS_method() : TLS_method());
|
|
|
|
|
// Version limiting for BoringSSL will be done below.
|
2016-03-24 14:05:06 +01:00
|
|
|
#else
|
|
|
|
|
const SSL_METHOD* method;
|
|
|
|
|
switch (ssl_max_version_) {
|
|
|
|
|
case SSL_PROTOCOL_TLS_10:
|
|
|
|
|
case SSL_PROTOCOL_TLS_11:
|
|
|
|
|
// OpenSSL doesn't support setting min/max versions, so we always use
|
|
|
|
|
// (D)TLS 1.0 if a max. version below the max. available is requested.
|
|
|
|
|
if (ssl_mode_ == SSL_MODE_DTLS) {
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = DTLSv1_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = DTLSv1_server_method();
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = TLSv1_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = TLSv1_server_method();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case SSL_PROTOCOL_TLS_12:
|
|
|
|
|
default:
|
|
|
|
|
if (ssl_mode_ == SSL_MODE_DTLS) {
|
|
|
|
|
#if (OPENSSL_VERSION_NUMBER >= 0x10002000L)
|
|
|
|
|
// DTLS 1.2 only available starting from OpenSSL 1.0.2
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = DTLS_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = DTLS_server_method();
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = DTLSv1_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = DTLSv1_server_method();
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
} else {
|
|
|
|
|
#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
|
|
|
|
|
// New API only available starting from OpenSSL 1.1.0
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = TLS_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = TLS_server_method();
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
if (role_ == SSL_CLIENT) {
|
|
|
|
|
method = SSLv23_client_method();
|
|
|
|
|
} else {
|
|
|
|
|
method = SSLv23_server_method();
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
ctx = SSL_CTX_new(method);
|
|
|
|
|
#endif // OPENSSL_IS_BORINGSSL
|
2015-05-20 12:48:41 +02:00
|
|
|
|
2017-02-27 14:06:41 -08:00
|
|
|
if (ctx == nullptr)
|
|
|
|
|
return nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
|
2016-03-24 14:05:06 +01:00
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
2016-12-06 17:12:02 -08:00
|
|
|
SSL_CTX_set_min_proto_version(ctx, ssl_mode_ == SSL_MODE_DTLS ?
|
2015-05-20 12:48:41 +02:00
|
|
|
DTLS1_VERSION : TLS1_VERSION);
|
|
|
|
|
switch (ssl_max_version_) {
|
|
|
|
|
case SSL_PROTOCOL_TLS_10:
|
2016-12-06 17:12:02 -08:00
|
|
|
SSL_CTX_set_max_proto_version(ctx, ssl_mode_ == SSL_MODE_DTLS ?
|
2015-05-20 12:48:41 +02:00
|
|
|
DTLS1_VERSION : TLS1_VERSION);
|
|
|
|
|
break;
|
|
|
|
|
case SSL_PROTOCOL_TLS_11:
|
2016-12-06 17:12:02 -08:00
|
|
|
SSL_CTX_set_max_proto_version(ctx, ssl_mode_ == SSL_MODE_DTLS ?
|
2015-05-20 12:48:41 +02:00
|
|
|
DTLS1_VERSION : TLS1_1_VERSION);
|
|
|
|
|
break;
|
|
|
|
|
case SSL_PROTOCOL_TLS_12:
|
|
|
|
|
default:
|
2016-12-06 17:12:02 -08:00
|
|
|
SSL_CTX_set_max_proto_version(ctx, ssl_mode_ == SSL_MODE_DTLS ?
|
2015-05-20 12:48:41 +02:00
|
|
|
DTLS1_2_VERSION : TLS1_2_VERSION);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2016-11-28 17:38:34 -08:00
|
|
|
if (g_use_time_callback_for_testing) {
|
|
|
|
|
SSL_CTX_set_current_time_cb(ctx, &TimeCallbackForTesting);
|
|
|
|
|
}
|
2016-03-24 14:05:06 +01:00
|
|
|
#endif
|
2015-05-20 12:48:41 +02:00
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
if (identity_ && !identity_->ConfigureIdentity(ctx)) {
|
|
|
|
|
SSL_CTX_free(ctx);
|
2017-02-27 14:06:41 -08:00
|
|
|
return nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-30 16:08:48 -07:00
|
|
|
#if !defined(NDEBUG)
|
2014-05-13 18:00:26 +00:00
|
|
|
SSL_CTX_set_info_callback(ctx, OpenSSLAdapter::SSLInfoCallback);
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-09-23 05:56:44 +00:00
|
|
|
int mode = SSL_VERIFY_PEER;
|
|
|
|
|
if (client_auth_enabled()) {
|
|
|
|
|
// Require a certificate from the client.
|
|
|
|
|
// Note: Normally this is always true in production, but it may be disabled
|
|
|
|
|
// for testing purposes (e.g. SSLAdapter unit tests).
|
|
|
|
|
mode |= SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SSL_CTX_set_verify(ctx, mode, SSLVerifyCallback);
|
2014-05-13 18:00:26 +00:00
|
|
|
SSL_CTX_set_verify_depth(ctx, 4);
|
2015-05-20 12:48:41 +02:00
|
|
|
// Select list of available ciphers. Note that !SHA256 and !SHA384 only
|
|
|
|
|
// remove HMAC-SHA256 and HMAC-SHA384 cipher suites, not GCM cipher suites
|
|
|
|
|
// with SHA256 or SHA384 as the handshake hash.
|
|
|
|
|
// This matches the list of SSLClientSocketOpenSSL in Chromium.
|
2017-02-27 14:06:41 -08:00
|
|
|
SSL_CTX_set_cipher_list(
|
|
|
|
|
ctx, "DEFAULT:!NULL:!aNULL:!SHA256:!SHA384:!aECDH:!AESGCM+AES256:!aPSK");
|
2014-05-13 18:00:26 +00:00
|
|
|
|
|
|
|
|
if (!srtp_ciphers_.empty()) {
|
|
|
|
|
if (SSL_CTX_set_tlsext_use_srtp(ctx, srtp_ciphers_.c_str())) {
|
|
|
|
|
SSL_CTX_free(ctx);
|
2017-02-27 14:06:41 -08:00
|
|
|
return nullptr;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ctx;
|
|
|
|
|
}
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
bool OpenSSLStreamAdapter::VerifyPeerCertificate() {
|
|
|
|
|
if (!has_peer_certificate_digest() || !peer_certificate_) {
|
|
|
|
|
LOG(LS_WARNING) << "Missing digest or peer certificate.";
|
|
|
|
|
return false;
|
2014-06-05 20:40:11 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
unsigned char digest[EVP_MAX_MD_SIZE];
|
|
|
|
|
size_t digest_length;
|
|
|
|
|
if (!OpenSSLCertificate::ComputeDigest(
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
peer_certificate_->x509(), peer_certificate_digest_algorithm_, digest,
|
|
|
|
|
sizeof(digest), &digest_length)) {
|
2014-05-13 18:00:26 +00:00
|
|
|
LOG(LS_WARNING) << "Failed to compute peer cert digest.";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
return false;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
2014-06-05 20:40:11 +00:00
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
Buffer computed_digest(digest, digest_length);
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
if (computed_digest != peer_certificate_digest_value_) {
|
2014-05-13 18:00:26 +00:00
|
|
|
LOG(LS_WARNING) << "Rejected peer certificate due to mismatched digest.";
|
2017-03-09 16:24:57 -08:00
|
|
|
return false;
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
// Ignore any verification error if the digest matches, since there is no
|
|
|
|
|
// value in checking the validity of a self-signed cert issued by untrusted
|
|
|
|
|
// sources.
|
|
|
|
|
LOG(LS_INFO) << "Accepted peer certificate.";
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
peer_certificate_verified_ = true;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int OpenSSLStreamAdapter::SSLVerifyCallback(int ok, X509_STORE_CTX* store) {
|
|
|
|
|
// Get our SSL structure from the store
|
|
|
|
|
SSL* ssl = reinterpret_cast<SSL*>(
|
|
|
|
|
X509_STORE_CTX_get_ex_data(store, SSL_get_ex_data_X509_STORE_CTX_idx()));
|
|
|
|
|
X509* cert = X509_STORE_CTX_get_current_cert(store);
|
|
|
|
|
int depth = X509_STORE_CTX_get_error_depth(store);
|
|
|
|
|
|
|
|
|
|
// For now we ignore the parent certificates and verify the leaf against
|
|
|
|
|
// the digest.
|
|
|
|
|
//
|
|
|
|
|
// TODO(jiayl): Verify the chain is a proper chain and report the chain to
|
|
|
|
|
// |stream->peer_certificate_|.
|
|
|
|
|
if (depth > 0) {
|
|
|
|
|
LOG(LS_INFO) << "Ignored chained certificate at depth " << depth;
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OpenSSLStreamAdapter* stream =
|
|
|
|
|
reinterpret_cast<OpenSSLStreamAdapter*>(SSL_get_app_data(ssl));
|
2014-06-05 20:40:11 +00:00
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
// Record the peer's certificate.
|
|
|
|
|
stream->peer_certificate_.reset(new OpenSSLCertificate(cert));
|
|
|
|
|
|
Relanding: Allow the DTLS fingerprint verification to occur after the handshake.
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
2016-09-30 11:55:43 -07:00
|
|
|
// If the peer certificate digest isn't known yet, we'll wait to verify
|
|
|
|
|
// until it's known, and for now just return a success status.
|
|
|
|
|
if (stream->peer_certificate_digest_algorithm_.empty()) {
|
|
|
|
|
LOG(LS_INFO) << "Waiting to verify certificate until digest is known.";
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return stream->VerifyPeerCertificate();
|
2014-05-13 18:00:26 +00:00
|
|
|
}
|
|
|
|
|
|
2016-06-15 17:15:23 -07:00
|
|
|
bool OpenSSLStreamAdapter::IsBoringSsl() {
|
|
|
|
|
#ifdef OPENSSL_IS_BORINGSSL
|
|
|
|
|
return true;
|
|
|
|
|
#else
|
|
|
|
|
return false;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-11 00:06:47 -08:00
|
|
|
#define CDEF(X) \
|
|
|
|
|
{ static_cast<uint16_t>(TLS1_CK_##X & 0xffff), "TLS_" #X }
|
|
|
|
|
|
|
|
|
|
struct cipher_list {
|
|
|
|
|
uint16_t cipher;
|
|
|
|
|
const char* cipher_str;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// TODO(torbjorng): Perhaps add more cipher suites to these lists.
|
|
|
|
|
static const cipher_list OK_RSA_ciphers[] = {
|
|
|
|
|
CDEF(ECDHE_RSA_WITH_AES_128_CBC_SHA),
|
|
|
|
|
CDEF(ECDHE_RSA_WITH_AES_256_CBC_SHA),
|
|
|
|
|
CDEF(ECDHE_RSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
#ifdef TLS1_CK_ECDHE_RSA_WITH_AES_256_GCM_SHA256
|
|
|
|
|
CDEF(ECDHE_RSA_WITH_AES_256_GCM_SHA256),
|
2015-08-17 14:08:59 +02:00
|
|
|
#endif
|
2016-04-07 08:55:28 -07:00
|
|
|
#ifdef TLS1_CK_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
|
2016-03-11 00:06:47 -08:00
|
|
|
CDEF(ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256),
|
2016-04-07 08:55:28 -07:00
|
|
|
#endif
|
2016-03-11 00:06:47 -08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const cipher_list OK_ECDSA_ciphers[] = {
|
|
|
|
|
CDEF(ECDHE_ECDSA_WITH_AES_128_CBC_SHA),
|
|
|
|
|
CDEF(ECDHE_ECDSA_WITH_AES_256_CBC_SHA),
|
|
|
|
|
CDEF(ECDHE_ECDSA_WITH_AES_128_GCM_SHA256),
|
|
|
|
|
#ifdef TLS1_CK_ECDHE_ECDSA_WITH_AES_256_GCM_SHA256
|
|
|
|
|
CDEF(ECDHE_ECDSA_WITH_AES_256_GCM_SHA256),
|
2015-05-20 12:48:41 +02:00
|
|
|
#endif
|
2016-04-07 08:55:28 -07:00
|
|
|
#ifdef TLS1_CK_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
|
2016-03-11 00:06:47 -08:00
|
|
|
CDEF(ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256),
|
2016-04-07 08:55:28 -07:00
|
|
|
#endif
|
2016-03-11 00:06:47 -08:00
|
|
|
};
|
|
|
|
|
#undef CDEF
|
|
|
|
|
|
|
|
|
|
bool OpenSSLStreamAdapter::IsAcceptableCipher(int cipher, KeyType key_type) {
|
|
|
|
|
if (key_type == KT_RSA) {
|
|
|
|
|
for (const cipher_list& c : OK_RSA_ciphers) {
|
|
|
|
|
if (cipher == c.cipher)
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (key_type == KT_ECDSA) {
|
|
|
|
|
for (const cipher_list& c : OK_ECDSA_ciphers) {
|
|
|
|
|
if (cipher == c.cipher)
|
|
|
|
|
return true;
|
2015-08-17 14:08:59 +02:00
|
|
|
}
|
2015-05-20 12:48:41 +02:00
|
|
|
}
|
2016-03-11 00:06:47 -08:00
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool OpenSSLStreamAdapter::IsAcceptableCipher(const std::string& cipher,
|
|
|
|
|
KeyType key_type) {
|
|
|
|
|
if (key_type == KT_RSA) {
|
|
|
|
|
for (const cipher_list& c : OK_RSA_ciphers) {
|
|
|
|
|
if (cipher == c.cipher_str)
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (key_type == KT_ECDSA) {
|
|
|
|
|
for (const cipher_list& c : OK_ECDSA_ciphers) {
|
|
|
|
|
if (cipher == c.cipher_str)
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
2015-02-11 22:34:36 +00:00
|
|
|
}
|
|
|
|
|
|
2016-11-28 17:38:34 -08:00
|
|
|
void OpenSSLStreamAdapter::enable_time_callback_for_testing() {
|
|
|
|
|
g_use_time_callback_for_testing = true;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-13 18:00:26 +00:00
|
|
|
} // namespace rtc
|