mixing HTTP and HTTPS forwards in one/two relays

[rbucker]

I saw this question in another doc... "mixing HTTP and HTTPS forwards in one relay" and in the context of the other question it was impossible to understand the complete POV.

In my case I have two relays. One for HTTP and one for HTTPS (incoming/server)... but then the HTTP relay forwards to my static httpd server as HTTP and my appserver as HTTP. And in my HTTPS relay I forward my static requests 'with tls' and my appserver... as http (no tls).

The challenge seems to be that the https relay is always trying to connect to blast with tls.

One thing I have not figured out... what is the default "forward to" if my match does not match?

and the sample code had a

    pass tagged ok forward to <www>

but when I tried it seemed to overwrite the forward to to blast... "last match wins" (if this is the case then the order of my match is wrong.)

    pass tagged ok forward to <www>
    pass tagged ok forward to <blast>

most of my relayd.conf.

table <www> { 127.0.0.1 }
table <blast> { 127.0.0.1 }

http protocol "http" {
    match request path "/.well-known/acme-challenge/*" forward to <www>
    match request url "my.appserver.com" forward to <blast>
    match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
    match request header set "X-Forwarded-Port" value "$REMOTE_PORT"
}

http protocol "https" {
    #tls ca file "/etc/ssl/cert.pem"
    tls ciphers $list
    tls keypair "my.appserver.com"
    tls keypair "webserver.com"

    return error

    match request header "Path" value "/.well-known/acme-challenge/*" forward to <www>
    match request header "Host" value "my.appserver.com" forward to <blast>

    match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
    match request header set "X-Forwarded-Port" value "$REMOTE_PORT"

    match response header set "Content-Security-Policy" value \
        "default-src 'self'"
    match response header set "Referrer-Policy" value "no-referrer"
    match response header set "Strict-Transport-Security" value \
        "max-age=15552000; includeSubDomains; preload"
    match response header set "X-Content-Type-Options" value "nosniff"
    match response header set "X-Frame-Options" value "SAMEORIGIN"
    match response header set "X-XSS-Protection" value "1; mode=block"

    match method POST tag ok
    match method GET tag ok
    match method HEAD tag ok

    block

    pass tagged ok 
#forward to <www>
    #pass tagged ok forward to <blast>
}
relay "https" {
    listen on $ipv4 port https tls
    protocol "https"
    forward with tls to <www> port 8443 check https "/" code 200
    forward to <blast> port 1900 check http "/" code 401
}

relay "http" {
    listen on $ipv4 port http
    protocol "http"
    forward to <www> port 8080 check http "/" code 302
    forward to <blast> port 1900 check http "/" code 401
}

[rbucker]

I started to read a lot of posts and I was beginning to believe that mixing the client relay was just unsupported. I've come to the conclusion this is definitely a bug.

Common with everyone else's experience the BLAST table which is not TLS enabled seems to open the connection to the server as TLS... even though it does not have "with tls"

relay "https" {
    listen on $ipv4 port https tls
    protocol "https"
    forward with tls to <www> port 8443 check https "/" code 200
    forward to <blast> port 1900 check http "/" code 401
}

However, when I added TLS to my "blast" app server...I received more/similar errors even though my app server was ok. (tested from the CLI). Then I added the "with tls" to the blast relay and VOILA it started working.

relay "https" {
    listen on $ipv4 port https tls
    protocol "https"
    forward with tls to <www> port 8443 check https "/" code 200
    forward with tls to <blast> port 1900 check https "/" code 401
}

Without "with tls" and app server running in plain http... The relay log suggested "TLS handshaking" error.

Without "with tls" and the appserver running https... the relay log suggested "tlsv1 allert protocol, version"

But when I added "with tls" and had the server running https.... all was fine.

This suggests that mixing is not possible or a bug and/or "with tls" is not completely documented.