Restore historical behavior for absent ServerHello extensions #4296
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In OpenSSL 1.1.0, when there were no extensions added to the ServerHello, we did not write the extension data length bytes to the end of the ServerHello; this is needed for compatibility with old client implementations that do not support TLS extensions (such as the default configuration of OpenSSL 0.9.8). When ServerHello extension construction was converted to the new extensions framework in commit 7da160b, this behavior was inadvertently limited to cases when SSLv3 was negotiated (and similarly for ClientHellos), presumably since extensions are not defined at all for SSLv3. However, extensions for TLS prior to TLS 1.3 have been defined in separate RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such should be considered an optional protocol feature in those cases. Accordingly, be conservative in what we send, and skip the extensions block when there are no extensions to be sent, regardless of the TLS/SSL version. (TLS 1.3 requires extensions and can safely be treated differently.)
agl
pushed a commit
to google/boringssl
that referenced
this pull request
Aug 31, 2017
For historical reasons, TLS allows ServerHellos (and ClientHellos) without extensions to omit the extensions fields entirely. openssl/openssl#4296 reports this is even necessary for compatibility with extension-less clients. We continue to do so, but add a test for it anyway. Change-Id: I63c2e3a5f298674eb21952fca6914dad07d7c245 Reviewed-on: https://boringssl-review.googlesource.com/19864 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
paulidale
approved these changes
Sep 4, 2017
kaduk
added
the
approval: review pending
|
ping @openssl/omc ? |
|
Any @openssl/omc want to chime in? |
mattcaswell
approved these changes
Sep 7, 2017
levitte
pushed a commit
that referenced
this pull request
Sep 7, 2017
In OpenSSL 1.1.0, when there were no extensions added to the ServerHello, we did not write the extension data length bytes to the end of the ServerHello; this is needed for compatibility with old client implementations that do not support TLS extensions (such as the default configuration of OpenSSL 0.9.8). When ServerHello extension construction was converted to the new extensions framework in commit 7da160b, this behavior was inadvertently limited to cases when SSLv3 was negotiated (and similarly for ClientHellos), presumably since extensions are not defined at all for SSLv3. However, extensions for TLS prior to TLS 1.3 have been defined in separate RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such should be considered an optional protocol feature in those cases. Accordingly, be conservative in what we send, and skip the extensions block when there are no extensions to be sent, regardless of the TLS/SSL version. (TLS 1.3 requires extensions and can safely be treated differently.) Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from #4296)
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In OpenSSL 1.1.0, when there were no extensions added to the ServerHello,
we did not write the extension data length bytes to the end of the
ServerHello; this is needed for compatibility with old client implementations
that do not support TLS extensions (such as the default configuration of
OpenSSL 0.9.8). When ServerHello extension construction was converted
to the new extensions framework in commit
7da160b, this behavior was inadvertently
limited to cases when SSLv3 was negotiated (and similarly for ClientHellos),
presumably since extensions are not defined at all for SSLv3. However,
extensions for TLS prior to TLS 1.3 have been defined in separate
RFCs (6066, 4366, and 3546) from the TLS protocol specifications, and as such
should be considered an optional protocol feature in those cases.
Accordingly, be conservative in what we send, and skip the extensions block
when there are no extensions to be sent, regardless of the TLS/SSL version.
(TLS 1.3 requires extensions and can safely be treated differently.)
@mattcaswell you did the original, if you want to take a look.
It looks like the TLSProxy just silently converts absent extensions to extensions_len of zero. Do you think we should add a separate variable and a test for this case?