Connecting to my website via HTTP attempts TLS handshake

[silverensign (Peter)]

I am running Caddy Server version 0.10.10
It is running on an Ubuntu 17.10 VM

Caddyfile:

mycustomdomain.foobar {
     log /var/www/caddy_log
     gzip
     proxy /foo redacted.local:port#
     proxy /bar redacted.local:port#
     proxy / redacted.local
     tls myemail@mydomain.foobar
}

I have an instance of caddyserver serving as a reverse proxy. Whenever I use a web browser (from outside my LAN) & go to my website via HTTPS (ie. https://mydomian.foobar) everything works fine. However when I try to attempt to connect via HTTP (ie. http://mydomain.foobar, or just mydomain.foobar in some browsers) I get prompted to download a 7 byte file whose name is a string of letters & numbers. The contents of this file (as seen in notepad++) is . I’m assuming this is useless as the underlying data probably isn’t characters or a string.

Caddy logs doesn’t give me anything but looking at systemd logs gives me the following:

2018/02/15 21:08:00 http: TLS handshake error from public_ip_address:42076: tls: first record does not look like a TLS handshake

So does this means Caddy assumes my http connections should be attempting to authenticate via TLS? How do I prevent this then? Redirect HTTP connections to HTTPS? (ultimately I would like to only use HTTPS)

Let me know If I can provide anymore information or if something I said is clear as mud. Thanks.

[Whitestrake (Matthew Fay)]

@silverensign

So does this means Caddy assumes my http connections should be attempting to authenticate via TLS?

Shouldn’t be! Your Caddyfile, assuming mycustomdomain.foobar is a real and publicly accessible domain name, should be issuing redirects over HTTP to requests on port 80.

Can you post the output of curl -IL mycustomdomain.foobar? (It should be, if everything is working correctly, two sets of headers - firstly for a HTTP redirect, then for a HTTPS site).

[silverensign (Peter)]

I don’t know why I hid my domain name, paranoia I suppose. I’m assuming I need to do run this command from a computer outside of my LAN?

Calling that command returns nothing. just a newline.

oneplus3:/ $ curl -IL peterhansen.tech

oneplus3:/ $

I tried it using google.com and it gave me:

oneplus3:/ $ curl -IL google.com
HTTP/1.1 200 OK
Date: Fri, 16 Feb 2018 05:16:41 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2018-02-16-05; expires=Sun, 18-Mar-2018 05:16:41 GMT; path=/; domain=.google.com
Set-Cookie: NID=123=HGuHbiICZ7WLBcycn9zwsE-iYsMEzcMSVmrCv14rNz7d4r2M2STWJqt9Qc7vl7sN1OECd4GBdoJPHtambLi48hC1-Ht6m4LWQA9c7y77mHB5evI3G6megeGKRlnyEiXk; expires=Sat, 18-Aug-2018 05:16:41 GMT; path=/; domain=.google.com; HttpOnly
Transfer-Encoding: chunked
Accept-Ranges: none
Vary: Accept-Encoding

So it works.

Running it within my LAN yields this:

peter@misc:~$ curl -IL peterhansen.tech
HTTP/1.1 301 Moved Permanently
Connection: close
Location: https://peterhansen.tech/
Server: Caddy
Date: Fri, 16 Feb 2018 05:21:32 GMT
Content-Type: text/plain; charset=utf-8

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 195
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Feb 2018 05:21:32 GMT
Etag: “p42hnd5f”
Last-Modified: Tue, 13 Feb 2018 02:30:49 GMT
Server: Caddy
Server: Caddy

Except I have a rule on my LAN’s DNS server to reroute all traffic destined for peterhansen.tech to the local IP address of the VM.

Could this then be an issue with how I set up my router? Or maybe even my namecheap DNS settings?

[Whitestrake (Matthew Fay)]

@silverensign

Could this then be an issue with how I set up my router? Or maybe even my namecheap DNS settings?

Could be DNS, but maybe not your settings, per se. I get the same result you do from my machine, and Caddy’s issuing a 301 over HTTP just fine and accepting the HTTPS request.

Can you run dig peterhansen.tech on both the machine that returned no result, and the machine that successfully connected to Caddy from within the LAN?

[silverensign (Peter)]

I just figured it out. It was my Router’s port forwarding settings. I accidentally forwarded port 80 on the WAN interface to port 443 of the VM. I use PfSense so I guess I accidentally chose “HTTPS” instead of “HTTP”.

If you try the curl command again it returns the headers now and connecting to my website via HTTP redirects to HTTPS. Thanks for the help, I wouldn’t of even thought of checking my router settings but seeing the difference between WAN & LAN systems when running curl made me curious if I had screwed something else up.

[Whitestrake (Matthew Fay)]

Excellent! pfSense is great, I run Caddy behind mine as well and also run split DNS resolution. Can get a bit weird sometimes, but once it’s all set up, it’s rock solid.

[silverensign (Peter)]

I do have one other issue if you have some time.

If you go to peterhansen.tech/graphics and then click on any one of the links it returns a 404 b/c it removes the “graphics” from the uri.

But if you go to peterhansen.tech/graphics/ then everything works fine.

I assumed I could either rewrite or redirect …/graphics to …/graphics/ and everything would work but I did that and it had no effect. I’m going to try it again real quick now that my first problem is solved but any thoughts on what I should poke around with?

[Whitestrake (Matthew Fay)]

As far as I’m aware, Caddy should be rewriting the indexes to use canonical trailing slashes.

What’s your Caddyfile look like for that one?

[silverensign (Peter)]

http://foobar.local/graphics {
   root /www/graphics
   gzip
   log /www/caddy_metadata/graphics_log
   filemanager /upload /www/graphics {
     database /www/caddy_metadata/caddy_plugin_database
   }
   browse /
}

