vault cli doesn't listen on secure port during oidc login even when explicitly asked to do so

[soumyadeep-paul-ibm]

During a CLI authentication with oidc, we see is localhost listen to a insecure port 8250, irrespective of callbackmethod=https and callbackport=9443

Does this mean, we need to make arrangement for forwarding the traffic to insecure port 8250 ?

Environment:

• Vault Version:
  Client : Vault v1.11.3 ('17250b25303c6418c283c95b1d5a9c9f16174fe8+CHANGES'), built 2022-08-26T10:27:10Z
  Server: Vault v1.11.3 (17250b2), built 2022-08-26T10:27:10Z

• Operating System/Architecture:
  root@icfra02vault-pocpibmvault01 ~]# uname -a
  Linux icfra02vault-pocpibmvault01 3.10.0-1160.el7.x86_64 Initial Website Import #1 SMP Tue Aug 18 14:50:17 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
  [root@icfra02vault-pocpibmvault01 ~]# cat /etc/redhat-release
  Red Hat Enterprise Linux Server release 7.9 (Maipo)
  Vault Config File:

# Paste your Vault config here.
# Be sure to scrub any sensitive values

Startup Log Output:

# Paste your log output here

Expected Behavior:
vault login -method=oidc callbackmethod=https skip_browser=true
This generates a callback url https://localhost:8250/oidc/callback, The temporary service running on port 8250 should configure a TLS certificate.

Actual Behavior:
The local port 8250 runs without a certificate and when we complete the oidc authentication, we get error

Secure Connection Failed

An error occurred during a connection to localhost:8250. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

This is caused by no certificate is configured on port 8250

 openssl s_client -connect localhost:8250
CONNECTED(00000005)
4527605420:error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number:/AppleInternal/Library/BuildRoots/a0876c02-1788-11ed-b9c4-96898e02b808/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2.8/ssl/ssl_pkt.c:386:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1663140312
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Steps to Reproduce:

• Configure OIDC
• In the OIDC application redirect URIs add https://localhost:8250/oidc/callback (Along with any other for vault ui)
• In the OIDC role configuration "allowed_redirect_uris" , add the same uri (Along with any other for vault ui)

Important Factoids:

Our OIDC provider doesn't allow adding a http url and we must add https url only.
References:

[soumyadeep-paul-ibm]

I am able to workaround the problem by running a haproxy server on the client side, which listens on a secure port 9443, and forwards traffic to insecure port 8250. I had to register https://localhost:9443 in the redirect urls in oidc and allowed_redirect_uris in the vault oidc role.

This works for us, because all our users are expected to login from a single jump server, however, I strongly feel this is something needs to taken care of by the vault client itself

[nordicmachine]

I've been able to reproduce this issue but am unable to work around it as @soumyadeep-paul-ibm has been since all of my users login from their own workstations. Our Identity Provider also does not permit http (non-TLS) endpoints. Additionally, I was investigating OIDC authentication because #18875 prevents us from upgrading Vault.

[maxb]

The right way forward here, is to fix the Identity Provider to permit http://localhost callback URLs.

You can't use TLS without a certificate, and you can't realistically get a meaningful certificate issued for localhost. Therefore a client program executing on the same computer as the web browser and seeking to use it as a login UI, requires a non-TLS redirect URL. But, in this use-case, the traffic is not traversing any real network, it's flowing directly over the localhost interface within a single machine, negating the majority of reasons to want TLS in the first place.

Vault is not doing anything weird here... this technique is specifically documented in https://www.ietf.org/rfc/rfc8252.html#section-7.3

[nordicmachine]

@maxb Thanks for the link to the RFC. It does look like loopback redirection should be fine over http so I've raised that issue with the Identity Provider.

However, the JWT/OIDC Auth Method documentation does state that:

The callback listener may be customized with the following optional parameters. These are typically not required to be set:
...
callbackmethod: (default: "http")
...

Which would lead me to believe that the intention was to actually implement more than just the 'http' method. So I think there still needs to be something done here. Perhaps either:

1. Update the documentation to clearly state that the callbackmethod parameter won't actually change the callback listener to do anything except listen on http (which would also lead me to ask why the parameter is there in the first place), or
2. Actually implement the ability for the callback listener to do TLS when the callbackmethod is set to 'https'

[maxb]

You make a good point... I cannot think of any way a user could usefully make use of the callbackmethod option. Perhaps it should just be removed outright.

[jDmacD]

You make a good point... I cannot think of any way a user could usefully make use of the callbackmethod option. Perhaps it should just be removed outright.

Just wanted to chime in an say I use the callbackmethod option, don't remove it!

I'm running the vault cli inside code-server.

vault login -method=oidc \
  listenaddress="0.0.0.0" \
  callbackhost="my-code-server.com" \
  callbackmethod=https \
  callbackport="443" \
  skip_browser=true

code-server helm:

extraPorts:
  - name: vault-cb
    port: 8250
    protocol: TCP

Gatway Route:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: code-server
  namespace: code
spec:
  parentRefs:
    - name: envoy-gateway-opnsense
      kind: Gateway
      group: gateway.networking.k8s.io
      namespace: envoy-gateway
      sectionName: https
  hostnames:
    - "my-coder-server.com"
  rules:
    - backendRefs:
        - name: code-server
          group: ''
          kind: Service
          namespace: code
          port: 8080
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /
    - backendRefs:
        - name: code-server
          group: ''
          kind: Service
          namespace: code
          port: 8250
          weight: 1
      matches:
        - path:
            type: Exact
            value: /oidc/callback

[onefourfive]

Should this have label:bug? This is not working as intended