Expose Server Name Indication (SNI) within ClientTLS autorization request claims

[charbonnierg]

I'm using an auth callout service to authenticate/authorize users on a TLS enabled NATS server.

I would like to know the server name that was used during client TLS handshake within my auth callout service.

Like in this example below, I would like to deny access if the proper server name is not used, even if token is valid:

• first attempt does not have a token: access is denied
• second attempt uses correct server name and correct token: access is granted
• third attempt uses invalid server name and correct token: access is denied
  

In order to do that, I had to modify both the jwt and nats-server repositories and added support for server name in request claims.

I've got two questions:

• Is there any way to do the same thing without modifying jwt and nats-server repositories ?
• If no, are you open to adding the server name in ClientTLS struct ? I could create a PR

[derekcollison]

That information is already present.

[charbonnierg]

Thanks for the reply !

[charbonnierg]

I just looked again, but that's not the same thing isn't it ?

I may have host set to 0.0.0.0. That's the case in my JWT claims:

{
  "aud": "nats-authorization-request",
  "exp": 1698248970,
  "jti": "KUEYEBMA5WXYHIMFWXKYV4GKB234KZPT7XTEQKUDKFB3WJM6IHPQ",
  "iat": 1698248968,
  "iss": "ND2VRW5IA7UIZTAJ4U2C2ZW3ROJSRLENP2CXLEIAWGEATT5XS7SSXTSY",
  "sub": "ACMHTF46SWZIFZMOUKPC7YL2L3EGMEM7NYGBYSNXQBOAHI6XC2VUWDRI",
  "nats": {
    "server_id": {
      "name": "srv-01",
      "host": "0.0.0.0",
      "id": "ND2VRW5IA7UIZTAJ4U2C2ZW3ROJSRLENP2CXLEIAWGEATT5XS7SSXTSY",
      "version": "2.11.0-dev"
    },
    "user_nkey": "UDXT3HLG24IHVVT2U67SHNY24IEK5G2ZA32UH4G3PBHTGRMAWXYOI2NE",
    "client_info": {
      "host": "127.0.0.1",
      "id": 10,
      "user": "TEST",
      "name": "NATS CLI Version 0.0.35",
      "kind": "Client",
      "type": "websocket"
    },
    "connect_opts": {
      "auth_token": "TEST",
      "name": "NATS CLI Version 0.0.35",
      "lang": "go",
      "version": "1.19.0",
      "protocol": 1
    },
    "client_tls": {
      "version": "1.3",
      "cipher": "TLS_AES_128_GCM_SHA256",
      "server_name": "other.local.quara-dev.com"
    },
    "type": "authorization_request",
    "version": 2
  }
}

What I want is really the server name used during TLS handshake, not a server name configured on server side. In my case, server accepts connections on several domain names, which are unrelated to server name.

Note: the server_name appears in my claims because I use my fork of nats-server

[derekcollison]

If we have a TLS connection we might be able to extract it from the handshake, I can take a look into that.

[charbonnierg]

FWIW I used the server name from the TLS connection state and tested it manually, it works great.

Also, thanks for your time and replies, I'm sure you've got many things to do, I really appreciate that you take time to discuss things

[derekcollison]

Nice, as you pointed out for this one it has to touch a bunch of libs not just the server, but I am happy to look at PRs if you want to give it a go.

[charbonnierg]

I just opened nats-io/jwt#210 which seems to be a pre-requisite for any change in nats-server repo.

I only added the new field to the struct, and did not add any test case ATM, feel free to tell me if anything if required.

[derekcollison]

Sounds good, will take a peek.

[ripienaar]

Agree @charbonnierg it's not the same. I am curious what the use case is for verifying this in callout? Not saying its an invalid idea or anything I am just curious :)

[derekcollison]

server_id from above contains the info on the server that has the client connection.

[charbonnierg]

If it can help understanding the feature request, I have an experimental auth callout plugin system configurable using policies. A policy has:

• a set of matchers: responsible for deciding if policy should apply
• a handler: responsible for either returning an error or user claims

