[SR-Users] Dispatcher SNI Questions

Daniel-Constantin Mierla miconda at gmail.com
Wed Jan 6 09:24:22 CET 2021


Hello,

for the moment a workaround could be to loop back the keepalive to
kamailio via event_route[tm:local-request], which can be done via udp,
then you get the OPTIONS in the request_route and there do the logic to
select the tls profile you want. It adds an extra local hop on the path,
but it should not have any big impact.

Cheers,
Daniel

On 05.01.21 12:06, Tim Chubb wrote:
>
> Hi All
>
>  
>
> Is it possible to explicitly define the tls cert to be used per
> destination by dispatcher? 
>
>  
>
> I'm attempting to integrate with a service that requires domain name
> presented to match that of the cert.  Where the use of dispatcher is
> probably not as intended anyway as it targets the same set of
> destinations multiple times (primary and secondary endpoints for the
> service im integrating with), with multiple distinct set id’s
> (basically a set per customer for multi tenancy) which expects a sip
> ping per account to verify that connection is alive and healthy.
>
>  
>
> #Example Dispatcher list
>
> #Account 1
>
> 1 sip:a.cloudservice.com:5061;transport=tls
> <sip:a.cloudservice.com:5061;transport=tls> 8 1
> socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061
>
> 1 sip:b.cloudservice.com:5061;transport=tls
> <sip:b.cloudservice.com:5061;transport=tls> 8 1
> socket=tls:10.0.0.2:5061;ping_sni=sip.account1.com;ping_from=sip:sip.account1.com:5061;
>
> #Account 2
>
> 2 sip:a.cloudservice.com:5061;transport=tls
> <sip:a.cloudservice.com:5061;transport=tls> 8 1
> socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061;
>
> 2 sip:b.cloudservice.com:5061;transport=tls
> <sip:b.cloudservice.com:5061;transport=tls> 8 1
> socket=tls:10.0.0.2:5061;ping_sni=sip.account2.com;ping_from=sip:sip.account2.com:5061;
>
>  
>
> Currently I'm running a solution based around certs with multiple SAN
> (subject alternative name) defined, but this is a pain to
> administrate, and not as scalable as I would like. I want to be able
> to define multiple client:any tls profiles and explicitly send via
> that profile.  Its easy enough to do that in config using the tls
> xavps to define a server name and/or id. But for the sip options ping
> by dispatcher to work you need to specify the server name or id before
> the tm:local-request event route fire's.  
>
>  
>
> I've resorted to hacking away at dispatcher to see what would happen
> if I set the tls server name or id before the OPTIONS message is sent,
> and it works great for the first  tls client profile matched, but any
> others you define re-use the initial tcp connection so reuses the
> first connections tls config, thus presenting the wrong cert (I'm
> probably wrong but logs show only one tls complete_init() related to
> dispatcher pings and the second set’s pings skips all the tls init
> logging so suggests some thing is cached/reused, and logging on the
> service indicates cert name mismatch with set1s cert being offered) 
>
>  
>
> So I've hit a bit of a dead end, is there a way to force a new tcp
> connection per server name/id 
>
>  
>
> I fear outbound SNI might be a bit of a can of worms, for it to work
> nicely with dispatcher as is, would be an extension of the
> proto:host:port format to include a name or id, maybe something like:
>
> tls(name=sub.domain.com):10.0.0.5:5061
>
>  
>
> But that looks like it would have a lot of wide reaching knock-on
> effects, so setting it as an attribute like ping_from works fine as
> I'm currently doing, if I could force a new connection from dispatch.c….
>
>  
>
> The other thing that’s occurred to me is that it might be better to
> stop trying to adapt a small percentage of dispatcher’s functionality
> and trying to hammer a round peg into a square hole and instead try
> and create a new module similar to dispatcher in so much that it sends
> pings (that’s all I really need in this case) and use dispatcher as
> intended with a single set of non-repeated destinations for routing. 
> This would also allow much simpler integration with MS teams (if added
> ability to set contact address on the background pings) as well as the
> service im trying to integrate, and a more natural data set to be used
> as in my example you can see the only difference is the customers
> domain between each set.  How I would imagine it to work would be to
> create a tls connection per customer domain, then iterate through the
> connections per destination in pseudo json the data would look like this:
>
> {
>
> Destinations:[
>
> [1,[“a.cloudservice.com”,”b.cloudservice.com”]],
>
> [2,[“sip.pstnhub.microsoft.com”, “sip2.pstnhub.microsoft.com”,
> “sip3.pstnhub.microsoft.com”]
>
> ],
>
> Sources:[
>
> {uri:”sip.account1.com”,destinationMapping:[1]},
>
> {uri:”sip.account2.com”,destinationMapping:[1,2]}
>
> ]
>
> }
>
>  
>
> And would just run in the background sending pings with SNI support,
> and if based on dispatcher should make it easy enough adapt things
> like the destination up and down event routes, and would allow me to
> use Kamailio much like I would use nginx for web stuff as a reverse
> proxy and handle TLS offload on my edge gateway proxy.
>
>  
>
> Any thoughts?, im frustratingly close to having something that will do
> if I could get a new connection to be created, but I fear my use case
> might be sufficiently different from dispatchers to make a new module
> a sensible approach..
>
>  
>
> Regards
>
>  
>
> Tim.
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210106/6a94fd7e/attachment-0001.htm>


More information about the sr-users mailing list