I’ve been successfully experimenting with tls-alpn-01 challenges and made a new transparent proxy with built-in responder to make this type of challenge easy as a breeze.
I named the new piece of code ualpn and made it available in the ‘ualpn’ branch of uacme on github:
Feedback and suggestions are welcome
Pretty cool!
Although only supported by nginx, you can also completely avoid proxying non-ALPN traffic through uacme by having nginx do the ALPN routing:
stream {
map $ssl_preread_alpn_protocols $tls_port {
~\bacme-tls/1\b 10443;
default 8443;
}
server {
listen 443;
listen [::]:443;
proxy_pass 127.0.0.1:$tls_port;
ssl_preread on;
}
}
A long time ago I also toyed with the idea of only proxying connections while the ACME client is running (using an iptables prerouting redirect), otherwise the connection is untouched. It seemed to work fine, but potentially fragile.
In the end I think most server administrators are probably not going to want to make such dramatic configuration changes just to support TLS-ALPN. This stuff should really be native in the webserver (like with Caddy), or at least how mod_md does it.
Yes, I don't like that kind of trick with iptables either.
Maybe. But on the other hand many admins trust transparent proxies such as haproxy and similar.
The core of ualpn is event-driven and can efficienly proxy heavy duty traffic. In addition on systems (such as linux) supporting the splice() system call, ualpn is optionally able to move network data without copying it to/from kernel/user address space.
unlike iptables tricks, ualpn should be portable to other UNIX systems and will work with any webserver, independently. Try it out and let me know what you think.
I’ve just added RFC8738 to the code
I have now merged the branch into master.
and the manpage is now also available in html format:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.