A) if you have different box versions and want to do firmware updates
B) if different households which shall not get all tonies of all participating people.
Be aware, that the gui does not (yet?) support different certs. I am not sure how the case 2 households with different tonies which shall only be owned by one, will be handled. I assume there is no distinction on teddycloud side, but still on boxine. Maybe @0xbadbee can enlighten this a little bit?
You use the same CA for all boxes, as it must fit to your server.
The client certificates you don’t need to exchange.
Yes
This is the easiest way to go. The toniebox has no SNI support. There may be a way to use a reverse proxy that reroutes all TLS traffic to a specific backend host, if no SNI is sent. (Don’t know in detail how this works, just a theory)
This is the way to go, but this won’t protect the API of the Toniebox and anybody knowing the endpoint could access your content files.
Beside all that, be sure you use the docker variant + the ubuntu version, as this protects against many security related bugs.
Both, authenticated access to your backend(s) and routing traffic based on the client certificate behind a reverse proxy (e.g. nginx) w/o SNI information can be resolved using mTLS on your catchall domain.
Regarding acess to the web ui(s) the same teddycloud(s) may be exposed using SNI information and a authentication mechanism of your choice, e.g. http basic authentication.
Would you happen to have an example for Haproxy on how to do this? Looks like SNI and mTLS is rather exclusive. One is an HTTP feature the other is part of the TLS handshake.
I wouldn’t want users with arbitrary client certs to go down the mTLS road when they actually want to connect to any of the websites I run on the machine…
I do not have a HAProxy configuration but porting the nginx configuration to HAProxy should be straightforward.
The following nginx configuration uses mTLS w/ a mapping to allow clients based on the fingerprint of their certificate.
In this example teddycloud runs on port 443 and nginx on 8443. In my setup both services are Containerized running in one pod and I ingress traffic on the host ip from port 443 to the nginx container on port 8443.
This allows specified toniebox clients to connect to teddycloud through nginx.
For access via web browsers you can expose the same teddycloud instance based on the SNI hostname using a separate nginx configuration file for the corresponding DNS name.
Just for reference, answering this from all the useful pieces of information I received…
In the flash file only the Boxine CA is replaced by TeddyCloud’s CA.
The existing box certs are dumped of course in order to be used by TeddyCloud when talking to Boxine.
The config.overlay.ini file allows for proper configuration of multiple boxes - each referenced by their dumped client certificates.
With release 0.5.2 hosting TeddyCloud becomes a thing
The only technical challenge is running the SSL backend without a second public IP address. If you use NGINX as a reverse proxy you’ll find a way to do it above.
In case of HAProxy I am using the following snippet:
global
...
crt-base /usr/local/etc/haproxy/certs
...
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
...
userlist TeddyCloudUsers
user teddy insecure-password SomeStrongPasswordHerePlease
...
frontend tcp-in
bind *:443,[::]:443 v6only
mode tcp
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend tcp2http if { req.ssl_sni -i tc.example.org }
use_backend tcp2http if { req.ssl_sni -i regular.site1.com }
use_backend tcp2http if { req.ssl_sni -i regular.site2.com }
...
use_backend tcp2http if { req.ssl_sni -i final.regular.site.com }
default_backend teddycloud
frontend http-in
bind *:80,[::]:80 v6only
bind 127.0.0.1:10443 alpn h2,http/1.1 ssl crt /usr/local/etc/haproxy/certs accept-proxy
...
acl teddycloud hdr(host) tc.example.org
acl teddycloud_auth http_auth(TeddyCloudUsers)
http-request auth if teddycloud !teddycloud_auth
use_backend teddycloud_web if teddycloud
...
default_backend internalserver
backend tcp2http
mode tcp
server haproxy-loopback 127.0.0.1:10443 check send-proxy-v2
backend teddycloud
mode tcp
server teddycloud teddycloud:443 no-check
backend teddycloud_web
mode http
server teddycloud_web teddycloud:80 no-check
backend internalserver
server internalserver apache:80
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
http-request add-header X-Forwarded-Host %[hdr(Host)] if { ssl_fc }
The cool thing about HAProxy is that it can act as a TCP proxy. The benefit of which is that it does not have to terminate the SSL connection (no unsafe legacy renegotiation with the actual backend, no need to share any certificates). Unfortunatly the only piece of information passed at layer 4 is the SSL connection setup (no certificates or anything here) - the only useful thing is the SNI though.
It would be easy to route to the Teddycloud backend based on the SNI, but here of all things the box does NOT pass an SNI.
Hence, the setup needs to tediously document all hosted domains and route them based on SNI to the actual internal server.
The default routing will be applied to all SSL traffic WITHOUT SNI (= our TonieBoxes) or without specified SNI.
As a bonus I included BasicAuth authentication for the TeddyCloud frontend.
Hi,
was anyone able to configure Caddy as reverse proxy?
I have configured a normal reverse proxy for my subdomain (by default it creates its own certificates), but no access from the Toniebox appears in the access log.
Switching off auto https and linking the Teddycloud certificates for this subdomain did not help either.