And I'm very interested in having a matcher based on tls server name, just like in the example below:

• For both domains, users should be authorized using oauth2 session ticket provided as token, and if an oauth2 session exists, user claims are signed for the target account.

• For the test app, a specific azure ad enteprise application is used

• For the staging app, a different azure ad enterprise application is used

default deny
policy app-users {
	match {
		tls_server_name staging.myapp.com
	}
	callout oauth2 {
		endpoint az-stag
		account STAG_APP
		template {
			allow_pub "users.notify.{oidc.session.email}.>"
			allow_sub "users.service.{oidc.session.email}.>"
			allow_resp
		}
	}
}
policy test-app-users {
	match {
		tls_server_name test.myapp.com
	}
	handler oauth2 {
		endpoint az-test
		account TEST_APP
		template {
			allow_pub "users.notify.{oidc.session.email}.>"
			allow_sub "users.service.{oidc.session.email}.>"
			allow_resp
		}
	}
}
policy admin {
	match {
		connection_type in_process
		username SYS
	}
	callout allow {
		account SYS
	}
}
policy auth-service {
	match {
		connection_type in_process
		username OAUTH2
	}
	callout allow {
		account OAUTH2
	}
}

[charbonnierg]

No, I'm suggesting to enrich metadata regarding client TLS connection. That's all.

If we make it really easy to use the SNI name incorrectly by not clearly indicating its not to be trusted, users will treat it as trusted.

We need to be clear here, the SNI is trustable. There is no way for the client to use a SNI not valid according to server config. This is no different from cipher or TLS version (and cipher and TLS versions are present in claims). Sure it is not enough to identify WHO is the client, and if he should be authorized, but that does not make it less "trusted".

IMHO The real question here is: should client_tls block contain information related to the TLS connection state, or should it only contain information related to tls certificates ?

• If the first, then it makes a lot of sense to include SNI
• If the latter, then it does not make sense to include SNI, but I don't see how cipher or protocol are justified in such case. Just like sni, they can be chosen by the client, and do not contain enough information by themselves to identify the client.

[derekcollison]

I am ok with adding it in, noting what R.I. said that with wildcards anyone could use multiple host names etc. in a probe.

[charbonnierg]

I do understand the fact that with wildwards, anyone could use multiple hosts. As well as I understand that certificates using alternative subject names will expose the valid set of domain names. And in any case, I only had difficulties with the concept of "trust" described by R.I. Aside from that I agree with what was said above :). Regarding the concept of trust, my understanding is as follow:

What we cannot trust is:

the user was authorized to connect because he provided this domain name.

I understand that R.I. fears that users will jump to this conclusion and open security holes. I'm not convinced by this argument, as users of auth callout should be advanced users anyway, but I do recognize that this MAY happen...

But regardless from usage, we can definitely trust:

the user attempted to connect using this domain name.

Which IMO, is not so far from (for example):

the user attempted to connect using TLS protocol 1.3

Or

the user attempted to connect using TLS encryption cipher TLS_AES_128_GCM_SHA256

In the three cases, the information is metadata describing the TLS connection state of client connection.

[ripienaar]

2 of the 3 you can trust because the TLS system validated the entire TLS version or cipher mathematically.

1 you cannot trust because any user can supply any of the valid options.

As you pointed out the spec requires you to use SNI to then follow on to securely validate TLS handshake - this means the security lies in the validation passing. We can trust webservers to implement this requirement and not land us in hot water.

We have no control over how this SNI name is used in callout logic and users may well not combine it with strict authentication validation (like your example does). They may think this is information that’s equally valid as “user used TLS version X wirh Y cipher”. You cannot spoof a version of TLS used or cipher used. You cannot claim to use a strong cipher when you are actually using a weak cipher.

You can claim to connect to a name you can’t actually access and the server has no way to validate that simply by passing an invalid SNI name.

Anyway I am done with this. Do what yous want.

[charbonnierg]

Your points are clear, although I do not completely agree with them.

Regardless of the outcome of the discussion, I'd like to express my thanks again for your time, and for this awesome project in general.