search

cockpit-project / cockpit

Cockpit is a web-based graphical interface for servers.
http://www.cockpit-project.org/
GNU Lesser General Public License v2.1
10.96k stars 1.1k forks source link

Cookie isn't marked as `secure` with `X-Forwarded-Proto: https` #20942

Open Func86 opened 2 weeks ago

Func86 commented 2 weeks ago

Explain what happens

  1. Behind Cloudflare Tunnel, set ProtocolHeader = X-Forwarded-Proto in the config, access the web console via HTTPS
  2. Before login, see the value of the cockpit cookie is deleted, with the Secure flag
  3. Login, and check the cookies again, it is without the Secure flag
  4. Toggle the ProtocolHeader = X-Forwarded-Proto config on and off, to confirm that it's only working when not logged in.

Version of Cockpit

323-1~bpo12+1

Where is the problem in Cockpit?

Unknown or not applicable

Server operating system

Debian

Server operating system version

Debian 6.1.99-1 (2024-07-15) x86_64

What browsers are you using?

Chrome

System log

No response

Func86 commented 2 weeks ago

https://github.com/cockpit-project/cockpit/blob/19e32033581fb91186e19a9ad3e2d2ddb14142da/src/ws/cockpitauth.c#L1580-L1588

vs

https://github.com/cockpit-project/cockpit/blob/19e32033581fb91186e19a9ad3e2d2ddb14142da/src/common/cockpitwebserver.c#L1343-L1360

which is used for the cockpit_auth_empty_cookie_value function.

martinpitt commented 2 weeks ago

To clarify: Your bug report is that you run cockpit-ws behind a reverse proxy, and X-Forwarded-Proto is https, but cockpit_auth_login_finish() does not actually test for that (only for --for-tls-proxy), so the cookie isn't marked as secure? That makes sense to me, just would like to confirm.

Func86 commented 2 weeks ago

Yes, so the behaviour is inconsistent before and after login.

martinpitt commented 2 weeks ago

@Func86 If this bothers you, start cockpit-ws with the --for-tls-proxy option, then the cookie should be correct.