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>
|
|
|
|
|
|
2017-09-15 06:47:31 +02:00
|
|
|
#include "p2p/base/dtlstransport.h"
|
|
|
|
|
#include "p2p/base/fakeicetransport.h"
|
|
|
|
|
#include "p2p/base/packettransportinternal.h"
|
|
|
|
|
#include "rtc_base/checks.h"
|
|
|
|
|
#include "rtc_base/dscp.h"
|
|
|
|
|
#include "rtc_base/gunit.h"
|
|
|
|
|
#include "rtc_base/helpers.h"
|
|
|
|
|
#include "rtc_base/ssladapter.h"
|
|
|
|
|
#include "rtc_base/sslidentity.h"
|
|
|
|
|
#include "rtc_base/sslstreamadapter.h"
|
|
|
|
|
#include "rtc_base/stringutils.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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char kIceUfrag1[] = "TESTICEUFRAG0001";
|
|
|
|
|
static const char kIcePwd1[] = "TESTICEPWD00000000000001";
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-04 17:16:34 -07:00
|
|
|
cricket::TransportDescription MakeTransportDescription(
|
|
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& cert,
|
|
|
|
|
cricket::ConnectionRole role) {
|
2016-05-14 19:44:11 -07:00
|
|
|
std::unique_ptr<rtc::SSLFingerprint> fingerprint;
|
2016-05-04 17:16:34 -07:00
|
|
|
if (cert) {
|
|
|
|
|
std::string digest_algorithm;
|
2016-07-13 12:10:17 -07:00
|
|
|
EXPECT_TRUE(
|
|
|
|
|
cert->ssl_certificate().GetSignatureDigestAlgorithm(&digest_algorithm));
|
|
|
|
|
EXPECT_FALSE(digest_algorithm.empty());
|
2016-05-04 17:16:34 -07:00
|
|
|
fingerprint.reset(
|
|
|
|
|
rtc::SSLFingerprint::Create(digest_algorithm, cert->identity()));
|
2016-07-13 12:10:17 -07:00
|
|
|
EXPECT_TRUE(fingerprint.get() != NULL);
|
|
|
|
|
EXPECT_EQ(rtc::DIGEST_SHA_256, digest_algorithm);
|
2016-05-04 17:16:34 -07:00
|
|
|
}
|
|
|
|
|
return cricket::TransportDescription(std::vector<std::string>(), kIceUfrag1,
|
|
|
|
|
kIcePwd1, cricket::ICEMODE_FULL, role,
|
|
|
|
|
fingerprint.get());
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
using cricket::ConnectionRole;
|
|
|
|
|
|
|
|
|
|
enum Flags { NF_REOFFER = 0x1, NF_EXPECT_FAILURE = 0x2 };
|
|
|
|
|
|
2016-12-06 16:22:06 -08:00
|
|
|
// TODO(deadbeef): Remove the dependency on JsepTransport. This test should be
|
|
|
|
|
// testing DtlsTransportChannel by itself, calling methods to set the
|
|
|
|
|
// configuration directly instead of negotiating TransportDescriptions.
|
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;
|
|
|
|
|
}
|
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 SetupChannels(int count, cricket::IceRole role, int async_delay_ms = 0) {
|
2016-12-06 16:22:06 -08:00
|
|
|
transport_.reset(
|
|
|
|
|
new cricket::JsepTransport("dtls content name", certificate_));
|
2016-12-06 15:28:55 -08:00
|
|
|
for (int i = 0; i < count; ++i) {
|
2017-01-12 15:58:31 -08:00
|
|
|
cricket::FakeIceTransport* fake_ice_channel =
|
|
|
|
|
new cricket::FakeIceTransport(transport_->mid(), i);
|
2016-12-06 16:22:06 -08:00
|
|
|
fake_ice_channel->SetAsync(true);
|
|
|
|
|
fake_ice_channel->SetAsyncDelay(async_delay_ms);
|
|
|
|
|
// Hook the raw packets so that we can verify they are encrypted.
|
|
|
|
|
fake_ice_channel->SignalReadPacket.connect(
|
|
|
|
|
this, &DtlsTestClient::OnFakeTransportChannelReadPacket);
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
cricket::DtlsTransport* dtls =
|
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
|
|
|
new cricket::DtlsTransport(fake_ice_channel, rtc::CryptoOptions());
|
2017-01-19 16:54:25 -08:00
|
|
|
dtls->SetLocalCertificate(certificate_);
|
|
|
|
|
dtls->ice_transport()->SetIceRole(role);
|
|
|
|
|
dtls->ice_transport()->SetIceTiebreaker(
|
|
|
|
|
(role == cricket::ICEROLE_CONTROLLING) ? 1 : 2);
|
|
|
|
|
dtls->SetSslMaxProtocolVersion(ssl_max_version_);
|
|
|
|
|
dtls->SignalWritableState.connect(
|
2017-11-13 13:26:07 -08:00
|
|
|
this, &DtlsTestClient::OnTransportWritableState);
|
|
|
|
|
dtls->SignalReadPacket.connect(this,
|
|
|
|
|
&DtlsTestClient::OnTransportReadPacket);
|
|
|
|
|
dtls->SignalSentPacket.connect(this,
|
|
|
|
|
&DtlsTestClient::OnTransportSentPacket);
|
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
|
|
|
dtls_transports_.push_back(std::unique_ptr<cricket::DtlsTransport>(dtls));
|
2017-01-19 16:54:25 -08:00
|
|
|
fake_ice_transports_.push_back(
|
2017-01-12 15:58:31 -08:00
|
|
|
std::unique_ptr<cricket::FakeIceTransport>(fake_ice_channel));
|
2017-01-19 16:54:25 -08:00
|
|
|
transport_->AddChannel(dtls, i);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-06 16:22:06 -08:00
|
|
|
cricket::JsepTransport* transport() { return transport_.get(); }
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
cricket::FakeIceTransport* GetFakeIceTransort(int component) {
|
|
|
|
|
for (const auto& ch : fake_ice_transports_) {
|
2016-12-06 16:22:06 -08:00
|
|
|
if (ch->component() == component) {
|
|
|
|
|
return ch.get();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
cricket::DtlsTransport* GetDtlsTransport(int component) {
|
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
|
|
|
for (const auto& dtls : dtls_transports_) {
|
2017-01-19 16:54:25 -08:00
|
|
|
if (dtls->component() == component) {
|
|
|
|
|
return dtls.get();
|
2016-12-06 16:22:06 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
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-10-28 22:20:11 +00:00
|
|
|
// Offer DTLS if we have an identity; pass in a remote fingerprint only if
|
|
|
|
|
// both sides support DTLS.
|
2017-08-23 18:05:50 -07:00
|
|
|
void Negotiate(DtlsTestClient* peer,
|
|
|
|
|
cricket::ContentAction action,
|
|
|
|
|
ConnectionRole local_role,
|
|
|
|
|
ConnectionRole remote_role,
|
2014-10-28 22:20:11 +00:00
|
|
|
int flags) {
|
2015-09-23 11:50:27 -07:00
|
|
|
Negotiate(certificate_, certificate_ ? peer->certificate_ : nullptr, action,
|
|
|
|
|
local_role, remote_role, flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
2016-07-13 12:10:17 -07:00
|
|
|
void SetLocalTransportDescription(
|
|
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& cert,
|
|
|
|
|
cricket::ContentAction action,
|
|
|
|
|
ConnectionRole role,
|
|
|
|
|
int flags) {
|
|
|
|
|
// If |NF_EXPECT_FAILURE| is set, expect SRTD or SLTD to fail when
|
|
|
|
|
// content action is CA_ANSWER.
|
|
|
|
|
bool expect_success =
|
|
|
|
|
!((action == cricket::CA_ANSWER) && (flags & NF_EXPECT_FAILURE));
|
|
|
|
|
EXPECT_EQ(expect_success,
|
|
|
|
|
transport_->SetLocalTransportDescription(
|
|
|
|
|
MakeTransportDescription(cert, role), action, nullptr));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SetRemoteTransportDescription(
|
|
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& cert,
|
|
|
|
|
cricket::ContentAction action,
|
|
|
|
|
ConnectionRole role,
|
|
|
|
|
int flags) {
|
|
|
|
|
// If |NF_EXPECT_FAILURE| is set, expect SRTD or SLTD to fail when
|
|
|
|
|
// content action is CA_ANSWER.
|
|
|
|
|
bool expect_success =
|
|
|
|
|
!((action == cricket::CA_ANSWER) && (flags & NF_EXPECT_FAILURE));
|
|
|
|
|
EXPECT_EQ(expect_success,
|
|
|
|
|
transport_->SetRemoteTransportDescription(
|
|
|
|
|
MakeTransportDescription(cert, role), action, nullptr));
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
// Allow any DTLS configuration to be specified (including invalid ones).
|
2015-08-27 10:12:24 +02:00
|
|
|
void Negotiate(const rtc::scoped_refptr<rtc::RTCCertificate>& local_cert,
|
|
|
|
|
const rtc::scoped_refptr<rtc::RTCCertificate>& remote_cert,
|
2014-10-28 22:20:11 +00:00
|
|
|
cricket::ContentAction action,
|
|
|
|
|
ConnectionRole local_role,
|
|
|
|
|
ConnectionRole remote_role,
|
|
|
|
|
int flags) {
|
|
|
|
|
if (action == cricket::CA_OFFER) {
|
2016-07-13 12:10:17 -07:00
|
|
|
SetLocalTransportDescription(local_cert, cricket::CA_OFFER, local_role,
|
|
|
|
|
flags);
|
|
|
|
|
SetRemoteTransportDescription(remote_cert, cricket::CA_ANSWER,
|
|
|
|
|
remote_role, flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
} else {
|
2016-07-13 12:10:17 -07:00
|
|
|
SetRemoteTransportDescription(remote_cert, cricket::CA_OFFER, remote_role,
|
|
|
|
|
flags);
|
|
|
|
|
// If remote if the offerer and has no DTLS support, answer will be
|
|
|
|
|
// without any fingerprint.
|
|
|
|
|
SetLocalTransportDescription(remote_cert ? local_cert : nullptr,
|
|
|
|
|
cricket::CA_ANSWER, local_role, flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-04 17:16:34 -07:00
|
|
|
bool Connect(DtlsTestClient* peer, bool asymmetric) {
|
2017-01-19 16:54:25 -08:00
|
|
|
for (auto& ice : fake_ice_transports_) {
|
|
|
|
|
ice->SetDestination(peer->GetFakeIceTransort(ice->component()),
|
|
|
|
|
asymmetric);
|
2016-12-06 16:22:06 -08:00
|
|
|
}
|
2014-10-28 22:20:11 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
bool all_dtls_transports_writable() const {
|
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_transports_.empty()) {
|
2015-09-30 10:32:59 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
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
|
|
|
for (const auto& dtls : dtls_transports_) {
|
2017-01-19 16:54:25 -08:00
|
|
|
if (!dtls->writable()) {
|
2015-09-30 10:32:59 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
2015-09-23 11:50:27 -07:00
|
|
|
}
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
bool all_ice_transports_writable() const {
|
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_transports_.empty()) {
|
2016-05-04 17:16:34 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
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
|
|
|
for (const auto& dtls : dtls_transports_) {
|
2017-01-19 16:54:25 -08:00
|
|
|
if (!dtls->ice_transport()->writable()) {
|
2016-05-04 17:16:34 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
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_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool negotiated_dtls() const {
|
|
|
|
|
return transport_->local_description() &&
|
|
|
|
|
transport_->local_description()->identity_fingerprint &&
|
|
|
|
|
transport_->remote_description() &&
|
|
|
|
|
transport_->remote_description()->identity_fingerprint;
|
|
|
|
|
}
|
2016-07-13 12:10:17 -07:00
|
|
|
|
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) {
|
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
|
|
|
for (const auto& dtls : dtls_transports_) {
|
2015-11-18 19:41:53 -08:00
|
|
|
int crypto_suite;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
bool rv = dtls->GetSrtpCryptoSuite(&crypto_suite);
|
2016-07-13 12:10:17 -07:00
|
|
|
if (negotiated_dtls() && expected_crypto_suite) {
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(rv);
|
|
|
|
|
|
2015-11-18 19:41:53 -08:00
|
|
|
ASSERT_EQ(crypto_suite, expected_crypto_suite);
|
2014-10-28 22:20:11 +00:00
|
|
|
} else {
|
|
|
|
|
ASSERT_FALSE(rv);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-11 00:06:47 -08:00
|
|
|
void CheckSsl() {
|
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
|
|
|
for (const auto& dtls : dtls_transports_) {
|
2015-10-05 12:43:27 -07:00
|
|
|
int cipher;
|
2015-02-11 22:34:36 +00:00
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
bool rv = dtls->GetSslCipherSuite(&cipher);
|
2016-07-13 12:10:17 -07:00
|
|
|
if (negotiated_dtls()) {
|
2015-02-11 22:34:36 +00:00
|
|
|
ASSERT_TRUE(rv);
|
|
|
|
|
|
2016-03-11 00:06:47 -08:00
|
|
|
EXPECT_TRUE(
|
|
|
|
|
rtc::SSLStreamAdapter::IsAcceptableCipher(cipher, rtc::KT_DEFAULT));
|
2015-02-11 22:34:36 +00:00
|
|
|
} else {
|
|
|
|
|
ASSERT_FALSE(rv);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
void SendPackets(size_t transport, size_t size, size_t count, bool srtp) {
|
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
|
|
|
RTC_CHECK(transport < dtls_transports_.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
|
|
|
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.
|
2015-08-27 10:12:24 +02:00
|
|
|
int flags = (certificate_ && srtp) ? cricket::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;
|
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
|
|
|
int rv = dtls_transports_[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-01-19 16:54:25 -08:00
|
|
|
int SendInvalidSrtpPacket(size_t transport, size_t size) {
|
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
|
|
|
RTC_CHECK(transport < dtls_transports_.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;
|
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
|
|
|
return dtls_transports_[transport]->SendPacket(
|
2014-10-28 22:20:11 +00:00
|
|
|
packet.get(), size, packet_options, cricket::PF_SRTP_BYPASS);
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
void ExpectPackets(size_t transport, 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
|
|
|
|
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,
|
|
|
|
|
const rtc::PacketTime& packet_time,
|
|
|
|
|
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 =
|
|
|
|
|
(certificate_ && IsRtpLeadByte(data[0])) ? cricket::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-02-10 11:31:50 -08:00
|
|
|
void OnFakeTransportChannelReadPacket(rtc::PacketTransportInternal* transport,
|
|
|
|
|
const char* data,
|
|
|
|
|
size_t size,
|
|
|
|
|
const rtc::PacketTime& time,
|
|
|
|
|
int flags) {
|
2014-10-28 22:20:11 +00:00
|
|
|
// Flags shouldn't be set on the underlying TransportChannel packets.
|
|
|
|
|
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_;
|
|
|
|
|
}
|
2016-07-13 12:10:17 -07:00
|
|
|
} else if (negotiated_dtls() && !(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-01-19 16:54:25 -08:00
|
|
|
std::vector<std::unique_ptr<cricket::FakeIceTransport>> fake_ice_transports_;
|
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
|
|
|
std::vector<std::unique_ptr<cricket::DtlsTransport>> dtls_transports_;
|
2016-12-06 16:22:06 -08:00
|
|
|
std::unique_ptr<cricket::JsepTransport> 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
|
|
|
};
|
|
|
|
|
|
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
|
|
|
// Base class for DtlsTransportChannelTest and DtlsEventOrderingTest, which
|
|
|
|
|
// inherit from different variants of testing::Test.
|
|
|
|
|
//
|
2016-06-15 17:15:23 -07:00
|
|
|
// Note that this test always uses a FakeClock, due to the |fake_clock_| member
|
|
|
|
|
// variable.
|
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
|
|
|
class DtlsTransportChannelTestBase {
|
2014-10-28 22:20:11 +00:00
|
|
|
public:
|
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
|
|
|
DtlsTransportChannelTestBase()
|
2015-09-23 11:50:27 -07:00
|
|
|
: client1_("P1"),
|
|
|
|
|
client2_("P2"),
|
|
|
|
|
channel_ct_(1),
|
|
|
|
|
use_dtls_(false),
|
2016-01-11 15:27:03 -08:00
|
|
|
ssl_expected_version_(rtc::SSL_PROTOCOL_DTLS_12) {}
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
void SetChannelCount(size_t channel_ct) {
|
|
|
|
|
channel_ct_ = static_cast<int>(channel_ct);
|
|
|
|
|
}
|
2015-05-20 12:48:41 +02:00
|
|
|
void SetMaxProtocolVersions(rtc::SSLProtocolVersion c1,
|
|
|
|
|
rtc::SSLProtocolVersion c2) {
|
|
|
|
|
client1_.SetupMaxProtocolVersion(c1);
|
|
|
|
|
client2_.SetupMaxProtocolVersion(c2);
|
|
|
|
|
ssl_expected_version_ = std::min(c1, c2);
|
|
|
|
|
}
|
2015-08-17 14:08:59 +02:00
|
|
|
void PrepareDtls(bool c1, bool c2, rtc::KeyType key_type) {
|
2014-10-28 22:20:11 +00:00
|
|
|
if (c1) {
|
2015-08-27 10:12:24 +02:00
|
|
|
client1_.CreateCertificate(key_type);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
if (c2) {
|
2015-08-27 10:12:24 +02:00
|
|
|
client2_.CreateCertificate(key_type);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
if (c1 && c2)
|
|
|
|
|
use_dtls_ = true;
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-13 12:10:17 -07:00
|
|
|
// Negotiate local/remote fingerprint before or after the underlying
|
|
|
|
|
// tranpsort is connected?
|
|
|
|
|
enum NegotiateOrdering { NEGOTIATE_BEFORE_CONNECT, CONNECT_BEFORE_NEGOTIATE };
|
|
|
|
|
bool Connect(ConnectionRole client1_role,
|
|
|
|
|
ConnectionRole client2_role,
|
|
|
|
|
NegotiateOrdering ordering = NEGOTIATE_BEFORE_CONNECT) {
|
|
|
|
|
bool rv;
|
|
|
|
|
if (ordering == NEGOTIATE_BEFORE_CONNECT) {
|
|
|
|
|
Negotiate(client1_role, client2_role);
|
|
|
|
|
rv = client1_.Connect(&client2_, false);
|
|
|
|
|
} else {
|
|
|
|
|
client1_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLING);
|
|
|
|
|
client2_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLED);
|
|
|
|
|
// This is equivalent to an offer being processed on both sides, but an
|
|
|
|
|
// answer not yet being received on the initiating side. So the
|
|
|
|
|
// connection will be made before negotiation has finished on both sides.
|
|
|
|
|
client1_.SetLocalTransportDescription(client1_.certificate(),
|
|
|
|
|
cricket::CA_OFFER, client1_role, 0);
|
|
|
|
|
client2_.SetRemoteTransportDescription(
|
|
|
|
|
client1_.certificate(), cricket::CA_OFFER, client1_role, 0);
|
|
|
|
|
client2_.SetLocalTransportDescription(
|
|
|
|
|
client2_.certificate(), cricket::CA_ANSWER, client2_role, 0);
|
|
|
|
|
rv = client1_.Connect(&client2_, false);
|
|
|
|
|
client1_.SetRemoteTransportDescription(
|
|
|
|
|
client2_.certificate(), cricket::CA_ANSWER, client2_role, 0);
|
|
|
|
|
}
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
EXPECT_TRUE(rv);
|
|
|
|
|
if (!rv)
|
|
|
|
|
return false;
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.all_dtls_transports_writable() &&
|
|
|
|
|
client2_.all_dtls_transports_writable(),
|
|
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
if (!client1_.all_dtls_transports_writable() ||
|
|
|
|
|
!client2_.all_dtls_transports_writable())
|
2014-10-28 22:20:11 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
// Check that we used the right roles.
|
|
|
|
|
if (use_dtls_) {
|
|
|
|
|
rtc::SSLRole client1_ssl_role =
|
|
|
|
|
(client1_role == cricket::CONNECTIONROLE_ACTIVE ||
|
|
|
|
|
(client2_role == cricket::CONNECTIONROLE_PASSIVE &&
|
2017-08-23 18:05:50 -07:00
|
|
|
client1_role == cricket::CONNECTIONROLE_ACTPASS))
|
|
|
|
|
? rtc::SSL_CLIENT
|
|
|
|
|
: rtc::SSL_SERVER;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
rtc::SSLRole client2_ssl_role =
|
|
|
|
|
(client2_role == cricket::CONNECTIONROLE_ACTIVE ||
|
|
|
|
|
(client1_role == cricket::CONNECTIONROLE_PASSIVE &&
|
2017-08-23 18:05:50 -07:00
|
|
|
client2_role == cricket::CONNECTIONROLE_ACTPASS))
|
|
|
|
|
? rtc::SSL_CLIENT
|
|
|
|
|
: rtc::SSL_SERVER;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
client1_.CheckRole(client1_ssl_role);
|
|
|
|
|
client2_.CheckRole(client2_ssl_role);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
// negotiated by default, we should end up with SRTP_AES128_CM_SHA1_32.
|
|
|
|
|
client1_.CheckSrtp(rtc::SRTP_AES128_CM_SHA1_32);
|
|
|
|
|
client2_.CheckSrtp(rtc::SRTP_AES128_CM_SHA1_32);
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Connect() {
|
|
|
|
|
// By default, Client1 will be Server and Client2 will be Client.
|
|
|
|
|
return Connect(cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Negotiate() {
|
|
|
|
|
Negotiate(cricket::CONNECTIONROLE_ACTPASS, cricket::CONNECTIONROLE_ACTIVE);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Negotiate(ConnectionRole client1_role, ConnectionRole client2_role) {
|
|
|
|
|
client1_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLING);
|
|
|
|
|
client2_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLED);
|
|
|
|
|
// Expect success from SLTD and SRTD.
|
2017-08-23 18:05:50 -07:00
|
|
|
client1_.Negotiate(&client2_, cricket::CA_OFFER, client1_role, client2_role,
|
|
|
|
|
0);
|
|
|
|
|
client2_.Negotiate(&client1_, cricket::CA_ANSWER, client2_role,
|
|
|
|
|
client1_role, 0);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Negotiate with legacy client |client2|. Legacy client doesn't use setup
|
|
|
|
|
// attributes, except NONE.
|
|
|
|
|
void NegotiateWithLegacy() {
|
|
|
|
|
client1_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLING);
|
|
|
|
|
client2_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLED);
|
|
|
|
|
// Expect success from SLTD and SRTD.
|
|
|
|
|
client1_.Negotiate(&client2_, cricket::CA_OFFER,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_NONE, 0);
|
|
|
|
|
client2_.Negotiate(&client1_, cricket::CA_ANSWER,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE,
|
|
|
|
|
cricket::CONNECTIONROLE_NONE, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Renegotiate(DtlsTestClient* reoffer_initiator,
|
2017-08-23 18:05:50 -07:00
|
|
|
ConnectionRole client1_role,
|
|
|
|
|
ConnectionRole client2_role,
|
2014-10-28 22:20:11 +00:00
|
|
|
int flags) {
|
|
|
|
|
if (reoffer_initiator == &client1_) {
|
2017-08-23 18:05:50 -07:00
|
|
|
client1_.Negotiate(&client2_, cricket::CA_OFFER, client1_role,
|
|
|
|
|
client2_role, flags);
|
|
|
|
|
client2_.Negotiate(&client1_, cricket::CA_ANSWER, client2_role,
|
|
|
|
|
client1_role, flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
} else {
|
2017-08-23 18:05:50 -07:00
|
|
|
client2_.Negotiate(&client1_, cricket::CA_OFFER, client2_role,
|
|
|
|
|
client1_role, flags);
|
|
|
|
|
client1_.Negotiate(&client2_, cricket::CA_ANSWER, client1_role,
|
|
|
|
|
client2_role, flags);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-01-19 16:54:25 -08:00
|
|
|
void TestTransfer(size_t transport, 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-01-19 16:54:25 -08:00
|
|
|
client2_.ExpectPackets(transport, size);
|
|
|
|
|
client1_.SendPackets(transport, 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_;
|
|
|
|
|
int channel_ct_;
|
|
|
|
|
bool use_dtls_;
|
2015-05-20 12:48:41 +02:00
|
|
|
rtc::SSLProtocolVersion ssl_expected_version_;
|
2014-10-28 22:20:11 +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
|
|
|
class DtlsTransportChannelTest : public DtlsTransportChannelTestBase,
|
|
|
|
|
public ::testing::Test {};
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
// Test that transport negotiation of ICE, no DTLS works properly.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestChannelSetupIce) {
|
|
|
|
|
Negotiate();
|
2017-01-19 16:54:25 -08:00
|
|
|
cricket::FakeIceTransport* channel1 = client1_.GetFakeIceTransort(0);
|
|
|
|
|
cricket::FakeIceTransport* channel2 = client2_.GetFakeIceTransort(0);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(channel1 != NULL);
|
|
|
|
|
ASSERT_TRUE(channel2 != NULL);
|
|
|
|
|
EXPECT_EQ(cricket::ICEROLE_CONTROLLING, channel1->GetIceRole());
|
|
|
|
|
EXPECT_EQ(1U, channel1->IceTiebreaker());
|
|
|
|
|
EXPECT_EQ(kIceUfrag1, channel1->ice_ufrag());
|
|
|
|
|
EXPECT_EQ(kIcePwd1, channel1->ice_pwd());
|
|
|
|
|
EXPECT_EQ(cricket::ICEROLE_CONTROLLED, channel2->GetIceRole());
|
|
|
|
|
EXPECT_EQ(2U, channel2->IceTiebreaker());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect without DTLS, and transfer some data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransfer) {
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-15 07:26:07 -07:00
|
|
|
// Connect without DTLS, and transfer some data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestOnSentPacket) {
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
EXPECT_EQ(client1_.sent_packet().send_time_ms, -1);
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
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
|
|
|
// Create two channels without DTLS, and transfer some data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferTwoChannels) {
|
|
|
|
|
SetChannelCount(2);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
TestTransfer(1, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect without DTLS, and transfer SRTP data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferSrtp) {
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels without DTLS, and transfer SRTP data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferSrtpTwoChannels) {
|
|
|
|
|
SetChannelCount(2);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with DTLS, and transfer some data.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtls) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels with DTLS, and transfer some data.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsTwoChannels) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
TestTransfer(1, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsCombineRecords) {
|
|
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
|
|
|
|
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.
|
|
|
|
|
cricket::FakeIceTransport* transport = client1_.GetFakeIceTransort(0);
|
|
|
|
|
transport->combine_outgoing_packets(true);
|
|
|
|
|
TestTransfer(0, 500, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-28 22:20:11 +00:00
|
|
|
// Connect with A doing DTLS and B not, and transfer some data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsRejected) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, false, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with B doing DTLS and A not, and transfer some data.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsNotOffered) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(false, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-20 12:48:41 +02:00
|
|
|
// Create two channels with DTLS 1.0 and check ciphers.
|
2016-03-11 00:06:47 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtls12None) {
|
2015-05-20 12:48:41 +02:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2015-05-20 12:48:41 +02:00
|
|
|
SetMaxProtocolVersions(rtc::SSL_PROTOCOL_DTLS_10, rtc::SSL_PROTOCOL_DTLS_10);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels with DTLS 1.2 and check ciphers.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtls12Both) {
|
2015-05-20 12:48:41 +02:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2015-05-20 12:48:41 +02:00
|
|
|
SetMaxProtocolVersions(rtc::SSL_PROTOCOL_DTLS_12, rtc::SSL_PROTOCOL_DTLS_12);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels with DTLS 1.0 / DTLS 1.2 and check ciphers.
|
2016-03-11 00:06:47 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtls12Client1) {
|
2015-05-20 12:48:41 +02:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2015-05-20 12:48:41 +02:00
|
|
|
SetMaxProtocolVersions(rtc::SSL_PROTOCOL_DTLS_12, rtc::SSL_PROTOCOL_DTLS_10);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels with DTLS 1.2 / DTLS 1.0 and check ciphers.
|
2016-03-11 00:06:47 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtls12Client2) {
|
2015-05-20 12:48:41 +02:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2015-05-20 12:48:41 +02:00
|
|
|
SetMaxProtocolVersions(rtc::SSL_PROTOCOL_DTLS_10, rtc::SSL_PROTOCOL_DTLS_12);
|
|
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsSrtp) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with DTLS-SRTP, transfer an invalid SRTP packet, and expects -1
|
|
|
|
|
// returned.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsInvalidSrtpPacket) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
int result = client1_.SendInvalidSrtpPacket(0, 100);
|
|
|
|
|
ASSERT_EQ(-1, result);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with DTLS. A does DTLS-SRTP but B does not.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsSrtpRejected) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Connect with DTLS. B does DTLS-SRTP but A does not.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsSrtpNotOffered) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create two channels with DTLS, negotiate DTLS-SRTP, and transfer bypass SRTP.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsSrtpTwoChannels) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Create a single channel with DTLS, and send normal data and SRTP data on it.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsSrtpDemux) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Testing when the remote is passive.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestTransferDtlsAnswererIsPassive) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect(cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_PASSIVE));
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Testing with the legacy DTLS client which doesn't use setup attribute.
|
|
|
|
|
// In this case legacy is the answerer.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtlsSetupWithLegacyAsAnswerer) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
NegotiateWithLegacy();
|
2017-03-27 10:33:26 -07:00
|
|
|
EXPECT_EQ(rtc::SSL_SERVER, *client1_.transport()->GetSslRole());
|
|
|
|
|
EXPECT_EQ(rtc::SSL_CLIENT, *client2_.transport()->GetSslRole());
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Testing re offer/answer after the session is estbalished. Roles will be
|
|
|
|
|
// kept same as of the previous negotiation.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtlsReOfferFromOfferer) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
// Initial role for client1 is ACTPASS and client2 is ACTIVE.
|
2017-08-23 18:05:50 -07:00
|
|
|
ASSERT_TRUE(
|
|
|
|
|
Connect(cricket::CONNECTIONROLE_ACTPASS, cricket::CONNECTIONROLE_ACTIVE));
|
2014-10-28 22:20:11 +00:00
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
// Using input roles for the re-offer.
|
|
|
|
|
Renegotiate(&client1_, cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE, NF_REOFFER);
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtlsReOfferFromAnswerer) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
// Initial role for client1 is ACTPASS and client2 is ACTIVE.
|
2017-08-23 18:05:50 -07:00
|
|
|
ASSERT_TRUE(
|
|
|
|
|
Connect(cricket::CONNECTIONROLE_ACTPASS, cricket::CONNECTIONROLE_ACTIVE));
|
2014-10-28 22:20:11 +00:00
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
// Using input roles for the re-offer.
|
|
|
|
|
Renegotiate(&client2_, cricket::CONNECTIONROLE_PASSIVE,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTPASS, NF_REOFFER);
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that any change in role after the intial setup will result in failure.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtlsRoleReversal) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect(cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_PASSIVE));
|
|
|
|
|
|
|
|
|
|
// Renegotiate from client2 with actpass and client1 as active.
|
|
|
|
|
Renegotiate(&client2_, cricket::CONNECTIONROLE_ACTPASS,
|
2017-08-23 18:05:50 -07:00
|
|
|
cricket::CONNECTIONROLE_ACTIVE, NF_REOFFER | NF_EXPECT_FAILURE);
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that using different setup attributes which results in similar ssl
|
|
|
|
|
// role as the initial negotiation will result in success.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestDtlsReOfferWithDifferentSetupAttr) {
|
2014-10-28 22:20:11 +00:00
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect(cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_PASSIVE));
|
|
|
|
|
// Renegotiate from client2 with actpass and client1 as active.
|
|
|
|
|
Renegotiate(&client2_, cricket::CONNECTIONROLE_ACTIVE,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTPASS, NF_REOFFER);
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that re-negotiation can be started before the clients become connected
|
|
|
|
|
// in the first negotiation.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestRenegotiateBeforeConnect) {
|
|
|
|
|
SetChannelCount(2);
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
Negotiate();
|
|
|
|
|
|
|
|
|
|
Renegotiate(&client1_, cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE, NF_REOFFER);
|
2016-05-04 17:16:34 -07:00
|
|
|
bool rv = client1_.Connect(&client2_, false);
|
2014-10-28 22:20:11 +00:00
|
|
|
EXPECT_TRUE(rv);
|
2017-01-19 16:54:25 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.all_dtls_transports_writable() &&
|
|
|
|
|
client2_.all_dtls_transports_writable(),
|
|
|
|
|
kTimeout, fake_clock_);
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
TestTransfer(0, 1000, 100, true);
|
|
|
|
|
TestTransfer(1, 1000, 100, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test Certificates state after negotiation but before connection.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestCertificatesBeforeConnect) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
Negotiate();
|
|
|
|
|
|
2015-08-27 10:12:24 +02:00
|
|
|
rtc::scoped_refptr<rtc::RTCCertificate> certificate1;
|
|
|
|
|
rtc::scoped_refptr<rtc::RTCCertificate> certificate2;
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<rtc::SSLCertificate> remote_cert1;
|
|
|
|
|
std::unique_ptr<rtc::SSLCertificate> remote_cert2;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
// After negotiation, each side has a distinct local certificate, but still no
|
|
|
|
|
// remote certificate, because connection has not yet occurred.
|
2015-09-23 11:50:27 -07:00
|
|
|
ASSERT_TRUE(client1_.transport()->GetLocalCertificate(&certificate1));
|
|
|
|
|
ASSERT_TRUE(client2_.transport()->GetLocalCertificate(&certificate2));
|
2015-08-27 10:12:24 +02:00
|
|
|
ASSERT_NE(certificate1->ssl_certificate().ToPEMString(),
|
|
|
|
|
certificate2->ssl_certificate().ToPEMString());
|
2017-01-19 16:54:25 -08:00
|
|
|
ASSERT_FALSE(client1_.GetDtlsTransport(0)->GetRemoteSSLCertificate());
|
|
|
|
|
ASSERT_FALSE(client2_.GetDtlsTransport(0)->GetRemoteSSLCertificate());
|
2014-10-28 22:20:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test Certificates state after connection.
|
2016-01-15 07:16:51 -08:00
|
|
|
TEST_F(DtlsTransportChannelTest, TestCertificatesAfterConnect) {
|
2015-08-17 14:08:59 +02:00
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_TRUE(Connect());
|
|
|
|
|
|
2015-08-27 10:12:24 +02:00
|
|
|
rtc::scoped_refptr<rtc::RTCCertificate> certificate1;
|
|
|
|
|
rtc::scoped_refptr<rtc::RTCCertificate> certificate2;
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
// After connection, each side has a distinct local certificate.
|
2015-09-23 11:50:27 -07:00
|
|
|
ASSERT_TRUE(client1_.transport()->GetLocalCertificate(&certificate1));
|
|
|
|
|
ASSERT_TRUE(client2_.transport()->GetLocalCertificate(&certificate2));
|
2015-08-27 10:12:24 +02:00
|
|
|
ASSERT_NE(certificate1->ssl_certificate().ToPEMString(),
|
|
|
|
|
certificate2->ssl_certificate().ToPEMString());
|
2014-10-28 22:20:11 +00:00
|
|
|
|
|
|
|
|
// Each side's remote certificate is the other side's local certificate.
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<rtc::SSLCertificate> remote_cert1 =
|
2017-01-19 16:54:25 -08:00
|
|
|
client1_.GetDtlsTransport(0)->GetRemoteSSLCertificate();
|
2016-04-06 05:15:06 -07:00
|
|
|
ASSERT_TRUE(remote_cert1);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_EQ(remote_cert1->ToPEMString(),
|
2015-08-27 10:12:24 +02:00
|
|
|
certificate2->ssl_certificate().ToPEMString());
|
2016-04-26 03:13:22 -07:00
|
|
|
std::unique_ptr<rtc::SSLCertificate> remote_cert2 =
|
2017-01-19 16:54:25 -08:00
|
|
|
client2_.GetDtlsTransport(0)->GetRemoteSSLCertificate();
|
2016-04-06 05:15:06 -07:00
|
|
|
ASSERT_TRUE(remote_cert2);
|
2014-10-28 22:20:11 +00:00
|
|
|
ASSERT_EQ(remote_cert2->ToPEMString(),
|
2015-08-27 10:12:24 +02:00
|
|
|
certificate1->ssl_certificate().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.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestRetransmissionSchedule) {
|
|
|
|
|
// 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);
|
|
|
|
|
|
|
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
|
|
|
|
// Exchange transport descriptions.
|
|
|
|
|
Negotiate(cricket::CONNECTIONROLE_ACTPASS, cricket::CONNECTIONROLE_ACTIVE);
|
|
|
|
|
|
|
|
|
|
// 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-01-19 16:54:25 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client2_.all_ice_transports_writable(), kTimeout,
|
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
|
|
|
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-01-19 16:54:25 -08:00
|
|
|
EXPECT_FALSE(client1_.all_ice_transports_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.
|
|
|
|
|
fake_clock_.AdvanceTime(
|
|
|
|
|
rtc::TimeDelta::FromMilliseconds(timeout_schedule_ms[i] - 1));
|
|
|
|
|
EXPECT_EQ(expected_hellos, client1_.received_dtls_client_hellos());
|
|
|
|
|
fake_clock_.AdvanceTime(rtc::TimeDelta::FromMilliseconds(1));
|
|
|
|
|
EXPECT_EQ(++expected_hellos, client1_.received_dtls_client_hellos());
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-07-13 12:10:17 -07:00
|
|
|
|
|
|
|
|
// Test that a DTLS connection can be made even if the underlying transport
|
|
|
|
|
// is connected before DTLS fingerprints/roles have been negotiated.
|
|
|
|
|
TEST_F(DtlsTransportChannelTest, TestConnectBeforeNegotiate) {
|
|
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
|
|
|
|
ASSERT_TRUE(Connect(cricket::CONNECTIONROLE_ACTPASS,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE,
|
|
|
|
|
CONNECT_BEFORE_NEGOTIATE));
|
|
|
|
|
TestTransfer(0, 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
|
|
|
|
|
|
|
|
// 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
|
|
|
|
|
: public DtlsTransportChannelTestBase,
|
|
|
|
|
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.
|
|
|
|
|
PrepareDtls(true, true, rtc::KT_DEFAULT);
|
|
|
|
|
// 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;
|
|
|
|
|
client1_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLING,
|
|
|
|
|
simulated_delay_ms);
|
|
|
|
|
client2_.SetupChannels(channel_ct_, cricket::ICEROLE_CONTROLLED,
|
|
|
|
|
simulated_delay_ms);
|
|
|
|
|
client1_.SetLocalTransportDescription(client1_.certificate(),
|
|
|
|
|
cricket::CA_OFFER,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTPASS, 0);
|
|
|
|
|
client2_.Negotiate(&client1_, cricket::CA_ANSWER,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTPASS, 0);
|
|
|
|
|
|
|
|
|
|
for (DtlsTransportEvent e : events) {
|
|
|
|
|
switch (e) {
|
|
|
|
|
case CALLER_RECEIVES_FINGERPRINT:
|
|
|
|
|
if (valid_fingerprint) {
|
|
|
|
|
client1_.SetRemoteTransportDescription(
|
|
|
|
|
client2_.certificate(), cricket::CA_ANSWER,
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE, 0);
|
|
|
|
|
} else {
|
|
|
|
|
// Create a fingerprint with a correct algorithm but an invalid
|
|
|
|
|
// digest.
|
|
|
|
|
cricket::TransportDescription remote_desc =
|
|
|
|
|
MakeTransportDescription(client2_.certificate(),
|
|
|
|
|
cricket::CONNECTIONROLE_ACTIVE);
|
|
|
|
|
++(remote_desc.identity_fingerprint->digest[0]);
|
|
|
|
|
// Even if certificate verification fails inside this method,
|
|
|
|
|
// it should return true as long as the fingerprint was formatted
|
|
|
|
|
// correctly.
|
|
|
|
|
EXPECT_TRUE(client1_.transport()->SetRemoteTransportDescription(
|
|
|
|
|
remote_desc, cricket::CA_ANSWER, nullptr));
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case CALLER_WRITABLE:
|
|
|
|
|
EXPECT_TRUE(client1_.Connect(&client2_, true));
|
2017-01-19 16:54:25 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client1_.all_ice_transports_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-01-19 16:54:25 -08:00
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(client2_.all_ice_transports_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-01-19 16:54:25 -08:00
|
|
|
EXPECT_FALSE(client1_.GetDtlsTransport(0)->IsDtlsConnected() ||
|
|
|
|
|
client1_.GetDtlsTransport(0)->dtls_state() ==
|
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
|
|
|
cricket::DTLS_TRANSPORT_FAILED);
|
|
|
|
|
EXPECT_TRUE_SIMULATED_WAIT(
|
2017-01-19 16:54:25 -08:00
|
|
|
client1_.GetDtlsTransport(0)->IsDtlsConnected() ||
|
|
|
|
|
client1_.GetDtlsTransport(0)->dtls_state() ==
|
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
|
|
|
cricket::DTLS_TRANSPORT_FAILED,
|
|
|
|
|
kTimeout, fake_clock_);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cricket::DtlsTransportState expected_final_state =
|
|
|
|
|
valid_fingerprint ? cricket::DTLS_TRANSPORT_CONNECTED
|
|
|
|
|
: cricket::DTLS_TRANSPORT_FAILED;
|
|
|
|
|
EXPECT_EQ_SIMULATED_WAIT(expected_final_state,
|
2017-01-19 16:54:25 -08:00
|
|
|
client1_.GetDtlsTransport(0)->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-01-19 16:54:25 -08:00
|
|
|
client2_.GetDtlsTransport(0)->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
|
|
|
|
|
|
|
|
// Channel should be writable iff there was a valid fingerprint.
|
2017-01-19 16:54:25 -08:00
|
|
|
EXPECT_EQ(valid_fingerprint, client1_.GetDtlsTransport(0)->writable());
|
|
|
|
|
EXPECT_EQ(valid_fingerprint, client2_.GetDtlsTransport(0)->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) {
|
|
|
|
|
TestTransfer(0, 1000, 100, false);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
TEST_P(DtlsEventOrderingTest, TestEventOrdering) {
|
|
|
|
|
TestEventOrdering(::testing::get<0>(GetParam()),
|
|
|
|
|
::testing::get<1>(GetParam()));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
INSTANTIATE_TEST_CASE_P(
|
|
|
|
|
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()));
|