Missing server_name extension in tls handshake in logproc
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 88
Description
**Logstash information**:
Please include the following information:
1. Logstash version -- v8.17.2
2. Logstash installation source (e.g. built from source, with a package manager: DEB/RPM, expanded from tar or zip archive, docker) -- docker
3. How is Logstash being run (e.g. as a service/service manager: systemd, upstart, etc. Via command line, docker/kubernetes) -- kubernetes
**JVM** (e.g. `java -version`): --> jre21
**Description of the problem including expected versus actual behavior**:
Logstash is used to send logs to syslog server with TLS.
Configuration used.
```
output {
syslog {
facility => "%{facility}"
host => "abc.net"
port => "6514"
protocol => "ssl-tcp"
ssl_cacert => /ca.pem
ssl_cert => /server.crt.pem
ssl_key => /server.key.pem
ssl_verify => true
severity => "%{severity}"
sourcehost => "%{[host][name]}"
codec => line {
format => "%{message}"
}
}
}
```
- When capturing packets between logproc and rsyslog server, there is no server_name extension in TLS handshake. Please find the tcp dump image with logproc communication to syslog server.
- Capturing the packets using tcpdump for curl command to the rsyslog contains the server_name extension as shown in image below
curl command:
`curl -v --cacert ca.pem --cert server.crt.pem --key server.key.pem https://abc.net:6514/`
Tcpdump on server side:
`tcpdump -i any host 100.103.102.3 and port 6514 -w syslog_capture.pcap`
Image of tcpdump capture on server side with curl
We have a request to have HostSNI in the TLS handshake.
Please check if this is an issue and needs some enhancement in the plugin.
Thanks in advance.
Contributor guide
Research direction
Start by examining the Logstash syslog output configuration and the packet captures comparing Logstash with curl. Determine whether the TLS client handshake can include the requested server_name extension in this setup. Done means the syslog connection sends HostSNI as requested, with the behavior verified against a capture or documented as unsupported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, java, kubernetes
- Domain
- backend, networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100