also in my reverse proxy Caddyfile i tried adding

rewrite /graphics /graphics/

but it had no affect.

[Whitestrake (Matthew Fay)]

Hmm, that label is HTTP-only, but I’m getting redirected to HTTPS.

I’m assuming that’s a second Caddy you’re proxying back to on a separate host on your LAN?

What does the proxy line look like in your edge Caddy?

[silverensign (Peter)]

Correct.

All my traffic on WAN port 80 & 443 is routed to a caddy server on it’s own VM which serves as a reverse proxy (the one I was initially having troubles with). Lets Call it VM1.

I have another VM (VM2) which hosts my graphics page & files like you saw. VM1 handles all the TLS/SSL & HTTPS encryption as it sits in between the WAN & LAN. All of my other services are not encrypted as they are on my LAN, but since they pass through my reverse proxy to get to anywhere on the WAN they become encrypted.

Does that make sense?

VM1 (reverse proxy server) Caddyfile

peterhansen.tech {
    log /var/www/caddy_log
    gzip
    proxy /service1 VM3.local:port#
    proxy /service2 VM3.local:port#
    proxy / VM2.local
    tls myemail@gmail.com
}

VM2 (graphics & file server) Caddyfile

http://VM2.local {
   root /www/frontpage
   gzip
   log /www/caddy_metadata/frontpage_log
}

http://VM2.local/graphics {
   root /www/graphics
   gzip
   log /www/caddy_metadata/graphics_log
   filemanager /upload /www/graphics {
     database /www/caddy_metadata/caddy_plugin_database
   }
   browse /
}

[Whitestrake (Matthew Fay)]

Hmm, seems like you’ve run into an issue similar to this one:

https://github.com/mholt/caddy/issues/1561

It’s definitely some quirky interaction of the proxy and the site label.

I propose you mv /www/graphics /www/frontpage and then structure VM2 Caddyfile like this instead:

http://VM2.local {
  root /www/frontpage
  gzip
  log /www/caddy_metadata/frontpage_log

  log /graphics /www/caddy_metadata/graphics_log
  filemanager /graphics/upload /www/frontpage/graphics {
    database /www/caddy_metadata/caddy_plugin_database
  }
  browse /graphics
}

It should be functionally identical.

(edited to update a filemanager path I forgot to update)

[silverensign (Peter)]

Bingo, That worked like a charm. Thank you so much. I have been mucking around with these issues for the past week and it was driving me up a wall.

[Whitestrake (Matthew Fay)]

No worries! Glad to help!

[Whitestrake (Matthew Fay)]

I just realised I made one tiny mistake in my proposed VM2 Caddyfile that you should address if you haven’t already, @silverensign;

The filemanager directive should instead start with filemanager /graphics/upload /www/frontpage/graphics to respect the web root shuffling around. Otherwise uploads would go to the old location, whoops

[silverensign (Peter)]

Ah, good catch; Everything is working great. Again, thanks so much for the help!