|author||David Benjamin <email@example.com>||Mon Nov 02 17:16:13 2015 -0500|
|committer||Adam Langley <firstname.lastname@example.org>||Mon Nov 02 23:16:22 2015 +0000|
Fix DTLS asynchronous write handling. Although the DTLS transport layer logic drops failed writes on the floor, it is actually set up to work correctly. If an SSL_write fails at the transport, dropping the buffer is fine. Arguably it works better than in TLS because we don't have the weird "half-committed to data" behavior. Likewise, the handshake keeps track of how far its gotten and resumes the message at the right point. This broke when the buffering logic was rewritten because I didn't understand what the DTLS code was doing. The one thing that doesn't work as one might expect is non-fatal write errors during rexmit are not recoverable. The next timeout must fire before we try again. This code is quite badly sprinkled in here, so add tests to guard it against future turbulence. Because of the rexmit issues, the tests need some hacks around calls which may trigger them. It also changes the Go DTLS implementation from being completely strict about sequence numbers to only requiring they be monotonic. The tests also revealed another bug. This one seems to be upstream's fault, not mine. The logic to reset the handshake hash on the second ClientHello (in the HelloVerifyRequest case) was a little overenthusiastic and breaks if the ClientHello took multiple tries to send. Change-Id: I9b38b93fff7ae62faf8e36c4beaf848850b3f4b9 Reviewed-on: https://boringssl-review.googlesource.com/6417 Reviewed-by: Adam Langley <email@example.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: