Re: relayd ssl termination advice
Oooo I wasn't familiar with sniproxy. I DO have a working haproxy configuration, and even though it is good software, I find myself barely understanding and was wanting something simpler. sniproxy looks to be exactly what I need :) I'm going to give this a try. Thank you for pointing this piece of software out to me! Courtney On 10/10/23 01:29, Stuart Henderson wrote: On 2023-10-10, Courtney wrote: Maybe I am wrong, but I thought that relayd was not capable of doing TLS pass through? That would be preferable if it is possible. If you do TLS passthrough (i.e. passing packets directly to the origin rather than doing "back to back" and terminating one TLS connection and making a second one) then the renewed certs need to be copied on to the backend machines, which was a thing you were asking about avoiding. Obviously you don't have access to HTTP headers at that point so you can't inspect Host, but you can look at SNI from the TLS ClientHello. (encrypted SNI doesn't matter much here - a small server will be sufficiently identifiable from the IP address alone so there's little benefit in using eSNI, so you can simply not configure tge server to use it). If you *do* want that, sniproxy is made for doing just that, so should be simple to configure, but it's also possible with at least haproxy and nginx. https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Passing the client's source IP through to the origin server can be a bit fiddly with this method. haproxy has a proxy protocol which can be used to pass it through but the origin server needs to understand it. It can also be done by essentially 'spoofing' the original client IP for the TCP connection to the origin - which works with any origin server software, but the proxy needs to be on a machine on the normal network path between the client and origin. (For a normal "back to back" proxy with two separate TLS connections, for https this would normally be done by adding X-Forwarded-For or similar header). relayd can definitely pass a TCP connection to a different backend based on IP address or port. There should probably be a way to use https Host headers as part of the decision by doing back-to-back TLS connections though like everything with relayd filters it will probably require hitting your head against a wall repeatedly before getting it to work ;) I don't _think_ there's any way to use SNI to make that decision in relayd. On 10/9/23 00:42, Kapetanakis Giannis wrote: On 08/10/2023 04:00, Courtney wrote: Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 2023-10-10, Courtney wrote: > Maybe I am wrong, but I thought that relayd was not capable of doing > TLS pass through? That would be preferable if it is possible. If you do TLS passthrough (i.e. passing packets directly to the origin rather than doing "back to back" and terminating one TLS connection and making a second one) then the renewed certs need to be copied on to the backend machines, which was a thing you were asking about avoiding. Obviously you don't have access to HTTP headers at that point so you can't inspect Host, but you can look at SNI from the TLS ClientHello. (encrypted SNI doesn't matter much here - a small server will be sufficiently identifiable from the IP address alone so there's little benefit in using eSNI, so you can simply not configure tge server to use it). If you *do* want that, sniproxy is made for doing just that, so should be simple to configure, but it's also possible with at least haproxy and nginx. https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Passing the client's source IP through to the origin server can be a bit fiddly with this method. haproxy has a proxy protocol which can be used to pass it through but the origin server needs to understand it. It can also be done by essentially 'spoofing' the original client IP for the TCP connection to the origin - which works with any origin server software, but the proxy needs to be on a machine on the normal network path between the client and origin. (For a normal "back to back" proxy with two separate TLS connections, for https this would normally be done by adding X-Forwarded-For or similar header). relayd can definitely pass a TCP connection to a different backend based on IP address or port. There should probably be a way to use https Host headers as part of the decision by doing back-to-back TLS connections though like everything with relayd filters it will probably require hitting your head against a wall repeatedly before getting it to work ;) I don't _think_ there's any way to use SNI to make that decision in relayd. > > > On 10/9/23 00:42, Kapetanakis Giannis wrote: >> On 08/10/2023 04:00, Courtney wrote: >>> Ultimately, I want to serve a handful of services on 80/443 that are >>> easily accessible internally and externally, and I don't want to have >>> unencrypted traffic between relayd and my server for the services that >>> are passing sessions and such. >> >> Then don't terminate the connection on relayd. Use redirect instead of a >> relay and terminate on the web server itself. >> >> It will also be a little faster since the router/relayd will only route/pass >> the packets to the appropriate backend server. >> >> For internal traffic you have to use appropriate DNS (local IP) and maybe a >> different certificate. >> >> G >> > > -- Please keep replies on the mailing list.
Re: relayd ssl termination advice
Maybe I am wrong, but I thought that relayd was not capable of doing TLS pass through? That would be preferable if it is possible. Courtney On 10/9/23 00:42, Kapetanakis Giannis wrote: On 08/10/2023 04:00, Courtney wrote: Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 08/10/2023 04:00, Courtney wrote: > Ultimately, I want to serve a handful of services on 80/443 that are > easily accessible internally and externally, and I don't want to have > unencrypted traffic between relayd and my server for the services that > are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 08.10.2023 03:00, Courtney wrote: Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. Currently I have a Nextcloud server and a gitea server, but only the Nextcloud server is being port forwarded on 80/443. I want to make my gitea server publicly visible as well as a couple other projects. My thought is to have relayd running on my router and match Host headers and forward it to my servers based on the Host. This will also conveniently let me handle renewing Let's Encrypt certs in one place. I already do this right now with a VPS, but I have a wireguard tunnel to my house in this case to access the backend, which is encrypting the traffic from my relayd server to my backend web server. With my Nextcloud and gitea server, if I terminate SSL at my router, the connection between my router and Nextcloud/gitea web servers would be unencrypted. Even though it is in my own house, I don't really like that idea. It seems to be overkill too to do peer to peer wireguard between my Nextcloud/gitea servers in my house. I was wondering if this would actually be proper or if there are any other ideas you all might have. Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Thank you, Courtney I have a similar situation at home. I use TLS to encrypt the traffic between relayd(8) and the actual web servers. On the web servers I use self-signed certificates which are valid for several decades. When it comes to administrative access on the web servers I use my router as ProxyJump and/or configure local tunnel(s) in ssh(1). Cheers, Bruno
Re: relayd ssl termination advice
On 10/7/2023 9:00 PM, Courtney wrote: Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. I'm currently doing this with haproxy by having it inspect the SNI on the incoming traffic and route based on that. At the time I set it up relayd didn't support SNI inspection, not sure if it's been added since. The main downsides to doing this: - haproxy has to be in the traffic path - haproxy has to run as root (ick) The traffic isn't decrypted by haproxy at all. I'm not sure how this will be affected by encrypted SNI/encrypted client hello. Relayd can also decrypt the traffic, then re-encrypt it from relayd to the web server. See "TLS RELAYS" in the man page.
relayd ssl termination advice
Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. Currently I have a Nextcloud server and a gitea server, but only the Nextcloud server is being port forwarded on 80/443. I want to make my gitea server publicly visible as well as a couple other projects. My thought is to have relayd running on my router and match Host headers and forward it to my servers based on the Host. This will also conveniently let me handle renewing Let's Encrypt certs in one place. I already do this right now with a VPS, but I have a wireguard tunnel to my house in this case to access the backend, which is encrypting the traffic from my relayd server to my backend web server. With my Nextcloud and gitea server, if I terminate SSL at my router, the connection between my router and Nextcloud/gitea web servers would be unencrypted. Even though it is in my own house, I don't really like that idea. It seems to be overkill too to do peer to peer wireguard between my Nextcloud/gitea servers in my house. I was wondering if this would actually be proper or if there are any other ideas you all might have. Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Thank you, Courtney
