How to exempt a particular URL from being served by SSL

Help
1

I do have a domain which should be served by SSL execpt on specific URL.

Example: www.mydomain.com should generally be served by SSL, execpt of www.mydomain.com/nosslpath/

How can I do that? I tried many many variants to no avail. Here I have found how to do that with nginx: ssl - Redirect all http to https in nginx, except one file - Stack Overflow

Thanks for any hints.

2

Hi @treviser,

This can be achieved, but it should be noted that this is bad practice!

https://www.example.com, http://www.example.com/nosslpath {
  ...
}

# Upgrade normal HTTP requests
http://www.example.com {
  redir https://{host}{uri}
}

# Downgrade HTTPS for /nosslpath
https://www.example.com/nosslpath {
  redir http://{host}{uri}
}

Assuming that you’re serving the same site and scheme is the only thing that changes for /nosslpath. Otherwise, if separate handling is required, split the top two labels into their own site blocks.

3

Hey, welcome back Ermin!

Um, why are you doing this? If I may ask.

4

I have a legacy backend and a legacy iOS app which I can not touch anymore. The legacy app consumes an XML file provided by said URL and it must be non-SSL. One of the customer consumes another URL of the web frontend in an iFrame on a new, SSL-secured website and faces a “Mixed content” error, if this URL is not provided as SSL. I still need it for a couple of weeks until the new solution will be ready :slight_smile:

1 Like
5

Thank you very much for your help. Unfortunately it does not work. I did try it your way and the opposite way (upgrade a particular URL to SSL and leave the rest unsecured), in any case the extra ULR does not work, either I get a 404 or a fallback page. But if the complete site is non-SSL, everything works fine.

Here is my caddyfile based on your suggestion:

http://www.whitehouse.twanda-hosting.ch, https://www.whitehouse.twanda-hosting.ch/external/offerings/ {

  proxy / http://192.168.xxx.xxx:8080 {
      transparent
      }

  gzip
  log /var/log/caddy/twandaOld.access.log
  errors /var/log/caddy/twandaOld.error.log
  tls {
      max_certs 200
      }
}

# Downgrade normal HTTP requests
https://www.whitehouse.twanda-hosting.ch {
  redir http://{host}{uri}
}

# Upgrade HTTPS for sslpath
http://www.whitehouse.twanda-hosting.ch/external/offerings/ {
  redir https://{host}{uri}
}```
6

I think you have http and https in the wrong places. Also make sure your browser cache isn’t interfering.

7

Definitely check browser cache, because this method definitely works.

It seems like you don’t need to explicitly downgrade clients, so I left that part out, but here is a live working concept. Effectively what we’re doing is accepting HTTPS across the board for simplicity, but allowing HTTP requests for the endpoints specified.

whitestrake at ishtar in /docker/web
→ cat caddyfiles/nosslpath.whitestrake.net.caddy
https://nosslpath.whitestrake.net, http://nosslpath.whitestrake.net/nossl, http://nosslpath.whitestrake.net/alsonossl {
  status 200 /
}

# Upgrade normal HTTP requests
http://nosslpath.whitestrake.net {
  redir https://{host}{uri}
}

As you can see, you can add more “upgrade-exempt” locations just by adding them to the label list.

Here’s the result:

whitestrake at apollo in ~/.dotfiles on master [!]
→ curl -I nosslpath.whitestrake.net
HTTP/1.1 301 Moved Permanently
Location: https://nosslpath.whitestrake.net/
Server: Caddy
Date: Sun, 28 Jan 2018 21:41:39 GMT
Content-Type: text/plain; charset=utf-8


whitestrake at apollo in ~/.dotfiles on master [!]
→ curl -I nosslpath.whitestrake.net/nossl
HTTP/1.1 200 OK
Server: Caddy
Date: Sun, 28 Jan 2018 21:41:47 GMT
Content-Type: text/plain; charset=utf-8


whitestrake at apollo in ~/.dotfiles on master [!]
→ curl -I nosslpath.whitestrake.net/alsonossl
HTTP/1.1 200 OK
Server: Caddy
Date: Sun, 28 Jan 2018 21:41:53 GMT
Content-Type: text/plain; charset=utf-8

Feel free to check for yourself - the URLs in the above snippets are live and I’ll leave them up for a while, it just serves empty Status 200’s to prove the concept, but it’ll definitely work for a proxy too.

1 Like
8

Thank you very much, I can see that it works. However, in my case the URL my backend receives must be somehow different than the one it receives, when I set the complete site to SSL off.
According to my console log, the Caddy creates the following GET request URL when SSL is completely turned off:
http://www.whitehouse.twanda.ch/winelist/
This works perfectly for my backend.
Using your suggestion, I assume that the URL must be something different, as the backend forwards it to a fallback URL.
By the way, my backend is tomcat6.
Is it possible that this is correlated with the “302 found” message I get in the console?

9

To be specific, Caddy should be sending:

  • GET /winelist/
  • With a Host: www.whitehouse.twanda.ch request header
    (along with some other headers too)
  • Over a HTTP connection
  • To the listener at 192.168.xxx.xxx:8080.

The Host header sent to the backend is lifted from the host requested by Caddy’s client.

I note that the transparent preset includes header_upstream X-Forwarded-Proto {scheme}. As far as I’m aware, this is the only method the backend can use to detect whether or not the original client connected via HTTP or HTTPS.

Whatever the backend is, it should be configured not to issue conflicting redirects. Given that it’s on an internal network, it might suffice to have it be totally permissive with respect to protocol.

1 Like
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.