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

good Internet-facing webserver #27

Open
3 tasks
scottlamb opened this issue Mar 9, 2018 · 1 comment
Open
3 tasks

good Internet-facing webserver #27

scottlamb opened this issue Mar 9, 2018 · 1 comment
Labels
enhancement rust Rust backend work required schema change Requires a database schema change (see new-schema branch)
Milestone

Comments

@scottlamb
Copy link
Owner

scottlamb commented Mar 9, 2018

I want Moonfire to be a good Internet-facing webserver.

  • support https
  • support https...with automatic ACME (letsencrypt) support for HTTP-01 and/or TLS-ALPN-01 challenges.
  • access logs: similar to nginx or Apache keep, ideally also with a field showing the logged-in user.

In the meantime, we have a guide for setting up a proxy in front: Security Moonfire NVR and exposing it to the Internet.

letsencrypt details

I want to serve everything over https, ideally automatically setting up new key pairs via letsencrypt + the acme-client crate.

I'd love it if someone were to write a crate (or integrate into some framework like rocket) something that uses acme-client, hyper, and a storage hook just make sure the http port responds to the challenges and the https port uses the certificate it gets. Moonfire NVR would plug in a storage hook that puts stuff in the SQLite database. This would be by far the slickest way to do https.

Consider enabling HTTP Strict Transport Security. Maybe a pref for that.

@scottlamb scottlamb added this to the 1.0 milestone Mar 9, 2018
@scottlamb scottlamb added the schema change Requires a database schema change (see new-schema branch) label Mar 13, 2018
scottlamb added a commit that referenced this issue Nov 27, 2018
Some caveats:

  * it doesn't record the peer IP yet, which makes it harder to verify
    sessions are valid. This is a little annoying to do in hyper now
    (see hyperium/hyper#1410). The direct peer might not be what we want
    right now anyway because there's no TLS support yet (see #27).  In
    the meantime, the sane way to expose Moonfire NVR to the Internet is
    via a proxy server, and recording the proxy's IP is not useful.
    Maybe better to interpret a RFC 7239 Forwarded header (and/or
    the older X-Forwarded-{For,Proto} headers).

  * it doesn't ever use Secure (https-only) cookies, for a similar reason.
    It's not safe to use even with a tls proxy until this is fixed.

  * there's no "moonfire-nvr config" support for inspecting/invalidating
    sessions yet.

  * in debug builds, logging in is crazy slow. See libpasta/libpasta#9.

Some notes:

  * I removed the Javascript "no-use-before-defined" lint, as some of
    the functions form a cycle.

  * Fixed #20 along the way. I needed to add support for properly
    returning non-OK HTTP statuses to signal unauthorized and such.

  * I removed the Access-Control-Allow-Origin header support, which was
    at odds with the "SameSite=lax" in the cookie header. The "yarn
    start" method for running a local proxy server accomplishes the same
    thing as the Access-Control-Allow-Origin support in a more secure
    manner.
@scottlamb scottlamb mentioned this issue Dec 1, 2018
13 tasks
@scottlamb scottlamb changed the title https built-in https+letsencrypt Dec 27, 2018
scottlamb added a commit that referenced this issue Dec 27, 2018
The guide is not as quick to follow and amateur-friendly as I'd like. A
few things that might improve matters:

   * complete #27 (built-in https+letsencrypt), so that when not sharing
     the port, users don't need to use nginx or certbot.
   * more ubiquitous IPv6 (out of my control but should happen over
     time) to reduce need to share the port
   * embed a dynamic DNS client
   * support UPnP Internet Gateway Device Control Protocol (if common
     routers have this enabled? probably not for security reasons.)

It's progress, though. Enough that I think I'll merge the auth branch
into master shortly.
@scottlamb scottlamb added the rust Rust backend work required label Jul 10, 2019
@scottlamb scottlamb modified the milestones: 1.0, 1.0? Apr 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement rust Rust backend work required schema change Requires a database schema change (see new-schema branch)
Projects
None yet
Development

No branches or pull requests

1 participant