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

Allow plain HTTP console access (as a non-default option) #440

Open
anjackson opened this issue Sep 30, 2021 · 1 comment
Open

Allow plain HTTP console access (as a non-default option) #440

anjackson opened this issue Sep 30, 2021 · 1 comment

Comments

@anjackson
Copy link
Collaborator

We got a report that people were having problems with the fact that HTTPS is used to access the Heritrix3 web console. In some situations, e.g. corporate IT environments, it is not possible to accept self-signed certificates nor import/permit locally minted certificate authorities.

If there are no objections, I would like to propose a new command-line option that enables acccess over plain HTTP. If it is not set, then users should be directed to HTTPS (as per #318). But if this option is enabled, users should be able to access the console directly.

A further question is whether the HTTP Basic authentication should always be required. Certainly, if there is authentication it seems like we must enforce the use of HTTPS. But, we could allow users to switch off authentication when accessing Heritrix via HTTP?

@ato
Copy link
Collaborator

ato commented Oct 1, 2021

I can't imagine many scenarios where running Heritrix without HTTPS or authentication on a network would not be irresponsible as it enables trivial remote code execution. It would also very likely violate the security policy of said corporate IT environments.

That said I think there are some use cases that are reasonable:

  1. A desktop user wanting to run Heritrix on their single-user PC and access it from a local browser.
  2. Running Heritrix on a server behind an authentication proxy or tunnel that provides transport encryption and externally authenticates the user with their corporate credentials (e.g. oauth2-proxy, ssh port forwarding).

If we allow this configuration but only when the UI is bound to localhost it would cover these more reasonable use cases without encouraging the more irresponsible one. Of course it could be circumvented by using an unprotected reverse proxy but that circumvention can already be done and at least requires someone to think about what they're doing a bit more than "oh, I just used --disable-security temporarily to quickly get started while testing but oops its in production now".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants