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}
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> This means the DTLS handshake can make progress while the SDP answer
> containing the fingerprint is still in transit. If the signaling path
> if significantly slower than the media path, this can have a moderate
> impact on call setup time.
>
> Of course, until the fingerprint is verified no media can be sent. Any
> attempted write will result in SR_BLOCK.
>
> This essentially fulfills the requirements of RFC 4572, Section 6.2:
>
> Note that when the offer/answer model is being used, it is possible
> for a media connection to outrace the answer back to the offerer.
> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
> role, it MUST (as specified in RFC 4145 [2]) begin listening for an
> incoming connection as soon as it sends its offer. However, it MUST
> NOT assume that the data transmitted over the TLS connection is valid
> until it has received a matching fingerprint in an SDP answer. If
> the fingerprint, once it arrives, does not match the client's
> certificate, the server endpoint MUST terminate the media connection
> with a bad_certificate error, as stated in the previous paragraph.
>
> BUG=webrtc:6387
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
R=mattdr@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2163683003 .
Cr-Commit-Position: refs/heads/master@{#14296}
GCM cipher suites are optional (disabled by default) and can be enabled
through "PeerConnectionFactoryInterface::Options".
If compiled with Chromium (i.e. "ENABLE_EXTERNAL_AUTH" is defined), no
GCM ciphers can be used yet (see https://crbug.com/628400).
BUG=webrtc:5222, 628400
Review-Url: https://codereview.webrtc.org/1528843005
Cr-Commit-Position: refs/heads/master@{#13635}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
This propagated into various other places. Also had to #include headers that
were implicitly pulled by "scoped_ptr.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1920043002
Cr-Commit-Position: refs/heads/master@{#12501}
Instead of using a raw pointer output parameter. This affects
SSLStreamAdapter::GetPeerCertificate
Transport::GetRemoteSSLCertificate
TransportChannel::GetRemoteSSLCertificate
TransportController::GetRemoteSSLCertificate
WebRtcSession::GetRemoteSSLCertificate
This is a good idea in general, but will also be very convenient when
scoped_ptr is gone, since unique_ptr doesn't have an .accept() method.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1802013002
Cr-Commit-Position: refs/heads/master@{#12262}
Instead of using a raw pointer output parameter. This is a good idea
in general, but will also be very convenient when scoped_ptr is gone,
since unique_ptr doesn't have an .accept() method.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1799233002
Cr-Commit-Position: refs/heads/master@{#12004}
The old code insists on exact cipher suite matches with hardwired expectations. It does this matching parameterized with key type (RSA vs ECDSA) and TLS version (DTLS vs TLS and version 1.0 vs 1.2).
This CL changes things to check against a white-list of cipher suites, with the check parameterized with key type (again RSA vs ECDSA). Then separately checks TLS version since the old implicit check of TLS version by means of resulting cipher suite was too blunt.
Using a white list for cipher suites isn't perfect, but it is safe and requires minimal maintenance. It allows compatibility with not just one exact version of underlying crypto lib, but any version with reasonable defaults.
The CL also re-enables critical tests which had to be disabled recently to allow a boringssl roll.
BUG=webrtc:5634
Review URL: https://codereview.webrtc.org/1774583002
Cr-Commit-Position: refs/heads/master@{#11951}
Macro incorrectly displays DISABLED_ON_ANDROID in test names for
parameterized tests under --gtest_list_tests, causing tests to be
disabled on all platforms since they contain the DISABLED_ prefix rather
than their expanded variants.
This expands the macro variants to inline if they're disabled or not,
and removes building some tests under configurations where they should
fail, instead of building them but disabling them by default.
The change also removes gtest_disable.h as an unused include from many
other files.
BUG=webrtc:5387, webrtc:5400
R=kjellander@webrtc.org, phoglund@webrtc.orgTBR=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1547343002 .
Cr-Commit-Position: refs/heads/master@{#11150}
We convert ASN1 time via std::tm to int64_t representing milliseconds-since-epoch. We do not use time_t since that cannot store milliseconds, and expires for 32-bit platforms in 2038 also for seconds.
Conversion via std::tm might might seem silly, but actually doesn't add any complexity.
One would expect tm -> seconds-since-epoch to already exist on the standard library. There is mktime, but it uses localtime (and sets an environment variable, and has the 2038 problem).
The ASN1 TIME parsing is limited to what is required by RFC 5280.
BUG=webrtc:5150
R=hbos@webrtc.org, nisse@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1468273004 .
Cr-Commit-Position: refs/heads/master@{#10854}
The tests were not honoring packet boundaries, thus causing failures
in tests with dropped/broken packets. This CL fixes this and also
re-enables the tests.
R=torbjorng@webrtc.org,pthatcher@webrtc.org,tommi@webrtc.org,juberti@webrtc.org
BUG=webrtc:5005,webrtc:5188
Review URL: https://codereview.webrtc.org/1440193002
Cr-Commit-Position: refs/heads/master@{#10709}
Reason for revert:
Broke chromium fyi build.
Original issue's description:
> Convert internal representation of Srtp cryptos from string to int.
>
> Note that the coversion from int to string happens in 3 places
> 1) SDP layer from int to external names. mediasession.cc GetSupportedSuiteNames.
> 2) for SSL_CTX_set_tlsext_use_srtp(), converting from int to internal names.
> 3) stats collection also needs external names.
>
> External names are like AES_CM_128_HMAC_SHA1_80, specified in sslstreamadapter.cc.
> Internal names are like SRTP_AES128_CM_SHA1_80, specified in opensslstreamadapter.cc.
>
> The conversion from string to int happens in one place only, SDP layer, SrtpFilter::ApplyParams().
>
> BUG=webrtc:5043
>
> Committed: https://crrev.com/2764e1027a08a5543e04b854a27a520801faf6eb
> Cr-Commit-Position: refs/heads/master@{#10701}
TBR=juberti@webrtc.org,pthatcher@webrtc.org,juberti@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5043
Review URL: https://codereview.webrtc.org/1455233005
Cr-Commit-Position: refs/heads/master@{#10702}
Note that the coversion from int to string happens in 3 places
1) SDP layer from int to external names. mediasession.cc GetSupportedSuiteNames.
2) for SSL_CTX_set_tlsext_use_srtp(), converting from int to internal names.
3) stats collection also needs external names.
External names are like AES_CM_128_HMAC_SHA1_80, specified in sslstreamadapter.cc.
Internal names are like SRTP_AES128_CM_SHA1_80, specified in opensslstreamadapter.cc.
The conversion from string to int happens in one place only, SDP layer, SrtpFilter::ApplyParams().
BUG=webrtc:5043
Review URL: https://codereview.webrtc.org/1416673006
Cr-Commit-Position: refs/heads/master@{#10701}
Reason for revert:
This broke chromium.fyi bot.
Original issue's description:
> Change WebRTC SslCipher to be exposed as number only.
>
> This makes the SSL exposed as uint16_t which is the IANA value. GetRfcSslCipherName is introduced to handle the conversion to names from ID. IANA value will be used for UMA reporting. Names will still be used for WebRTC stats reporting.
>
> For SRTP, currently it's still string internally but is reported as IANA number.
>
> This is used by the ongoing CL https://codereview.chromium.org/1335023002.
>
> BUG=523033
>
> Committed: https://crrev.com/4fe3c9a77386598db9abd1f0d6983aefee9cc943
> Cr-Commit-Position: refs/heads/master@{#10124}
TBR=juberti@webrtc.org,rsleevi@chromium.org,pthatcher@webrtc.org,davidben@chromium.org,juberti@google.com,davidben@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=523033
Review URL: https://codereview.webrtc.org/1380603005
Cr-Commit-Position: refs/heads/master@{#10125}
This makes the SSL exposed as uint16_t which is the IANA value. GetRfcSslCipherName is introduced to handle the conversion to names from ID. IANA value will be used for UMA reporting. Names will still be used for WebRTC stats reporting.
For SRTP, currently it's still string internally but is reported as IANA number.
This is used by the ongoing CL https://codereview.chromium.org/1335023002.
BUG=523033
Review URL: https://codereview.webrtc.org/1337673002
Cr-Commit-Position: refs/heads/master@{#10124}
Recent changes (https://codereview.chromium.org/1311013010) introduces a
dependency on WebKit (Blink) in Chromium, which forces us to start pulling
down that as well (+6GB). However Blink is about to be merged into the
Chromium repo soon anyway, so the size increase is inevitable.
Luckily, this can be removed in the next roll, if we roll past
http://crrev.com/348812
The ijar dependency was introduced in https://codereview.chromium.org/1323053003 (#347208)
Relevant changes:
* src/third_party/boringssl/src: 12fe1b2..ac8302a
* src/third_party/libvpx: a208eca..0304cef
* src/third_party/libyuv: 3c4f573..0bc626a
* src/tools/gyp: 6ee91ad..5d01a8c
Details: a28d8d5..5482f56/DEPS
Clang version was not updated in this roll.
R=torbjorng@webrtc.orgTBR=marpan@webrtc.org
BUG=webrtc:5005, chromium:530112
Review URL: https://codereview.webrtc.org/1305043008 .
Cr-Commit-Position: refs/heads/master@{#9956}
Reason for revert:
It looks like this broke the FYI bots. I tried updating libjingle_nacl.gyp, but the IOS build still failed because in Chrome it's configured to use NSS. See https://codereview.chromium.org/1316863012/.
Original issue's description:
> purge nss files and dependencies
>
> BUG=webrtc:4497
>
> Committed: https://crrev.com/5647a2cf3db888195c928a1259d98f72f6ecbc15
> Cr-Commit-Position: refs/heads/master@{#9862}
TBR=tommi@webrtc.org,kjellander@webrtc.org,torbjorng@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4497
Review URL: https://codereview.webrtc.org/1311843006
Cr-Commit-Position: refs/heads/master@{#9867}
This CL adds an API to SSL stream adapters to set the maximum allowed
protocol version and with that implements support for DTLS 1.2.
With DTLS 1.2 the default cipher changes in the unittests as follows.
BoringSSL
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA -> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
NSS
TLS_RSA_WITH_AES_128_CBC_SHA -> TLS_RSA_WITH_AES_128_GCM_SHA256
BUG=chromium:428343
R=juberti@google.com
Review URL: https://webrtc-codereview.appspot.com/50989004
Cr-Commit-Position: refs/heads/master@{#9232}
I'm reverting the patch due to compilation issues. It would be great if we could make sure Chromium is ready for the patch before we land it in WebRTC.
As is, we're trying to roll webrtc into Chromium and we can't (this is not the only reason though). I might reland this after the roll, depending on how that goes though.
Here's an example failure:
e:\b\build\slave\win_gn\build\src\jingle\glue\channel_socket_adapter_unittest.cc(77) : error C2259: 'jingle_glue::MockTransportChannel' : cannot instantiate abstract class
due to following members:
'bool cricket::TransportChannel::GetSslCipher(std::string *)' : is abstract
e:\b\build\slave\win_gn\build\src\third_party\webrtc\p2p\base\transportchannel.h(107) : see declaration of 'cricket::TransportChannel::GetSslCipher'
ninja: build stopped: subcommand failed.
> This CL adds an API to the SSL stream adapters and transport channels to get the SSL cipher that was negotiated with the remote peer.
>
> BUG=3976
> R=davidben@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/26009004TBR=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40689004
Cr-Commit-Position: refs/heads/master@{#8282}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8282 4adac7df-926f-26a2-2b94-8c16560cd09d
