-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support parsing TLS 1.3 supported_versions extension (#8647) #8772
Merged
adriansr
merged 2 commits into
elastic:master
from
adriansr:packetbeat-tls-version-extension
Oct 30, 2018
Merged
Support parsing TLS 1.3 supported_versions extension (#8647) #8772
adriansr
merged 2 commits into
elastic:master
from
adriansr:packetbeat-tls-version-extension
Oct 30, 2018
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
This adds support for the new TLS version negotiation mechanism introduced in TLS 1.3. It relies on a new extension: `supported_versions`. When this extension is used in the CLIENT_HELLO message, it features a list of versions the client is willing to use: ``` "supported_versions": [ "TLS 1.3", "TLS 1.2", "TLS 1.1", "TLS 1.0" ], ``` If the server supports the extension, it will pick one of the offered versions and include it in the SERVER_HELLO message: ``` "supported_versions": "TLS 1.3", ``` The TLS parser will report a new field, `tls.version`, that is the TLS version that has been selected after negotiation, either using the new negotiation introduced in TLS 1.3 or the legacy negotiation mechanism that used the version field in HELLO messages. Fixes elastic#8647
- Server version visualisation changed to TLS Version - Client version is not useful anymore, replaced by tls.server_certificate.public_key_size
andrewkroh
approved these changes
Oct 29, 2018
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I'm thinking we should backport this to 6.5. WDYT?
jamesspi
approved these changes
Oct 30, 2018
jamesspi
approved these changes
Oct 30, 2018
Thanks @adriansr and @andrewkroh ! If it can be back ported to 6.5 that would be awesome. |
adriansr
added a commit
to adriansr/beats
that referenced
this pull request
Oct 30, 2018
…lastic#8772) This adds support for the new TLS version negotiation mechanism introduced in TLS 1.3. It relies on a new extension: `supported_versions`. When this extension is used in the CLIENT_HELLO message, it features a list of versions the client is willing to use: ``` "supported_versions": [ "TLS 1.3", "TLS 1.2", "TLS 1.1", "TLS 1.0" ], ``` If the server supports the extension, it will pick one of the offered versions and include it in the SERVER_HELLO message: ``` "supported_versions": "TLS 1.3", ``` The TLS parser will report a new field, `tls.version`, that is the TLS version that has been selected after negotiation, either using the new negotiation introduced in TLS 1.3 or the legacy negotiation mechanism that used the version field in HELLO messages. Updated the TLS dashboard to use the new version field: - Server version visualization changed to TLS Version - Client version is not useful anymore, replaced by tls.server_certificate.public_key_size Fixes elastic#8647 (cherry picked from commit 51c1aa2)
I've backported it to 6.5/6.x branches 👍 |
adriansr
added a commit
to adriansr/beats
that referenced
this pull request
Nov 15, 2018
…lastic#8772) This adds support for the new TLS version negotiation mechanism introduced in TLS 1.3. It relies on a new extension: `supported_versions`. When this extension is used in the CLIENT_HELLO message, it features a list of versions the client is willing to use: ``` "supported_versions": [ "TLS 1.3", "TLS 1.2", "TLS 1.1", "TLS 1.0" ], ``` If the server supports the extension, it will pick one of the offered versions and include it in the SERVER_HELLO message: ``` "supported_versions": "TLS 1.3", ``` The TLS parser will report a new field, `tls.version`, that is the TLS version that has been selected after negotiation, either using the new negotiation introduced in TLS 1.3 or the legacy negotiation mechanism that used the version field in HELLO messages. Updated the TLS dashboard to use the new version field: - Server version visualization changed to TLS Version - Client version is not useful anymore, replaced by tls.server_certificate.public_key_size Fixes elastic#8647 (cherry picked from commit 51c1aa2)
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.
This adds support for the new TLS version negotiation mechanism
introduced in TLS 1.3.
It relies on a new extension:
supported_versions
. When thisextension is used in the CLIENT_HELLO message, it features
a list of versions the client is willing to use:
If the server supports the extension, it will pick one of the
offered versions and include it in the SERVER_HELLO message:
The TLS parser will report a new field,
tls.version
, that is theTLS version that has been selected after negotiation, either using
the new negotiation introduced in TLS 1.3 or the legacy negotiation
mechanism that used the version field in HELLO messages.
Update TLS dashboard to use new version field …
tls.server_certificate.public_key_size
Fixes #8647