2014-10-28 22:20:11 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2011 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-08-23 18:05:50 -07:00
|
|
|
#include <algorithm>
|
2016-04-26 03:13:22 -07:00
|
|
|
#include <memory>
|
2014-10-28 22:20:11 +00:00
|
|
|
#include <set>
|
2018-11-22 11:34:47 +01:00
|
|
|
#include <utility>
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2019-01-07 10:21:47 -08:00
|
|
|
#include "absl/memory/memory.h"
|
2019-01-11 09:11:00 -08:00
|
|
|
#include "p2p/base/dtls_transport.h"
|
|
|
|
|
#include "p2p/base/fake_ice_transport.h"
|
|
|
|
|
#include "p2p/base/packet_transport_internal.h"
|
2017-09-15 06:47:31 +02:00
|
|
|
#include "rtc_base/checks.h"
|
|
|
|
|
#include "rtc_base/dscp.h"
|
|
|
|
|
#include "rtc_base/gunit.h"
|
|
|
|
|
#include "rtc_base/helpers.h"
|
2019-01-11 09:11:00 -08:00
|
|
|
#include "rtc_base/rtc_certificate.h"
|
|
|
|
|
#include "rtc_base/ssl_adapter.h"
|
|
|
|
|
#include "rtc_base/ssl_identity.h"
|
|
|
|
|
#include "rtc_base/ssl_stream_adapter.h"
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-11-09 11:09:25 +01:00
|
|
|
#define MAYBE_SKIP_TEST(feature) \
|
|
|
|
|
if (!(rtc::SSLStreamAdapter::feature())) { \
|
|
|
|
|
RTC_LOG(LS_INFO) << #feature " feature disabled... skipping"; \
|
|
|
|
|
return; \
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
namespace cricket {
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
static const size_t kPacketNumOffset = 8;
|
|
|
|
|
static const size_t kPacketHeaderLen = 12;
|
2015-10-15 07:26:07 -07:00
|
|
|
static const int kFakePacketId = 0x1234;
|
2016-05-04 17:16:34 -07:00
|
|
|
static const int kTimeout = 10000;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
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
|
|
|
static bool IsRtpLeadByte(uint8_t b) {
|
2014-10-28 22:20:11 +00:00
|
|
|
return ((b & 0xC0) == 0x80);
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// |modify_digest| is used to set modified fingerprints that are meant to fail
|
|
|
|
|
// validation.
|
|
|
|
|
void SetRemoteFingerprintFromCert(
|
|
|
|
|
DtlsTransport* transport,
|
2016-05-04 17:16:34 -07:00
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& cert,
|
2017-12-14 15:38:57 -08:00
|
|
|
bool modify_digest = false) {
|
2018-10-15 19:27:44 -07:00
|
|
|
std::unique_ptr<rtc::SSLFingerprint> fingerprint =
|
|
|
|
|
rtc::SSLFingerprint::CreateFromCertificate(*cert);
|
2017-12-14 15:38:57 -08:00
|
|
|
if (modify_digest) {
|
|
|
|
|
++fingerprint->digest[0];
|
2016-05-04 17:16:34 -07:00
|
|
|
}
|
2017-12-14 15:38:57 -08:00
|
|
|
// Even if digest is verified to be incorrect, should fail asynchrnously.
|
|
|
|
|
EXPECT_TRUE(transport->SetRemoteFingerprint(
|
|
|
|
|
fingerprint->algorithm,
|
|
|
|
|
reinterpret_cast<const uint8_t*>(fingerprint->digest.data()),
|
|
|
|
|
fingerprint->digest.size()));
|
2016-05-04 17:16:34 -07:00
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
class DtlsTestClient : public sigslot::has_slots<> {
|
|
|
|
|
public:
|
2017-08-23 18:05:50 -07:00
|
|
|
explicit DtlsTestClient(const std::string& name) : name_(name) {}
|
2015-08-27 10:12:24 +02:00
|
|
|
void CreateCertificate(rtc::KeyType key_type) {
|
2015-12-17 03:04:15 -08:00
|
|
|
certificate_ =
|
2016-04-26 03:13:22 -07:00
|
|
|
rtc::RTCCertificate::Create(std::unique_ptr<rtc::SSLIdentity>(
|
2015-12-17 03:04:15 -08:00
|
|
|
rtc::SSLIdentity::Generate(name_, key_type)));
|
2015-08-27 10:12:24 +02:00
|
|
|
}
|
|
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& certificate() {
|
|
|
|
|
return certificate_;
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
2015-05-20 12:48:41 +02:00
|
|
|
void SetupMaxProtocolVersion(rtc::SSLProtocolVersion version) {
|
|
|
|
|
ssl_max_version_ = version;
|
|
|
|
|
}
|
2017-12-14 15:38:57 -08:00
|
|
|
// Set up fake ICE transport and real DTLS transport under test.
|
|
|
|
|
void SetupTransports(IceRole role, int async_delay_ms = 0) {
|
2019-05-29 17:34:13 -07:00
|
|
|
fake_ice_transport_.reset(new FakeIceTransport("fake", 0));
|
|
|
|
|
fake_ice_transport_->SetAsync(true);
|
|
|
|
|
fake_ice_transport_->SetAsyncDelay(async_delay_ms);
|
|
|
|
|
fake_ice_transport_->SetIceRole(role);
|
|
|
|
|
fake_ice_transport_->SetIceTiebreaker((role == ICEROLE_CONTROLLING) ? 1
|
|
|
|
|
: 2);
|
2017-12-14 15:38:57 -08:00
|
|
|
// Hook the raw packets so that we can verify they are encrypted.
|
2019-05-29 17:34:13 -07:00
|
|
|
fake_ice_transport_->SignalReadPacket.connect(
|
2017-12-14 15:38:57 -08:00
|
|
|
this, &DtlsTestClient::OnFakeIceTransportReadPacket);
|
|
|
|
|
|
2018-10-11 15:33:17 -07:00
|
|
|
dtls_transport_ = absl::make_unique<DtlsTransport>(
|
2019-05-29 17:34:13 -07:00
|
|
|
fake_ice_transport_.get(), webrtc::CryptoOptions(),
|
2018-11-27 15:53:01 -08:00
|
|
|
/*event_log=*/nullptr);
|
2017-12-14 15:38:57 -08:00
|
|
|
dtls_transport_->SetSslMaxProtocolVersion(ssl_max_version_);
|
|
|
|
|
// Note: Certificate may be null here if testing passthrough.
|
|
|
|
|
dtls_transport_->SetLocalCertificate(certificate_);
|
|
|
|
|
dtls_transport_->SignalWritableState.connect(
|
|
|
|
|
this, &DtlsTestClient::OnTransportWritableState);
|
|
|
|
|
dtls_transport_->SignalReadPacket.connect(
|
|
|
|
|
this, &DtlsTestClient::OnTransportReadPacket);
|
|
|
|
|
dtls_transport_->SignalSentPacket.connect(
|
|
|
|
|
this, &DtlsTestClient::OnTransportSentPacket);
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-22 11:34:47 +01:00
|
|
|
FakeIceTransport* fake_ice_transport() {
|
|
|
|
|
return static_cast<FakeIceTransport*>(dtls_transport_->ice_transport());
|
|
|
|
|
}
|
2017-12-14 15:38:57 -08:00
|
|
|
|
|
|
|
|
DtlsTransport* dtls_transport() { return dtls_transport_.get(); }
|
|
|
|
|
|
|
|
|
|
// Simulate fake ICE transports connecting.
|
2016-05-04 17:16:34 -07:00
|
|
|
bool Connect(DtlsTestClient* peer, bool asymmetric) {
|
2018-11-22 11:34:47 +01:00
|
|
|
fake_ice_transport()->SetDestination(peer->fake_ice_transport(),
|
|
|
|
|
asymmetric);
|
2016-05-04 17:16:34 -07:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int received_dtls_client_hellos() const {
|
|
|
|
|
return received_dtls_client_hellos_;
|
|
|
|
|
}
|
|
|
|
|
|
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 received_dtls_server_hellos() const {
|
|
|
|
|
return received_dtls_server_hellos_;
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
void CheckRole(rtc::SSLRole role) {
|
|
|
|
|
if (role == rtc::SSL_CLIENT) {
|
2016-05-04 17:16:34 -07:00
|
|
|
ASSERT_EQ(0, received_dtls_client_hellos_);
|
|
|
|
|
ASSERT_GT(received_dtls_server_hellos_, 0);
|
2014-10-28 22:20:11 +00:00
|
|
|
} else {
|
2016-05-04 17:16:34 -07:00
|
|
|
ASSERT_GT(received_dtls_client_hellos_, 0);
|
|
|
|
|
ASSERT_EQ(0, received_dtls_server_hellos_);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
void CheckSrtp(int expected_crypto_suite) {
|
2017-12-14 15:38:57 -08:00
|
|
|
int crypto_suite;
|
|
|
|
|
bool rv = dtls_transport_->GetSrtpCryptoSuite(&crypto_suite);
|
|
|
|
|
if (dtls_transport_->IsDtlsActive() && expected_crypto_suite) {
|
|
|
|
|
ASSERT_TRUE(rv);
|
|
|
|
|
ASSERT_EQ(crypto_suite, expected_crypto_suite);
|
|
|
|
|
} else {
|
|
|
|
|
ASSERT_FALSE(rv);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-11 00:06:47 -08:00
|
|
|
void CheckSsl() {
|
2017-12-14 15:38:57 -08:00
|
|
|
int cipher;
|
|
|
|
|
bool rv = dtls_transport_->GetSslCipherSuite(&cipher);
|
|
|
|
|
if (dtls_transport_->IsDtlsActive()) {
|
|
|
|
|
ASSERT_TRUE(rv);
|
|
|
|
|
EXPECT_TRUE(
|
|
|
|
|
rtc::SSLStreamAdapter::IsAcceptableCipher(cipher, rtc::KT_DEFAULT));
|
|
|
|
|
} else {
|
|
|
|
|
ASSERT_FALSE(rv);
|
2015-02-11 22:34:36 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
void SendPackets(size_t size, size_t count, bool srtp) {
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<char[]> packet(new char[size]);
|
2014-10-28 22:20:11 +00:00
|
|
|
size_t sent = 0;
|
|
|
|
|
do {
|
|
|
|
|
// Fill the packet with a known value and a sequence number to check
|
|
|
|
|
// against, and make sure that it doesn't look like DTLS.
|
|
|
|
|
memset(packet.get(), sent & 0xff, size);
|
|
|
|
|
packet[0] = (srtp) ? 0x80 : 0x00;
|
|
|
|
|
rtc::SetBE32(packet.get() + kPacketNumOffset,
|
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
|
|
|
static_cast<uint32_t>(sent));
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
// Only set the bypass flag if we've activated DTLS.
|
2017-12-14 15:38:57 -08:00
|
|
|
int flags = (certificate_ && srtp) ? PF_SRTP_BYPASS : 0;
|
2014-10-28 22:20:11 +00:00
|
|
|
rtc::PacketOptions packet_options;
|
2015-10-15 07:26:07 -07:00
|
|
|
packet_options.packet_id = kFakePacketId;
|
2017-12-14 15:38:57 -08:00
|
|
|
int rv = dtls_transport_->SendPacket(packet.get(), size, packet_options,
|
|
|
|
|
flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_GT(rv, 0);
|
|
|
|
|
ASSERT_EQ(size, static_cast<size_t>(rv));
|
|
|
|
|
++sent;
|
|
|
|
|
} while (sent < count);
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
int SendInvalidSrtpPacket(size_t size) {
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<char[]> packet(new char[size]);
|
2014-10-28 22:20:11 +00:00
|
|
|
// Fill the packet with 0 to form an invalid SRTP packet.
|
|
|
|
|
memset(packet.get(), 0, size);
|
|
|
|
|
|
|
|
|
|
rtc::PacketOptions packet_options;
|
2017-12-14 15:38:57 -08:00
|
|
|
return dtls_transport_->SendPacket(packet.get(), size, packet_options,
|
|
|
|
|
PF_SRTP_BYPASS);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
void ExpectPackets(size_t size) {
|
2014-10-28 22:20:11 +00:00
|
|
|
packet_size_ = size;
|
|
|
|
|
received_.clear();
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-23 18:05:50 -07:00
|
|
|
size_t NumPacketsReceived() { return received_.size(); }
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Inverse of SendPackets.
|
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
|
|
|
bool VerifyPacket(const char* data, size_t size, uint32_t* out_num) {
|
2014-10-28 22:20:11 +00:00
|
|
|
if (size != packet_size_ ||
|
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
|
|
|
(data[0] != 0 && static_cast<uint8_t>(data[0]) != 0x80)) {
|
2014-10-28 22:20:11 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
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
|
|
|
uint32_t packet_num = rtc::GetBE32(data + kPacketNumOffset);
|
2014-10-28 22:20:11 +00:00
|
|
|
for (size_t i = kPacketHeaderLen; i < size; ++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
|
|
|
if (static_cast<uint8_t>(data[i]) != (packet_num & 0xff)) {
|
2014-10-28 22:20:11 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (out_num) {
|
|
|
|
|
*out_num = packet_num;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
bool VerifyEncryptedPacket(const char* data, size_t size) {
|
|
|
|
|
// This is an encrypted data packet; let's make sure it's mostly random;
|
|
|
|
|
// less than 10% of the bytes should be equal to the cleartext packet.
|
|
|
|
|
if (size <= packet_size_) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
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
|
|
|
uint32_t packet_num = rtc::GetBE32(data + kPacketNumOffset);
|
2014-10-28 22:20:11 +00:00
|
|
|
int num_matches = 0;
|
|
|
|
|
for (size_t i = kPacketNumOffset; i < size; ++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
|
|
|
if (static_cast<uint8_t>(data[i]) == (packet_num & 0xff)) {
|
2014-10-28 22:20:11 +00:00
|
|
|
++num_matches;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return (num_matches < ((static_cast<int>(size) - 5) / 10));
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-13 13:26:07 -08:00
|
|
|
// Transport callbacks
|
|
|
|
|
void OnTransportWritableState(rtc::PacketTransportInternal* transport) {
|
|
|
|
|
RTC_LOG(LS_INFO) << name_ << ": Transport '" << transport->transport_name()
|
2017-11-09 11:09:25 +01:00
|
|
|
<< "' is writable";
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-11-13 13:26:07 -08:00
|
|
|
void OnTransportReadPacket(rtc::PacketTransportInternal* transport,
|
|
|
|
|
const char* data,
|
|
|
|
|
size_t size,
|
2018-11-05 13:01:41 +01:00
|
|
|
const int64_t& /* packet_time_us */,
|
2017-11-13 13:26:07 -08:00
|
|
|
int flags) {
|
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
|
|
|
uint32_t packet_num = 0;
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(VerifyPacket(data, size, &packet_num));
|
|
|
|
|
received_.insert(packet_num);
|
|
|
|
|
// Only DTLS-SRTP packets should have the bypass flag set.
|
2015-09-23 11:50:27 -07:00
|
|
|
int expected_flags =
|
2017-12-14 15:38:57 -08:00
|
|
|
(certificate_ && IsRtpLeadByte(data[0])) ? PF_SRTP_BYPASS : 0;
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_EQ(expected_flags, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-13 13:26:07 -08:00
|
|
|
void OnTransportSentPacket(rtc::PacketTransportInternal* transport,
|
|
|
|
|
const rtc::SentPacket& sent_packet) {
|
2015-10-15 07:26:07 -07:00
|
|
|
sent_packet_ = sent_packet;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rtc::SentPacket sent_packet() const { return sent_packet_; }
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
// Hook into the raw packet stream to make sure DTLS packets are encrypted.
|
2017-12-14 15:38:57 -08:00
|
|
|
void OnFakeIceTransportReadPacket(rtc::PacketTransportInternal* transport,
|
|
|
|
|
const char* data,
|
|
|
|
|
size_t size,
|
2018-11-05 13:01:41 +01:00
|
|
|
const int64_t& /* packet_time_us */,
|
2017-12-14 15:38:57 -08:00
|
|
|
int flags) {
|
2018-01-27 14:16:15 -08:00
|
|
|
// Flags shouldn't be set on the underlying Transport packets.
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_EQ(0, flags);
|
|
|
|
|
|
|
|
|
|
// Look at the handshake packets to see what role we played.
|
|
|
|
|
// Check that non-handshake packets are DTLS data or SRTP bypass.
|
2016-05-04 17:16:34 -07:00
|
|
|
if (data[0] == 22 && size > 17) {
|
|
|
|
|
if (data[13] == 1) {
|
|
|
|
|
++received_dtls_client_hellos_;
|
|
|
|
|
} else if (data[13] == 2) {
|
|
|
|
|
++received_dtls_server_hellos_;
|
|
|
|
|
}
|
2017-12-14 15:38:57 -08:00
|
|
|
} else if (dtls_transport_->IsDtlsActive() &&
|
|
|
|
|
!(data[0] >= 20 && data[0] <= 22)) {
|
2016-05-04 17:16:34 -07:00
|
|
|
ASSERT_TRUE(data[0] == 23 || IsRtpLeadByte(data[0]));
|
|
|
|
|
if (data[0] == 23) {
|
|
|
|
|
ASSERT_TRUE(VerifyEncryptedPacket(data, size));
|
|
|
|
|
} else if (IsRtpLeadByte(data[0])) {
|
|
|
|
|
ASSERT_TRUE(VerifyPacket(data, size, NULL));
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
std::string name_;
|
2015-08-27 10:12:24 +02:00
|
|
|
rtc::scoped_refptr<rtc::RTCCertificate> certificate_;
|
2017-12-14 15:38:57 -08:00
|
|
|
std::unique_ptr<FakeIceTransport> fake_ice_transport_;
|
|
|
|
|
std::unique_ptr<DtlsTransport> dtls_transport_;
|
2016-05-04 17:16:34 -07:00
|
|
|
size_t packet_size_ = 0u;
|
2014-10-28 22:20:11 +00:00
|
|
|
std::set<int> received_;
|
2016-05-04 17:16:34 -07:00
|
|
|
rtc::SSLProtocolVersion ssl_max_version_ = rtc::SSL_PROTOCOL_DTLS_12;
|
|
|
|
|
int received_dtls_client_hellos_ = 0;
|
|
|
|
|
int received_dtls_server_hellos_ = 0;
|
2015-10-15 07:26:07 -07:00
|
|
|
rtc::SentPacket sent_packet_;
|
2014-10-28 22:20:11 +00:00
|
|
|
};
|
|
|
|
|
|
2018-01-27 14:16:15 -08:00
|
|
|
// Base class for DtlsTransportTest and DtlsEventOrderingTest, which
|
2019-04-09 15:11:12 +02:00
|
|
|
// inherit from different variants of ::testing::Test.
|
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
|
|
|
//
|
2016-06-15 17:15:23 -07:00
|
|
|
// Note that this test always uses a FakeClock, due to the |fake_clock_| member
|
|
|
|
|
// variable.
|
2018-01-27 14:16:15 -08:00
|
|
|
class DtlsTransportTestBase {
|
2014-10-28 22:20:11 +00:00
|
|
|
public:
|
2018-01-27 14:16:15 -08:00
|
|
|
DtlsTransportTestBase() : client1_("P1"), client2_("P2"), use_dtls_(false) {}
|
2017-12-14 15:38:57 -08:00
|
|
|
|
2015-05-20 12:48:41 +02:00
|
|
|
void SetMaxProtocolVersions(rtc::SSLProtocolVersion c1,
|
|
|
|
|
rtc::SSLProtocolVersion c2) {
|
|
|
|
|
client1_.SetupMaxProtocolVersion(c1);
|
|
|
|
|
client2_.SetupMaxProtocolVersion(c2);
|
|
|
|
|
}
|
2017-12-14 15:38:57 -08:00
|
|
|
// If not called, DtlsTransport will be used in SRTP bypass mode.
|
|
|
|
|
void PrepareDtls(rtc::KeyType key_type) {
|
|
|
|
|
client1_.CreateCertificate(key_type);
|
|
|
|
|
client2_.CreateCertificate(key_type);
|
|
|
|
|
use_dtls_ = true;
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// This test negotiates DTLS parameters before the underlying transports are
|
|
|
|
|
// writable. DtlsEventOrderingTest is responsible for exercising differerent
|
|
|
|
|
// orderings.
|
|
|
|
|
bool Connect(bool client1_server = true) {
|
|
|
|
|
Negotiate(client1_server);
|
|
|
|
|
EXPECT_TRUE(client1_.Connect(&client2_, false));
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.dtls_transport()->writable() &&
|
|
|
|
|
client2_.dtls_transport()->writable(),
|
2017-01-19 16:54:25 -08:00
|
|
|
kTimeout, fake_clock_);
|
2017-12-14 15:38:57 -08:00
|
|
|
if (!client1_.dtls_transport()->writable() ||
|
|
|
|
|
!client2_.dtls_transport()->writable())
|
2014-10-28 22:20:11 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
// Check that we used the right roles.
|
|
|
|
|
if (use_dtls_) {
|
2017-12-14 15:38:57 -08:00
|
|
|
client1_.CheckRole(client1_server ? rtc::SSL_SERVER : rtc::SSL_CLIENT);
|
|
|
|
|
client2_.CheckRole(client1_server ? rtc::SSL_CLIENT : rtc::SSL_SERVER);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
Negotiate the same SRTP crypto suites for every DTLS association formed.
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
2017-04-21 03:23:33 -07:00
|
|
|
if (use_dtls_) {
|
|
|
|
|
// Check that we negotiated the right ciphers. Since GCM ciphers are not
|
2018-04-03 16:29:26 -07:00
|
|
|
// negotiated by default, we should end up with SRTP_AES128_CM_SHA1_80.
|
|
|
|
|
client1_.CheckSrtp(rtc::SRTP_AES128_CM_SHA1_80);
|
|
|
|
|
client2_.CheckSrtp(rtc::SRTP_AES128_CM_SHA1_80);
|
2014-10-28 22:20:11 +00:00
|
|
|
} else {
|
Negotiate the same SRTP crypto suites for every DTLS association formed.
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
2017-04-21 03:23:33 -07:00
|
|
|
// If DTLS isn't actually being used, GetSrtpCryptoSuite should return
|
|
|
|
|
// false.
|
2015-11-18 19:41:53 -08:00
|
|
|
client1_.CheckSrtp(rtc::SRTP_INVALID_CRYPTO_SUITE);
|
|
|
|
|
client2_.CheckSrtp(rtc::SRTP_INVALID_CRYPTO_SUITE);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
2016-03-11 00:06:47 -08:00
|
|
|
|
|
|
|
|
client1_.CheckSsl();
|
|
|
|
|
client2_.CheckSsl();
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
void Negotiate(bool client1_server = true) {
|
|
|
|
|
client1_.SetupTransports(ICEROLE_CONTROLLING);
|
|
|
|
|
client2_.SetupTransports(ICEROLE_CONTROLLED);
|
2018-02-22 15:26:27 -08:00
|
|
|
client1_.dtls_transport()->SetDtlsRole(client1_server ? rtc::SSL_SERVER
|
|
|
|
|
: rtc::SSL_CLIENT);
|
|
|
|
|
client2_.dtls_transport()->SetDtlsRole(client1_server ? rtc::SSL_CLIENT
|
|
|
|
|
: rtc::SSL_SERVER);
|
2017-12-14 15:38:57 -08:00
|
|
|
if (client2_.certificate()) {
|
|
|
|
|
SetRemoteFingerprintFromCert(client1_.dtls_transport(),
|
|
|
|
|
client2_.certificate());
|
|
|
|
|
}
|
|
|
|
|
if (client1_.certificate()) {
|
|
|
|
|
SetRemoteFingerprintFromCert(client2_.dtls_transport(),
|
|
|
|
|
client1_.certificate());
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
void TestTransfer(size_t size, size_t count, bool srtp) {
|
2017-11-09 11:09:25 +01:00
|
|
|
RTC_LOG(LS_INFO) << "Expect packets, size=" << size;
|
2017-12-14 15:38:57 -08:00
|
|
|
client2_.ExpectPackets(size);
|
|
|
|
|
client1_.SendPackets(size, count, srtp);
|
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
|
|
|
EXPECT_EQ_SIMULATED_WAIT(count, client2_.NumPacketsReceived(), kTimeout,
|
|
|
|
|
fake_clock_);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected:
|
2016-06-15 17:15:23 -07:00
|
|
|
rtc::ScopedFakeClock fake_clock_;
|
2014-10-28 22:20:11 +00:00
|
|
|
DtlsTestClient client1_;
|
|
|
|
|
DtlsTestClient client2_;
|
|
|
|
|
bool use_dtls_;
|
2015-05-20 12:48:41 +02:00
|
|
|
rtc::SSLProtocolVersion ssl_expected_version_;
|
2014-10-28 22:20:11 +00:00
|
|
|
};
|
|
|
|
|
|
2018-01-27 14:16:15 -08:00
|
|
|
class DtlsTransportTest : public DtlsTransportTestBase,
|
|
|
|
|
public ::testing::Test {};
|
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
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Connect without DTLS, and transfer RTP data.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferRtp) {
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, /*srtp=*/false);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Test that the SignalSentPacket signal is wired up.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestSignalSentPacket) {
|
2015-10-15 07:26:07 -07:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
// Sanity check default value (-1).
|
|
|
|
|
ASSERT_EQ(client1_.sent_packet().send_time_ms, -1);
|
|
|
|
|
TestTransfer(1000, 100, false);
|
|
|
|
|
// Check that we get the expected fake packet ID, and a time of 0 from the
|
|
|
|
|
// fake clock.
|
2015-10-15 07:26:07 -07:00
|
|
|
EXPECT_EQ(kFakePacketId, client1_.sent_packet().packet_id);
|
|
|
|
|
EXPECT_GE(client1_.sent_packet().send_time_ms, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
// Connect without DTLS, and transfer SRTP data.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferSrtp) {
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, /*srtp=*/true);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Connect with DTLS, and transfer data over DTLS.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtls) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, /*srtp=*/false);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-07-07 13:44:07 -07:00
|
|
|
// Connect with DTLS, combine multiple DTLS records into one packet.
|
|
|
|
|
// Our DTLS implementation doesn't do this, but other implementations may;
|
|
|
|
|
// see https://tools.ietf.org/html/rfc6347#section-4.1.1.
|
|
|
|
|
// This has caused interoperability problems with ORTCLib in the past.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtlsCombineRecords) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2017-07-07 13:44:07 -07:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
// Our DTLS implementation always sends one record per packet, so to simulate
|
|
|
|
|
// an endpoint that sends multiple records per packet, we configure the fake
|
|
|
|
|
// ICE transport to combine every two consecutive packets into a single
|
|
|
|
|
// packet.
|
2017-12-14 15:38:57 -08:00
|
|
|
FakeIceTransport* transport = client1_.fake_ice_transport();
|
2017-07-07 13:44:07 -07:00
|
|
|
transport->combine_outgoing_packets(true);
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(500, 100, /*srtp=*/false);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-27 14:16:15 -08:00
|
|
|
class DtlsTransportVersionTest
|
|
|
|
|
: public DtlsTransportTestBase,
|
2017-12-14 15:38:57 -08:00
|
|
|
public ::testing::TestWithParam<
|
|
|
|
|
::testing::tuple<rtc::SSLProtocolVersion, rtc::SSLProtocolVersion>> {
|
|
|
|
|
};
|
2015-05-20 12:48:41 +02:00
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Test that an acceptable cipher suite is negotiated when different versions
|
|
|
|
|
// of DTLS are supported. Note that it's IsAcceptableCipher that does the actual
|
|
|
|
|
// work.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_P(DtlsTransportVersionTest, TestCipherSuiteNegotiation) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
|
|
|
|
SetMaxProtocolVersions(::testing::get<0>(GetParam()),
|
|
|
|
|
::testing::get<1>(GetParam()));
|
2015-05-20 12:48:41 +02:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Will test every combination of 1.0/1.2 on the client and server.
|
2019-01-31 12:20:57 +01:00
|
|
|
INSTANTIATE_TEST_SUITE_P(
|
2017-12-14 15:38:57 -08:00
|
|
|
TestCipherSuiteNegotiation,
|
2018-01-27 14:16:15 -08:00
|
|
|
DtlsTransportVersionTest,
|
2017-12-14 15:38:57 -08:00
|
|
|
::testing::Combine(::testing::Values(rtc::SSL_PROTOCOL_DTLS_10,
|
|
|
|
|
rtc::SSL_PROTOCOL_DTLS_12),
|
|
|
|
|
::testing::Values(rtc::SSL_PROTOCOL_DTLS_10,
|
|
|
|
|
rtc::SSL_PROTOCOL_DTLS_12)));
|
2015-05-20 12:48:41 +02:00
|
|
|
|
Negotiate the same SRTP crypto suites for every DTLS association formed.
Before this CL, we would negotiate:
- No crypto suites for data m= sections.
- A full set for audio m= sections.
- The full set, minus SRTP_AES128_CM_SHA1_32 for video m= sections.
However, this doesn't make sense with BUNDLE, since any DTLS
association could end up being used for any type of media. If
video is "bundled on" the audio transport (which is typical), it
will actually end up using SRTP_AES128_CM_SHA1_32.
So, this CL moves the responsibility of deciding SRTP crypto suites out
of BaseChannel and into DtlsTransport. The only two possibilities are
now "normal set" or "normal set + GCM", if enabled by the PC factory
options.
This fixes an issue (see linked bug) that was occurring when audio/video
were "bundled onto" the data transport. Since the data transport
wasn't negotiating any SRTP crypto suites, none were available to use
for audio/video, so the application would get black video/no audio.
This CL doesn't affect the SDES SRTP crypto suite negotiation;
it only affects the negotiation in the DLTS handshake, through
the use_srtp extension.
BUG=chromium:711243
Review-Url: https://codereview.webrtc.org/2815513012
Cr-Commit-Position: refs/heads/master@{#17810}
2017-04-21 03:23:33 -07:00
|
|
|
// Connect with DTLS, negotiating DTLS-SRTP, and transfer SRTP using bypass.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtlsSrtp) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, /*srtp=*/true);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with DTLS-SRTP, transfer an invalid SRTP packet, and expects -1
|
|
|
|
|
// returned.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtlsInvalidSrtpPacket) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_EQ(-1, client1_.SendInvalidSrtpPacket(100));
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-27 14:16:15 -08:00
|
|
|
// Create a single transport with DTLS, and send normal data and SRTP data on
|
|
|
|
|
// it.
|
|
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtlsSrtpDemux) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, /*srtp=*/false);
|
|
|
|
|
TestTransfer(1000, 100, /*srtp=*/true);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Test transferring when the "answerer" has the server role.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestTransferDtlsSrtpAnswererIsPassive) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
|
|
|
|
ASSERT_TRUE(Connect(/*client1_server=*/false));
|
|
|
|
|
TestTransfer(1000, 100, /*srtp=*/true);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
// Test that renegotiation (setting same role and fingerprint again) can be
|
|
|
|
|
// started before the clients become connected in the first negotiation.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestRenegotiateBeforeConnect) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
|
|
|
|
// Note: This is doing the same thing Connect normally does, minus some
|
|
|
|
|
// additional checks not relevant for this test.
|
2014-10-28 22:20:11 +00:00
|
|
|
Negotiate();
|
2017-12-14 15:38:57 -08:00
|
|
|
Negotiate();
|
|
|
|
|
EXPECT_TRUE(client1_.Connect(&client2_, false));
|
|
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.dtls_transport()->writable() &&
|
|
|
|
|
client2_.dtls_transport()->writable(),
|
2017-01-19 16:54:25 -08:00
|
|
|
kTimeout, fake_clock_);
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, true);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test Certificates state after negotiation but before connection.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestCertificatesBeforeConnect) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
Negotiate();
|
|
|
|
|
|
|
|
|
|
// After negotiation, each side has a distinct local certificate, but still no
|
|
|
|
|
// remote certificate, because connection has not yet occurred.
|
2017-12-14 15:38:57 -08:00
|
|
|
auto certificate1 = client1_.dtls_transport()->GetLocalCertificate();
|
|
|
|
|
auto certificate2 = client2_.dtls_transport()->GetLocalCertificate();
|
2018-10-25 01:16:26 -07:00
|
|
|
ASSERT_NE(certificate1->GetSSLCertificate().ToPEMString(),
|
|
|
|
|
certificate2->GetSSLCertificate().ToPEMString());
|
2018-02-23 13:04:51 -08:00
|
|
|
ASSERT_FALSE(client1_.dtls_transport()->GetRemoteSSLCertChain());
|
|
|
|
|
ASSERT_FALSE(client2_.dtls_transport()->GetRemoteSSLCertChain());
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test Certificates state after connection.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestCertificatesAfterConnect) {
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
|
|
|
|
|
// After connection, each side has a distinct local certificate.
|
2017-12-14 15:38:57 -08:00
|
|
|
auto certificate1 = client1_.dtls_transport()->GetLocalCertificate();
|
|
|
|
|
auto certificate2 = client2_.dtls_transport()->GetLocalCertificate();
|
2018-10-25 01:16:26 -07:00
|
|
|
ASSERT_NE(certificate1->GetSSLCertificate().ToPEMString(),
|
|
|
|
|
certificate2->GetSSLCertificate().ToPEMString());
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
// Each side's remote certificate is the other side's local certificate.
|
2018-02-23 13:04:51 -08:00
|
|
|
std::unique_ptr<rtc::SSLCertChain> remote_cert1 =
|
|
|
|
|
client1_.dtls_transport()->GetRemoteSSLCertChain();
|
2016-04-06 05:15:06 -07:00
|
|
|
ASSERT_TRUE(remote_cert1);
|
2018-02-23 13:04:51 -08:00
|
|
|
ASSERT_EQ(1u, remote_cert1->GetSize());
|
|
|
|
|
ASSERT_EQ(remote_cert1->Get(0).ToPEMString(),
|
2018-10-25 01:16:26 -07:00
|
|
|
certificate2->GetSSLCertificate().ToPEMString());
|
2018-02-23 13:04:51 -08:00
|
|
|
std::unique_ptr<rtc::SSLCertChain> remote_cert2 =
|
|
|
|
|
client2_.dtls_transport()->GetRemoteSSLCertChain();
|
2016-04-06 05:15:06 -07:00
|
|
|
ASSERT_TRUE(remote_cert2);
|
2018-02-23 13:04:51 -08:00
|
|
|
ASSERT_EQ(1u, remote_cert2->GetSize());
|
|
|
|
|
ASSERT_EQ(remote_cert2->Get(0).ToPEMString(),
|
2018-10-25 01:16:26 -07:00
|
|
|
certificate1->GetSSLCertificate().ToPEMString());
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
2016-05-04 17:16:34 -07:00
|
|
|
|
2016-06-15 17:15:23 -07:00
|
|
|
// Test that packets are retransmitted according to the expected schedule.
|
|
|
|
|
// Each time a timeout occurs, the retransmission timer should be doubled up to
|
|
|
|
|
// 60 seconds. The timer defaults to 1 second, but for WebRTC we should be
|
|
|
|
|
// initializing it to 50ms.
|
2018-01-27 14:16:15 -08:00
|
|
|
TEST_F(DtlsTransportTest, TestRetransmissionSchedule) {
|
2016-06-15 17:15:23 -07:00
|
|
|
// We can only change the retransmission schedule with a recently-added
|
|
|
|
|
// BoringSSL API. Skip the test if not built with BoringSSL.
|
|
|
|
|
MAYBE_SKIP_TEST(IsBoringSsl);
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_DEFAULT);
|
|
|
|
|
// Exchange fingerprints and set SSL roles.
|
|
|
|
|
Negotiate();
|
2016-06-15 17:15:23 -07:00
|
|
|
|
|
|
|
|
// Make client2_ writable, but not client1_.
|
|
|
|
|
// This means client1_ will send DTLS client hellos but get no response.
|
|
|
|
|
EXPECT_TRUE(client2_.Connect(&client1_, true));
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client2_.fake_ice_transport()->writable(),
|
|
|
|
|
kTimeout, fake_clock_);
|
2016-06-15 17:15:23 -07:00
|
|
|
|
|
|
|
|
// Wait for the first client hello to be sent.
|
|
|
|
|
EXPECT_EQ_WAIT(1, client1_.received_dtls_client_hellos(), kTimeout);
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_FALSE(client1_.fake_ice_transport()->writable());
|
2016-06-15 17:15:23 -07:00
|
|
|
|
|
|
|
|
static int timeout_schedule_ms[] = {50, 100, 200, 400, 800, 1600,
|
|
|
|
|
3200, 6400, 12800, 25600, 51200, 60000};
|
|
|
|
|
|
|
|
|
|
int expected_hellos = 1;
|
|
|
|
|
for (size_t i = 0;
|
|
|
|
|
i < (sizeof(timeout_schedule_ms) / sizeof(timeout_schedule_ms[0]));
|
|
|
|
|
++i) {
|
|
|
|
|
// For each expected retransmission time, advance the fake clock a
|
|
|
|
|
// millisecond before the expected time and verify that no unexpected
|
|
|
|
|
// retransmissions were sent. Then advance it the final millisecond and
|
|
|
|
|
// verify that the expected retransmission was sent.
|
2018-05-08 14:52:22 +02:00
|
|
|
fake_clock_.AdvanceTime(webrtc::TimeDelta::ms(timeout_schedule_ms[i] - 1));
|
2016-06-15 17:15:23 -07:00
|
|
|
EXPECT_EQ(expected_hellos, client1_.received_dtls_client_hellos());
|
2018-05-08 14:52:22 +02:00
|
|
|
fake_clock_.AdvanceTime(webrtc::TimeDelta::ms(1));
|
2016-06-15 17:15:23 -07:00
|
|
|
EXPECT_EQ(++expected_hellos, client1_.received_dtls_client_hellos());
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-07-13 12:10:17 -07: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
|
|
|
// The following events can occur in many different orders:
|
|
|
|
|
// 1. Caller receives remote fingerprint.
|
|
|
|
|
// 2. Caller is writable.
|
|
|
|
|
// 3. Caller receives ClientHello.
|
|
|
|
|
// 4. DTLS handshake finishes.
|
|
|
|
|
//
|
|
|
|
|
// The tests below cover all causally consistent permutations of these events;
|
|
|
|
|
// the caller must be writable and receive a ClientHello before the handshake
|
|
|
|
|
// finishes, but otherwise any ordering is possible.
|
|
|
|
|
//
|
|
|
|
|
// For each permutation, the test verifies that a connection is established and
|
|
|
|
|
// fingerprint verified without any DTLS packet needing to be retransmitted.
|
|
|
|
|
//
|
|
|
|
|
// Each permutation is also tested with valid and invalid fingerprints,
|
|
|
|
|
// ensuring that the handshake fails with an invalid fingerprint.
|
|
|
|
|
enum DtlsTransportEvent {
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT,
|
|
|
|
|
CALLER_WRITABLE,
|
|
|
|
|
CALLER_RECEIVES_CLIENTHELLO,
|
|
|
|
|
HANDSHAKE_FINISHES
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class DtlsEventOrderingTest
|
2018-01-27 14:16:15 -08:00
|
|
|
: public DtlsTransportTestBase,
|
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
|
|
|
public ::testing::TestWithParam<
|
|
|
|
|
::testing::tuple<std::vector<DtlsTransportEvent>, bool>> {
|
|
|
|
|
protected:
|
|
|
|
|
// If |valid_fingerprint| is false, the caller will receive a fingerprint
|
|
|
|
|
// that doesn't match the callee's certificate, so the handshake should fail.
|
|
|
|
|
void TestEventOrdering(const std::vector<DtlsTransportEvent>& events,
|
|
|
|
|
bool valid_fingerprint) {
|
|
|
|
|
// Pre-setup: Set local certificate on both caller and callee, and
|
|
|
|
|
// remote fingerprint on callee, but neither is writable and the caller
|
|
|
|
|
// doesn't have the callee's fingerprint.
|
2017-12-14 15:38:57 -08:00
|
|
|
PrepareDtls(rtc::KT_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
|
|
|
// Simulate packets being sent and arriving asynchronously.
|
|
|
|
|
// Otherwise the entire DTLS handshake would occur in one clock tick, and
|
|
|
|
|
// we couldn't inject method calls in the middle of it.
|
|
|
|
|
int simulated_delay_ms = 10;
|
2017-12-14 15:38:57 -08:00
|
|
|
client1_.SetupTransports(ICEROLE_CONTROLLING, simulated_delay_ms);
|
|
|
|
|
client2_.SetupTransports(ICEROLE_CONTROLLED, simulated_delay_ms);
|
|
|
|
|
// Similar to how NegotiateOrdering works.
|
2018-02-22 15:26:27 -08:00
|
|
|
client1_.dtls_transport()->SetDtlsRole(rtc::SSL_SERVER);
|
|
|
|
|
client2_.dtls_transport()->SetDtlsRole(rtc::SSL_CLIENT);
|
2017-12-14 15:38:57 -08:00
|
|
|
SetRemoteFingerprintFromCert(client2_.dtls_transport(),
|
|
|
|
|
client1_.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
|
|
|
|
|
|
|
|
for (DtlsTransportEvent e : events) {
|
|
|
|
|
switch (e) {
|
|
|
|
|
case CALLER_RECEIVES_FINGERPRINT:
|
|
|
|
|
if (valid_fingerprint) {
|
2017-12-14 15:38:57 -08:00
|
|
|
SetRemoteFingerprintFromCert(client1_.dtls_transport(),
|
|
|
|
|
client2_.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
|
|
|
} else {
|
2017-12-14 15:38:57 -08:00
|
|
|
SetRemoteFingerprintFromCert(client1_.dtls_transport(),
|
|
|
|
|
client2_.certificate(),
|
|
|
|
|
true /*modify_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
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case CALLER_WRITABLE:
|
|
|
|
|
EXPECT_TRUE(client1_.Connect(&client2_, true));
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.fake_ice_transport()->writable(),
|
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
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
break;
|
|
|
|
|
case CALLER_RECEIVES_CLIENTHELLO:
|
|
|
|
|
// Sanity check that a ClientHello hasn't already been received.
|
|
|
|
|
EXPECT_EQ(0, client1_.received_dtls_client_hellos());
|
|
|
|
|
// Making client2_ writable will cause it to send the ClientHello.
|
|
|
|
|
EXPECT_TRUE(client2_.Connect(&client1_, true));
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client2_.fake_ice_transport()->writable(),
|
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
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
EXPECT_EQ_SIMULATED_WAIT(1, client1_.received_dtls_client_hellos(),
|
|
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
break;
|
|
|
|
|
case HANDSHAKE_FINISHES:
|
|
|
|
|
// Sanity check that the handshake hasn't already finished.
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_FALSE(client1_.dtls_transport()->IsDtlsConnected() ||
|
|
|
|
|
client1_.dtls_transport()->dtls_state() ==
|
|
|
|
|
DTLS_TRANSPORT_FAILED);
|
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
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(
|
2017-12-14 15:38:57 -08:00
|
|
|
client1_.dtls_transport()->IsDtlsConnected() ||
|
|
|
|
|
client1_.dtls_transport()->dtls_state() ==
|
|
|
|
|
DTLS_TRANSPORT_FAILED,
|
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
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-14 15:38:57 -08:00
|
|
|
DtlsTransportState expected_final_state =
|
|
|
|
|
valid_fingerprint ? DTLS_TRANSPORT_CONNECTED : DTLS_TRANSPORT_FAILED;
|
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
|
|
|
EXPECT_EQ_SIMULATED_WAIT(expected_final_state,
|
2017-12-14 15:38:57 -08:00
|
|
|
client1_.dtls_transport()->dtls_state(), kTimeout,
|
|
|
|
|
fake_clock_);
|
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
|
|
|
EXPECT_EQ_SIMULATED_WAIT(expected_final_state,
|
2017-12-14 15:38:57 -08:00
|
|
|
client2_.dtls_transport()->dtls_state(), kTimeout,
|
|
|
|
|
fake_clock_);
|
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
|
|
|
|
2018-01-27 14:16:15 -08:00
|
|
|
// Transports should be writable iff there was a valid fingerprint.
|
2017-12-14 15:38:57 -08:00
|
|
|
EXPECT_EQ(valid_fingerprint, client1_.dtls_transport()->writable());
|
|
|
|
|
EXPECT_EQ(valid_fingerprint, client2_.dtls_transport()->writable());
|
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
|
|
|
|
|
|
|
|
// Check that no hello needed to be retransmitted.
|
|
|
|
|
EXPECT_EQ(1, client1_.received_dtls_client_hellos());
|
|
|
|
|
EXPECT_EQ(1, client2_.received_dtls_server_hellos());
|
|
|
|
|
|
|
|
|
|
if (valid_fingerprint) {
|
2017-12-14 15:38:57 -08:00
|
|
|
TestTransfer(1000, 100, 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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TEST_P(DtlsEventOrderingTest, TestEventOrdering) {
|
|
|
|
|
TestEventOrdering(::testing::get<0>(GetParam()),
|
|
|
|
|
::testing::get<1>(GetParam()));
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-31 12:20:57 +01:00
|
|
|
INSTANTIATE_TEST_SUITE_P(
|
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
|
|
|
TestEventOrdering,
|
|
|
|
|
DtlsEventOrderingTest,
|
|
|
|
|
::testing::Combine(
|
|
|
|
|
::testing::Values(
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT, CALLER_WRITABLE,
|
|
|
|
|
CALLER_RECEIVES_CLIENTHELLO, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_WRITABLE, CALLER_RECEIVES_FINGERPRINT,
|
|
|
|
|
CALLER_RECEIVES_CLIENTHELLO, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_WRITABLE, CALLER_RECEIVES_CLIENTHELLO,
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_WRITABLE, CALLER_RECEIVES_CLIENTHELLO,
|
|
|
|
|
HANDSHAKE_FINISHES, CALLER_RECEIVES_FINGERPRINT},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT, CALLER_RECEIVES_CLIENTHELLO,
|
|
|
|
|
CALLER_WRITABLE, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_RECEIVES_CLIENTHELLO, CALLER_RECEIVES_FINGERPRINT,
|
|
|
|
|
CALLER_WRITABLE, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{
|
|
|
|
|
CALLER_RECEIVES_CLIENTHELLO, CALLER_WRITABLE,
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT, HANDSHAKE_FINISHES},
|
|
|
|
|
std::vector<DtlsTransportEvent>{CALLER_RECEIVES_CLIENTHELLO,
|
|
|
|
|
CALLER_WRITABLE, HANDSHAKE_FINISHES,
|
|
|
|
|
CALLER_RECEIVES_FINGERPRINT}),
|
|
|
|
|
::testing::Bool()));
|
2017-12-14 15:38:57 -08:00
|
|
|
|
|
|
|
|
} // namespace cricket
|