<div dir="ltr">Hi Bogdan,<div><br></div><div>Yes, of course this is real scenario. MS Teams integration. They authenticate everything by TLS certificates used by connection. It works fine for 1 integration. </div><div>But if I send SIP with domain2 to the TLS connection encrypted with certificate for domain1, I just fail.</div><div>And actually everybody I checked reusing TLS sessions almost the same way as TCP. So OpenSIPS will be the first doing this correct way.</div><div>And I like comments from tls_mgm.c</div><div><div><span style="font-family:Consolas,"Courier New",monospace;font-size:14px;white-space:pre"><font color="#000000">/* what if we have multiple connections to the same remote socket? e.g. we can have</font></span></div><div style="font-family:Consolas,"Courier New",monospace;font-size:14px;line-height:19px;white-space:pre"><div style=""><font color="#000000">  connection 1: localIP1:localPort1 <--> remoteIP:remotePort</font></div><div style=""><font color="#000000">  connection 2: localIP2:localPort2 <--> remoteIP:remotePort</font></div><div style=""><font color="#000000">but I think the is very unrealistic */</font></div><font color="#000000">
</font></div></div><div>So I got exactly this scenario.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чт, 28 мар. 2019 г. в 13:47, Bogdan-Andrei Iancu <<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alexey,<br>
<br>
It make sense (logically speaking) to get the TLS domain involved in the <br>
TCP conn re-usage alg - but my question is: have you came across a real <br>
scenario with such a need ?<br>
<br>
Regards,<br>
<br>
Bogdan-Andrei Iancu<br>
<br>
OpenSIPS Founder and Developer<br>
   <a href="https://www.opensips-solutions.com" rel="noreferrer" target="_blank">https://www.opensips-solutions.com</a><br>
OpenSIPS Summit 2019<br>
   <a href="https://www.opensips.org/events/Summit-2019Amsterdam/" rel="noreferrer" target="_blank">https://www.opensips.org/events/Summit-2019Amsterdam/</a><br>
<br>
On 03/26/2019 02:23 PM, vasilevalex wrote:<br>
> Hi Bogdan,<br>
><br>
> Thanks for fix!<br>
><br>
> What do you think about reusing TLS connections? In master branch this<br>
> behavior still the same. OpenSIPS reuses TLS connections the same way as<br>
> regular TCP connections, but it should not. For reusing TCP connection we<br>
> check, if connection with the same dst IP:PORT exists. But for TLS it is not<br>
> enough. We additionally should check, what certificate uses this connection<br>
> (or what domain it is related).<br>
><br>
> And in documentation for tls_mgm module everywhere written: Note: If there<br>
> is already an existing TLS connection to the remote target, it will be<br>
> reused and setting this AVP has no effect.<br>
><br>
> This is the same case - we have only 1 destination target, but we should use<br>
> several TLS connections to this target with different TLS certificates. So<br>
> first connection will be successful, but SIP message for second domain which<br>
> should use another certificate will try to reuse this first connection, as<br>
> target is the same. And this message will fail.<br>
><br>
><br>
><br>
> -----<br>
> ---<br>
> Alexey Vasilyev<br>
> --<br>
> Sent from: <a href="http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html" rel="noreferrer" target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html</a><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Best regards<br>Alexey Vasilyev</div>