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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement HTTP handling for TlsServer #984

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

daxpedda
Copy link

@daxpedda daxpedda commented Aug 4, 2022

This allows hosting a HTTP and HTTPS server on the same port. The main use-case is upgrading a connection to HTTPS automatically when connecting to e.g. "localhost:3030", as browsers connect via HTTP unless explicitly specified.

I implemented this in a way to be optional while not disturbing the default path.

This is a first step towards #417. I learned a lot since then 馃槄.

@jxs
Copy link
Collaborator

jxs commented Aug 11, 2022

Hi,
This is great work, looks correct to me! I think we can implement the forward from HTTP to HTTPS in this PR and rename the http function to something like upgrade wdyt?

@daxpedda
Copy link
Author

daxpedda commented Aug 11, 2022

My thinking was that maybe somebody is interested in this feature without the automatic upgrade.
I was planning to implement the upgrade functionality as a filter, but if the feature of handling both protocols to begin with is undesired, what you propose makes sense.

So is this standalone feature (without upgrading) undesired?

@notgull
Copy link

notgull commented Aug 11, 2022

I'm thinking about the downside of allowing this without the "upgrade" is that using HTTP that doesn't immediately redirect to HTTPS is problematic. At my place of work, it's considered a vulnerability. If anything, it should be opt-out of upgrading, not opt in, since it makes your program significantly more insecure.

@daxpedda
Copy link
Author

Yeah, that sounds reasonable to me. I don't think I will even implement the opt-out, because personally I don't have a use-case, so we can do it when somebody requests it.

Will look into implementing the automatic upgrade soon.

@jxs
Copy link
Collaborator

jxs commented Aug 11, 2022

My thinking was that maybe somebody is interested in this feature without the automatic upgrade.

ah good question, but What would be the use case for that?

I'm thinking about the downside of allowing this without the "upgrade" is that using HTTP that doesn't immediately redirect to HTTPS is problematic. At my place of work, it's considered a vulnerability.

interesting, yeah I was also wondering about that, do you have more info on the possible attack vector?

Update:

saw @daxpedda response, ok great! 馃憤

@daxpedda
Copy link
Author

My thinking was that maybe somebody is interested in this feature without the automatic upgrade.

ah good question, but What would be the use case for that?

I don't know, I was only doing it to make the implementation easier, I can't even come up with a use-case.

I'm thinking about the downside of allowing this without the "upgrade" is that using HTTP that doesn't immediately redirect to HTTPS is problematic. At my place of work, it's considered a vulnerability.

interesting, yeah I was also wondering about that, do you have more info on the possible attack vector?

I'm assuming if you set up a HTTPS server you don't actually want anybody connecting over HTTP. So if one forgets to setup the automatic upgrade, a user could potentially use the website completely over HTTP instead of over HTTPS. An attacker could use this by just sending you the HTTP link, even if you check the domain, you might not notice the scheme.

@daxpedda daxpedda marked this pull request as draft August 25, 2022 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants