commit 042041bf9585f92e962387c59ca805f1218338f9
author Taylor Brandstetter <deadbeef@webrtc.org> Mon Sep 19 16:02:23 2016 -0700
committer Taylor Brandstetter <deadbeef@webrtc.org> Mon Sep 19 23:02:35 2016 +0000
tree d0eb2a7852088bef3a1efb6cece62295d5628ffe
parent e9cac751396d140e968192e763f540bd917cb551

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

Review URL: https://codereview.webrtc.org/2163683003 .

Cr-Commit-Position: refs/heads/master@{#14296}