Skip to content

No redirect when using warp-tls #60

Closed
cgaebel opened this Issue Apr 8, 2012 · 16 comments

4 participants

@cgaebel
cgaebel commented Apr 8, 2012

When I configure my site with warp-tls, http traffic is sent to a page with the contents of:

http://pastebin.com/tuthyb5A

HTTPS traffic works fine.

Can this be changed to redirecting to the https site automatically? I don't know how this is done on a low level, but it's possible! I swear!

@snoyberg
Yesod Web Framework member
snoyberg commented Apr 9, 2012

There is insufficient information here. Can you elaborate?

@cgaebel
cgaebel commented Apr 9, 2012

Fixed. Sorry, github ate my post because of invalid characters.

@snoyberg
Yesod Web Framework member
snoyberg commented Apr 9, 2012

Ahh... I get it. What you'll need to do is have two separate Warp instances. A non-TLS instance should listen on port 80, and it should have an application that just redirects to port 443. Then have warp-tls listening on 443, and everything should work out correctly.

@cgaebel
cgaebel commented Apr 9, 2012

What if I'm serving on a different port?

For my application, I'm running on 8080. If I connect to http://localhost:8080, it gets an error. Where is https://localhost:8080 traffic going? Does that get redirected to 443?

@snoyberg
Yesod Web Framework member
snoyberg commented Apr 9, 2012

Hmm... what you're looking for is a system that automatically detects if the request was HTTP or HTTPS and handles it accordingly. I'm not aware of any servers working that way, and Warp certainly doesn't have that ability right now. It's an interesting idea though, but I think I'd need to get some changes pushed to tls as well.

@cgaebel
cgaebel commented Apr 9, 2012

Alright. Do you want me to move this issue over there, then?

@snoyberg
Yesod Web Framework member
snoyberg commented Apr 9, 2012

Nah, I'll ask him right here:

@vincenthz Here was my thought here. If TLS were modified so that it's not necessary to use Handles, then I could grab the first chunk of data sent and check if it's a normal HTTP request (the first 20 or so bytes are all in the ASCII range) or HTTPS. Then I could resubmit that first chunk to tls.

Basically, I'd be looking for a conduit interface in tls. I don't expect tls to use conduit itself, but if it exported the primitives, I could write a tls-conduit library as a wrapper. Of course, if you want to put the conduit functions in tls directly, I wouldn't complain either.

I haven't looked as tls internals for a while, so I don't know how invasive such a change would be. But essentially, any function that currently pulls data from the Handle would have to be rewritten to accept a chunk of data being pushed to it.

@vincenthz

@snoyberg: the IO operations in TLS have been vectorised in tls 0.8. the Handle interface is just for convenience, but the interface is already taking a 'flush', 'recv' and 'send' operations that can pull/push data from/to anywhere, as long as the interface is respected.

The current version:

https://github.com/vincenthz/hs-tls/blob/master/Network/TLS/Context.hs#L142

FYI, i add a link to the next version (1.0) where i've made thing clearer related to the backend (but previous work the same really modulo some name differences):

https://github.com/vincenthz/hs-tls/blob/next/Network/TLS/Context.hs#L179

@gregwebs
Yesod Web Framework member
gregwebs commented Apr 9, 2012

@wowus trying to exactly understand the use case. Why are you deploying to 8080? Someone else is already taking up 80?

@cgaebel
cgaebel commented Apr 9, 2012

It's embedded in another application, and I don't want to be so presumptuous as to assume the user doesn't need port 80.

@snoyberg
Yesod Web Framework member
snoyberg commented Jul 1, 2012

@vincenthz Is this non-Handle API available now? I'm having trouble finding it in the public-facing API.

@vincenthz

looks like it was missing from the export list. it's now exported as clientWith and serverWith in tls 0.9.6. (note that context creation is now unified in tls 1.0 and it's now called contextNew and contextNewOnHandle)

@snoyberg
Yesod Web Framework member
snoyberg commented Jul 3, 2012

Thanks @vincenthz. I just pushed a change to take advantage of serverWith. The one thing I wouldn't mind some feedback on is my HTTP vs HTTPS sniffing: I'm currently checking the first five bytes to see if they're in the range 9-126. Is that reliable enough?

@vincenthz

It should be: byte 2 is very likely be 0x3 (or 0x2) and byte 3 0x{0,1,2,3}. however byte 1 is going to be 0x16 (in your range), and the byte 4 and 5 (length) could be anything and thus match your range too.

However you could just test that the first byte is 0x16 (tls handshake type). as it's not ascii, it shouldn't be an authorized HTTP request method (IIRC the RFC) and have to be TLS.

@snoyberg snoyberg added a commit that referenced this issue Jul 3, 2012
@snoyberg snoyberg Sniff TLS via 0x16 (#60) 1dbf88f
@snoyberg
Yesod Web Framework member
snoyberg commented Jul 3, 2012

Thanks, 0x16 sounds like a great idea.

@wowus Does this address your issue?

@cgaebel
cgaebel commented Jul 3, 2012

LGTM.

@cgaebel cgaebel closed this Jul 3, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.