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

Pass host to tls.connect for certificate validation #2273

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

RazerM
Copy link

@RazerM RazerM commented Jul 10, 2020

Fixes #2263

@charmander
Copy link
Collaborator

Someone’ll need to write a test for this. I wonder what it does when host is a Unix domain socket?

@RazerM RazerM force-pushed the fix-ip-tls-validation branch from e426771 to 839b6b4 Compare July 22, 2020 22:19
@RazerM
Copy link
Author

RazerM commented Jul 22, 2020

I wonder what it does when host is a Unix domain socket?

I think from the links I put in #2263 it's clear that host is only used for checking the server identity, and that for non-IP addresses this is currently set by servername. So nothing has changed for unix domain sockets in that regard.

@RazerM RazerM force-pushed the fix-ip-tls-validation branch from 839b6b4 to 03c4ea5 Compare May 3, 2021 09:14
@RazerM
Copy link
Author

RazerM commented May 3, 2021

What can I do to get this merged?

@vitaly-t
Copy link
Contributor

vitaly-t commented Jun 3, 2021

When indeed? :) I got another issue open about the same, it seems.

@charmander
Copy link
Collaborator

charmander commented Jun 3, 2021

@vitaly-t That doesn’t sound like the same issue; the host in that one isn’t an IP address, and the claimed behaviour is missing SNI, not certificate validation failure.

@RazerM It needs a test.

@vitaly-t
Copy link
Contributor

vitaly-t commented Jun 3, 2021

That doesn’t sound like the same issue; the host in that one isn’t an IP address, and the claimed behaviour is missing SNI

Yeah, sorry, I didn't look up close. But what's valid there is something else in the configuration here, since pg-promise just passes the config object on to this driver, without any modification.

@charmander
Copy link
Collaborator

@vitaly-t It looks like pg sets servername unconditionally, but we want to allow it to be overridden; working on a fix for that. (That should mean the SNI is the same as the host instead of missing, but that’s probably what the issue reporter means.)

@RazerM
Copy link
Author

RazerM commented Jun 6, 2021

@charmander #1890 was merged without a test despite the consequences for IP addresses so I get the impression the test setup wouldn't easily support such a test. The existing tests all pass for this PR too.

I think it should be clear from the description in the issue what is wrong. It's quite frustrating because it's fairly easy to see why IP addresses don't work and how pg got like this:

  1. pg passes a socket to tls.connect.
  2. tls.connect has no idea which hostname it needs to check the identity for when it has a socket.
  3. tls.connect uses options.servername || options.host || 'localhost' to verify server identity.
  4. pg used to always pass servername, which as noted should not be done for IP addresses.
  5. PR Skip TLS SNI if host is IP address #1890 changed this to only do it for non-IP addresses, therefore the tls.connect identity verification uses 'localhost'. This is bad!
  6. The snippet above shows why removing servername for IP addresses results in 'localhost' being used. You need to pass host!

@charmander
Copy link
Collaborator

charmander commented Jun 7, 2021

Of course it’s clear what’s wrong. That doesn’t mean it doesn’t need a test. It was able to break in the first place because there was no test.

I can write the test, but it’ll be a while.

@penous
Copy link

penous commented May 15, 2023

Hey all, any updates on this?

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.

IP hosts are not validated correctly against certificate altnames
4 participants