Skip to content

Comments

Add SNI support#90

Merged
fmauchle merged 1 commit intoradsecproxy:masterfrom
jerryz1982:sni
Aug 10, 2021
Merged

Add SNI support#90
fmauchle merged 1 commit intoradsecproxy:masterfrom
jerryz1982:sni

Conversation

@jerryz1982
Copy link
Contributor

Closes #88

@fmauchle
Copy link
Contributor

This would configure the SNI on a per tls (context) basis. Shouldn't this config be on a per server config?
(common configurations often use a single tls config for many, if not all, servers)

Without knowing the internals of SNI: would it hurt (i.e. be incompatible with some implementations) to always set SNI (if server is specified as a hostname), even if the server doesn't expect it?

@jerryz1982
Copy link
Contributor Author

@fmauchle I put it in tls config because SNI is only relevant when server type is tls. If one tls context is used by many servers, and you would like to use different SNI for different servers, I agree that it would be more appropriate to put SNI under server settings.
As far as I know, SNI would not hurt even if server-side doesn't need it, it should just ignore it.
https://stackoverflow.com/questions/45015871/can-sni-be-enabled-without-problems-to-servers-that-do-not-support-sni-in-tls-ha
Do you mean to set server hostname as default SNI if not explicitly specified?
Personally, I would leave it optional and when not specified, SNI would not be used, as it is an optional field in TLS and only relevant when there are different backends or certs for the same server.

@fmauchle
Copy link
Contributor

@fmauchle I put it in tls config because SNI is only relevant when server type is tls.

There already are a number of config statements in the server block that are only relevant if type is tls (or dtls). Thats no issue.

Do you mean to set server hostname as default SNI if not explicitly specified?

Yes that was my first thought, so we don't have to specify the server name twice (assuming SNI would be identical to the server name most of the time).

Personally, I would leave it optional and when not specified, SNI would not be used, as it is an optional field in TLS and only relevant when there are different backends or certs for the same server.

Agreed, leaving it optional might be on the safe side for now. But a simple flag to enable it would still be good, especially if used with dynamic discovery.

@jerryz1982
Copy link
Contributor Author

moved the setting to server config

fmauchle added a commit that referenced this pull request Aug 10, 2021
@fmauchle fmauchle merged commit 76ef331 into radsecproxy:master Aug 10, 2021
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.

SNI support (feature request)

2 participants