deadbeef 89824f6fe0 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 18:55:49 +00:00
..
2016-09-29 00:42:08 +00:00
2016-09-29 00:42:08 +00:00
2015-04-02 10:31:00 +00:00
2016-08-23 12:54:31 +00:00
2016-09-29 00:42:08 +00:00
2016-09-29 00:42:08 +00:00
2016-09-29 00:42:08 +00:00
2015-12-28 22:07:05 +00:00
2015-12-28 22:07:05 +00:00
2016-09-29 00:42:08 +00:00
2015-05-21 11:50:41 +00:00
2015-05-21 11:50:41 +00:00
2015-04-01 22:25:29 +00:00
2016-08-16 13:38:23 +00:00
2016-07-01 20:59:39 +00:00
2016-07-01 10:45:29 +00:00
2016-02-02 16:34:16 +00:00
2016-04-28 12:14:30 +00:00
2015-09-22 18:58:13 +00:00
2016-01-04 21:44:16 +00:00