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

HSTS redirects to wrong url on non standard port #42

Closed
AnonSphere opened this issue Dec 1, 2012 · 10 comments
Closed

HSTS redirects to wrong url on non standard port #42

AnonSphere opened this issue Dec 1, 2012 · 10 comments
Milestone

Comments

@AnonSphere
Copy link

Hi again,

I run a webserver, where http runs on port 2080 and the user is redirected with ip tables to 127.0.0.1:80, because there are multiple services on port 80. When I turn on HSTS the user is redirected to https://webserver.com:2080/.

I think, this is not intended.

Regards Oliver

@skinkie
Copy link
Member

skinkie commented Dec 1, 2012

Mmm... what would you expect?

@AnonSphere
Copy link
Author

As cherokee is waiting for a http connection on this port and the browser is waiting for a tls connection, the user is sent to nowhere. It would be correct to send him to https://webserver.com/ or to be able to specify the port, where he should be sent to. The http port is wrong in all cases.

@skinkie
Copy link
Member

skinkie commented Dec 1, 2012

My guestimate is that https is just 'replaced' before it, and the fact that a port specified is ignored. But imagine the following usecase: what if cherokee would send the user to the first TLS port available from the bindings list?

  1. would that be the right port?
  2. would the firewall redirect that?
  3. ...

I see a lot of non-trivial issues that could potentially arrise and must be documented. And I suggestion for a default behavior with multiple bindings is appreciated :-)

@AnonSphere
Copy link
Author

A redirection ignoring the port would be better in any case as cherokee could not listen to one port as tls and as regular port. So this will always fail. :-)

http://webserver.com/ => https://webserver.com/
http://webserver.com:2080/ => https://webserver.com/

I think, the easiest solution would be, if you add a field for a redirection, where you can add a full url including the port and if no url is given, the user should be redirected to https without any port.

@skinkie
Copy link
Member

skinkie commented Feb 2, 2013

Could you validate for us that the following commit implements the desired behavior for now?

ef762c3

@AnonSphere
Copy link
Author

As far as I can say (from my c knowledge), it looks good – but I could not validate all use cases in my environment. You would have to wait till monday for that. 👍

@skinkie
Copy link
Member

skinkie commented Feb 2, 2013

I am happy to wait till monday :)

@AnonSphere
Copy link
Author

Sorry, I just forgot to tell you, that it seems to work as expected. 👍

@skinkie
Copy link
Member

skinkie commented Mar 2, 2013

Lets close this one, I guess we could figure out some more advanced scheme later.

@skinkie skinkie closed this as completed Mar 2, 2013
@skinkie
Copy link
Member

skinkie commented Jun 10, 2013

I am about to commit a patch which actually could would solve the HTTPS on non-standard ports. It seemed we had the code already for more than two years.

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

No branches or pull requests

2 participants