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

TLS: Validate solely against caCert if permittedPeers is empty #11

Open
mathias-nyman opened this issue Mar 27, 2015 · 1 comment
Open

Comments

@mathias-nyman
Copy link

Hi,

The option to validate the TLS peer solely based on an X.509 certificate chain (caCert) is not supported in librelp.

The current logic is:

  1. Verify the peer certificate against the configured caCert (gnutls_certificate_verify_peers2 does it)
    and
  2. Verify the peer certificate against the configured permittedPeer

I propose the logic to be:

  1. Verify the peer certificate against the configured caCert (gnutls_certificate_verify_peers2 does it)
    and if caCert unset or permittedPeer > 0, then
  2. Verify the peer certificate against the configured permittedPeer

This logic should not break backwards compatibility, since it has not been supported to have permittedPeer option unset so far (or well, it would always have led to failed peer verification).

Main change would go around here:

librelp/src/tcp.c

Line 1190 in 63eebbb

if(!bFoundPositiveMatch) {

I can work on a pull request if you agree on the changes in general.

Thanks,
: Mathias

@mathias-nyman
Copy link
Author

Hi again,

Browsed the code some more. I see now that you never intended to use caCert as a trust chain for the peer, only as the ca bundle containing the trust chain for the local instance.

Yet my feature request remains. Implementation wise it should be a new configuration parameter for tls, instead of assuming caCert also being the trust chain for the peer.

Let me know what you think,
: Mathias

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

No branches or pull requests

1 participant