Security issues before HTTPS is configured

jupyterhub / the-littlest-jupyterhub

Simple JupyterHub distribution for 1-100 users on a single server

https://tljh.jupyter.org

BSD 3-Clause "New" or "Revised" License

1.04k stars 340 forks source link

Security issues before HTTPS is configured #258

Open jedbrown opened 5 years ago

jedbrown commented 5 years ago

A user following the installation instructions starts with a plain HTTP server that creates an admin account with user-provided password. This is vulnerable to very unsophisticated attacks such as

an attacker could win a race with the owner, thereby gaining admin access to the machine
a passive observer could record the admin password created by the owner

It seems to me that instructions for public installation should avoid these race conditions by either having a complete HTTPS script or instruction users to log in to the console and configure HTTPS before activating the Jupyter Hub login.

yuvipanda commented 5 years ago

Thanks for opening this, @jedbrown. I agree this is a very real security issue. However, we made an explicit decision to not ask users to ssh in to the box to set up, and automatic HTTPs requires a domain name which is also too high a bar for initial setup. You also might not know the IP until after the VM has been created, making DNS more complicated.

For mitigation against racing, we should allow users to specify the password during the setup command itself, rather than having them set it on first use. I'll file a separate issue for that.

For passive observer, I think we should explicitly mention this is a tradeoff we make, and suggest ways around this if this is a threat vector they care about - primarily involving getting a console & setting up HTTPS first. This is pretty bad security for this threat, but I think the tradeoff for usability is worth it in this case.

How does that sound?

yuvipanda commented 5 years ago

I opened https://github.com/jupyterhub/the-littlest-jupyterhub/issues/263 for the first issue

jedbrown commented 5 years ago

The issue of not knowing the IP address is an irritating obstacle because it takes a few hours for a new DNS record to propagate. Some hosts support floating IP addresses, which enables setting the DNS record before provisioning the new VPS. If a user waits for the DNS to propagate, the tljh install script could just accept the desired hostname as a command line argument and use certbot to bring up HTTPS.

I realize it isn't instant gratification, but I'd still rather the host wait for a fresh DNS record to propagate than to have an open login.

consideRatio commented 3 years ago

The status of this issue is:

[x] #263 enables users to pass an initial admin-password
[ ] Someone could eavesdrop on the admin using this password For best security, one should not use the admin password unless we have HTTPS setup.

Do we need to login as an admin via the JupyterHub web UI at all before setting up HTTPS? One doesn't have to do that, right? Perhaps we should simply suggest that the end user setups HTTPS before accessing JupyterHub as a resolution to this issue.

PS: We use FirstUseAuthenticator by default, which is configured to not create new users, so there should only be one created ahead of time by passing the --admin admin-name:admin-password during the initial setup.