Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
Background:
This is a follow-on for Proposal 2 - it is for each of use TLS offloading to external proxies.
When using external TLS/TCP bridges users encounter a mismatch when the URI/socket matcher cannnot find a matching TLS socket. Users can work around this by forcing t_relay_to but it is not a natural map.
Some dancing with record-route headers is usually necessary
Proposal 2b This proposal is to have a marker in config file on TCP listeners that they are in fact proxy'd TLS connections. So the look-and-feel should be TLS except that they skip mod_tls processing.
When the config searches for matching socket this type of TLS-proxy will be found.
Benefits:
- can sidestep more exotic mod_tls problems with OpenSSL; user just offloads to HAProxy et al - seamless config: these proxy'ied sockets have enough metadata that look like TLS socket for URIs, record-route etc handling
Richard (Shih-Ping)
Hello,
isn't enough what can be achieved with:
listen=tcp:x.y.z.w:5060 advertise tls:a.b.c.d:5061
Cheers, Daniel
On 28.06.25 03:48, Richard Chan via sr-dev wrote:
Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
Background:
This is a follow-on for Proposal 2 - it is for each of use TLS offloading to external proxies.
When using external TLS/TCP bridges users encounter a mismatch when the URI/socket matcher cannnot find a matching TLS socket. Users can work around this by forcing t_relay_to but it is not a natural map.
Some dancing with record-route headers is usually necessary
Proposal 2b This proposal is to have a marker in config file on TCP listeners that they are in fact proxy'd TLS connections. So the look-and-feel should be TLS except that they skip mod_tls processing.
When the config searches for matching socket this type of TLS-proxy will be found.
Benefits:
- can sidestep more exotic mod_tls problems with OpenSSL; user just
offloads to HAProxy et al
- seamless config: these proxy'ied sockets have enough metadata that
look like TLS socket for URIs, record-route etc handling
Richard (Shih-Ping)
Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org To unsubscribe send an email to sr-dev-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hello Richard,
it is probably not fully related, but are you aware of the haproxy protocol support inside of Kamailio core? This was added to facilitate this offloading functionality. I personally did not used it so far, so I cannot give details how good it works.
Cheers,
Henning
From: Richard Chan via sr-dev sr-dev@lists.kamailio.org Sent: Saturday, June 28, 2025 3:49 AM To: Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org Cc: Richard Chan shihping.chan@gmail.com Subject: [sr-dev] Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
Background:
This is a follow-on for Proposal 2 - it is for each of use TLS offloading to external proxies.
When using external TLS/TCP bridges users encounter a mismatch when the URI/socket matcher cannnot find a matching TLS socket. Users can work around this by forcing t_relay_to but it is not a natural map.
Some dancing with record-route headers is usually necessary
Proposal 2b This proposal is to have a marker in config file on TCP listeners that they are in fact proxy'd TLS connections. So the look-and-feel should be TLS except that they skip mod_tls processing.
When the config searches for matching socket this type of TLS-proxy will be found.
Benefits:
- can sidestep more exotic mod_tls problems with OpenSSL; user just offloads to HAProxy et al - seamless config: these proxy'ied sockets have enough metadata that look like TLS socket for URIs, record-route etc handling
Richard (Shih-Ping)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Richard Chan