Skip to content

Conversation

charbonnierg
Copy link

@charbonnierg charbonnierg commented Oct 25, 2023

This PR introduces a new field on ClientTLS struct to hold the server name used in TLS handshake.

Discussed in nats-io/nats-server#4706

Cipher string `json:"cipher,omitempty"`
Certs StringList `json:"certs,omitempty"`
VerifiedChains []StringList `json:"verified_chains,omitempty"`
ServerName string `json:"server_name,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be HostName? Would that be more descriptive?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used the same terminology as crypto/tls: https://pkg.go.dev/crypto/tls#ConnectionState, and I though that in the context of a ClientTLS block, ServerName would have a clear meaning.

But I understand that it may be misleading due to the fact that a server also has a server_name, so I would like for you to make the choice 😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, we can stick with ServerName or SNI.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that SNI may be the best candidate here. Googling "tls sni" gives pretty relevant results, and it does not reuse an existing field name from other claims data.

If that's ok with you, I can push a commit with this modification.

Copy link
Author

@charbonnierg charbonnierg Oct 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change would be:

	VerifiedChains []StringList `json:"verified_chains,omitempty"`
-       ServerName   string        `json:"server_name,omitempty"`
+       SNI            string      `json:"sni,omitempty"`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looping in @philpennock and @ripienaar for their opinions here. I could do either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants