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.

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

dnsdist: SNI extension is missing on outgoing TLS connections #11249

Closed
sbiberhofer opened this issue Jan 29, 2022 · 2 comments · Fixed by #11251
Closed

dnsdist: SNI extension is missing on outgoing TLS connections #11249

sbiberhofer opened this issue Jan 29, 2022 · 2 comments · Fixed by #11251
Assignees
Milestone

Comments

@sbiberhofer
Copy link

  • Program: dnsdist
  • Issue type: Bug report

Short description

Adding DoT or DoH backends via newServer({address="ip:port", tls="openssl", subjectName="dns.someserver.com"}) or newServer({address="ip:port", tls="openssl", subjectName="dns.someserver.com", dohPath="/query"}) initiates the outgoing TLS connection without setting the SNI extension in the TLS ClientHello. This causes problems if the default certificate of responding server does not match the subjectName value.

Environment

  • Operating system: Voidlinux, Debian Bookworm
  • Software version: 1.7.0
  • Software source: Default OS repositories

Steps to reproduce

  1. Configure a TLS backend via newServer({address="ip:port", tls="openssl", subjectName="dns.someserver.com"})
  2. Have the server responding on dns.someserver.com return a non-matching default certificate

Expected behaviour

dnsdist should initialize the TLS context properly to ensure the server_name extension is sent in the ClientHello when the subjectName parameter is set.

Actual behaviour

At least when using openssl, dnsdist appears to call SSL_set1_host, thus verifying the certificate against the specified subjectName. It doesn't seem to call SSL_set_tlsext_host_name or something similar to add the subjectName via the server_name extension to the ClientHello.

@Habbie
Copy link
Member

Habbie commented Jan 29, 2022

The gnutls driver does work, and can serve as a workaround for now, for users that have it.

@Habbie
Copy link
Member

Habbie commented Jan 29, 2022

It doesn't seem to call SSL_set_tlsext_host_name

This is what openssl s_client uses, so that looks like the right fix to me.

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

Successfully merging a pull request may close this issue.

3 participants