influxdata / influxdata/telegraf
CN-tagging: TLS/SSL client certificate Comon Names should be allowed as automatic tags
- Dominant language
- Go
- Stars
- 17.8k
- Forks
- 5.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 161
Description
### Use Case
- Multiple sensors, each with a unique signed client certificate for authentication.
- Each sensor uploads data, tagging itself as the source.
- Client certificates include a Common Name, which identifies the certificate and device.
- Clients connect to telegraf directly, not through a specialized proxy service.
- Physical access can not be restricted on some sensors.
### Expected behavior
- Data should be taggable with the client certificate CN, so it can only identify as itself.
- Mistagged data should be dropped or retagged, ignoring the incorrect tag values.
### Actual behavior
- Any client certificate can tag data with any value.
- There is no way to add forced tags based on certificate CN.
- A single compromised certificate allows an attacker to feed fake data as if from all other devices.
### Additional info
MQTT has a similar feature, where the client CN can be used as user name, which in turn can filter access to topics.
I don't kow telegraf in depth, but it seems this would need to be implemented in in socket_listener, then forwarded to the protocol decoders.
Currently CN-tagging can be done safely, but requires clients to connect to an intermediate service, which then authenticates, applies CN-tagging, and forwards data to telegraf. Ideally this service could be dropped if CN-tagging were to be integrated on telegraf.
Contributor guide
Research direction
Start by reading the socket_listener implementation and tracing how client connections are forwarded to protocol decoders. Determine how certificate Common Names could become trusted tags and how incorrect tag values should be dropped or retagged; completion should support the stated client-certificate CN behavior without requiring an intermediate service.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100