Page MenuHomePhabricator

New "service https" implementation
Closed, ResolvedPublic

Description

Now that we have a working HTTP API prototype, it's time to resurrect "service https" that has been removed from the nightly build along with the corpse of the old GUI.

Some considerations:

  • nginx-based, obviously. That's the default HTTP server now.
  • HTTP applications such as API and GUI must be explicitly enabled, by default just display a static info page
  • user-supplied cert support would be cool, but intermediate certs may make it complicated
  • support for custom proxy rules would be nice

A draft of what we need right now:

service https
  # global options
  listen-address <IPv4|IPv6|any> (multi)

  # applications
  api
    port <port number>
    debug <valueless>
    keys
        id <txt>
          key <txt>

There's also a bit of a chicken and egg problem: API and in the future the GUI are HTTP servers on their own, but they also need the HTTP proxy. So we likely need separate scripts for configuring the proxy, and one script per API/GUI/etc.
The proxy configuration script can look into the subtrees to see what port to proxy requests too etc.
We need to find out if making the proxy script the "owner" of "service https" and making the API script the owner of "service https api" is sufficient to achieve that, or we need to do some trickery to make sure when you change "service https api port" for example, both scripts are triggered.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change

Event Timeline

dmbaturin triaged this task as High priority.Jun 17 2019, 3:38 PM
dmbaturin created this task.
c-po added a comment.Jun 17 2019, 3:43 PM

I'd propose adding letsencrypt support for the certificates, too

dmbaturin updated the task description. (Show Details)Jun 17 2019, 3:45 PM
pasik added a subscriber: pasik.Jun 18 2019, 8:27 AM
runar added a subscriber: runar.Jun 21 2019, 9:29 PM
runar added a comment.Jun 21 2019, 9:33 PM

When were talking web-interface (not the api itself) it needs to have the functionality to "stage" multiple changes before commit'ing everything in one go, just like in the cli

Just to confirm, HTTP proxy in this context being nginx being a reverse proxy frontend for GUI and API HTTP servers, likely living on localhost bindings, right?

I ask, because being able to serve an onboard PAC file for the onboard squid web proxy instance would allow PAC file self servicing, though that would also depend on DHCP server WPAD URL configurations, and being served via HTTP due to the chicken/egg issue of trusting an SSL certificate during PAC file retrieval by an isolated client.

jestabro changed the task status from Open to In progress.Jul 1 2019, 7:44 PM
Dmitry added a subscriber: Dmitry.Jul 25 2019, 9:02 PM
dmbaturin changed the task status from In progress to Needs testing.Sep 5 2019, 1:09 AM
dmbaturin set Is it a breaking change? to Perfectly compatible.
dmbaturin changed Is it a breaking change? from Perfectly compatible to Behavior change.
syncer closed this task as Resolved.Sep 5 2019, 8:43 AM
syncer moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.3) board.
syncer moved this task from In Progress to Finished on the VyOS 1.3 Equuleus board.