Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add support for the "supported_versions" extension in the Packetbeat TLS module. #8647

Closed
jamesspi opened this issue Oct 18, 2018 · 0 comments
Closed

Add support for the "supported_versions" extension in the Packetbeat TLS module. #8647

jamesspi opened this issue Oct 18, 2018 · 0 comments
Assignees
@adriansr
Labels
enhancement module Packetbeat

Comments

@jamesspi
Copy link
Contributor

TLS 1.3 recently went live. The negotiated TLS version is stored in the supported_versions extension rather than the server_hello extension, which still shows up as 1.2 (I believe this was intentional to handle to problem with middleware).

Packetbeat currently picks up the server_hello extension, which for TLS 1.3 will give incorrect results.

Ideally, we start using the supported_versions extension to detect the correct version.

Packetbeat Version: 6.4.2
Client tested with: Chrome 70 on macOS Mojave
Server Tested with: Nginx 1.15.5 and OpenSSL 1.1.1
Server OS: CentOS Linux release 7.5.1804 (Core)

Thanks!
James
@jamesspi jamesspi assigned jamesspi and adriansr and unassigned jamesspi Oct 18, 2018
adriansr added a commit to adriansr/beats that referenced this issue Oct 26, 2018
@adriansr
Support parsing TLS 1.3 supported_versions extension (elastic#8647)
63329bf 
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
@adriansr adriansr mentioned this issue Oct 26, 2018
Merged
adriansr added a commit that referenced this issue Oct 30, 2018
@adriansr
Support parsing TLS 1.3 supported_versions extension (#8647) (#8772)
51c1aa2 
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 #8647
adriansr added a commit to adriansr/beats that referenced this issue Oct 30, 2018
@adriansr
Support parsing TLS 1.3 supported_versions extension (elastic#8647) (e…
f668b2d 
…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)
@adriansr adriansr mentioned this issue Oct 30, 2018
Closed
@adriansr adriansr mentioned this issue Oct 30, 2018
Merged
adriansr added a commit to adriansr/beats that referenced this issue Nov 15, 2018
@adriansr
Support parsing TLS 1.3 supported_versions extension (elastic#8647) (e…
145818d 
…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)
adriansr added a commit that referenced this issue Nov 15, 2018
@adriansr
Support parsing TLS 1.3 supported_versions extension (#8647)
3fcb0b9 
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 #8647

(cherry picked from commit 51c1aa2)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adriansr adriansr

Labels
enhancement module Packetbeat
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jsoriano @adriansr @jamesspi