[SR-Users] SNI Query

mahesh b mahesh.b.2487 at gmail.com
Fri Jan 3 11:24:30 CET 2020


Hi All,

Am using Kamailio 5.1.9 version.

*Below is my tls.cfg*

[server:default]
method = TLSv1+
verify_certificate = no
require_certificate = no
private_key = server.key
certificate = server.crt
ca_list = bundle.crt
cipher_list = RSA
verify_depth = 9

[client:default]
verify_certificate = no
require_certificate = no


[server:10.211.160.172:5061]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /root/mahesh_openssl/profile2/btip_172_server_private.key
certificate = /root/mahesh_openssl/profile2/btip_172_server_public.crt
ca_list = /root/mahesh_openssl/profile2/btip_ca_public.crt
cipher_list = RSA
verify_depth = 9
server_name = btip.172.com


[server:10.211.160.172:5061]
method = TLSv1+
verify_certificate = yes
require_certificate = yes
private_key = /root/mahesh_openssl/profile1/ctip_172_server_private.key
certificate = /root/mahesh_openssl/profile1/ctip_172_server_public.crt
ca_list = /root/mahesh_openssl/profile1/ctip_ca_public.crt
cipher_list = RSA
verify_depth = 9
server_name = ctip.172.com

My Kamailio server ip is 10.211.160.172

i)When i initiate a tls connection from remote server(which is also a
kamailio server) say 10.211.160.176 to 10.211.160.172
  In the client hello am setting sni name as btip.172.com => so on
10.211.160.172 side it is picking up the server profile with serve_name
btip.172.com for the tls handshake.*// Working as expected*

ii)When i initiate a tls connection from another remote server(Which is
also a kamailio server) say 10.211.160.163 to 10.211.160.172
  In the client hello am setting sni name as ctip.172.com => so on
10.211.160.172 side it is picking up the server profile with serve_name
ctip.172.com for the tls handshake.*// Working as expected*

iii)When i initiate a tls connection from another remote server(Which is
also a kamailio server) say 10.211.160.175 to 10.211.160.172
  In the client hello am NOT setting sni name  => so on 10.211.160.172 side
should it pick up the server default profile or the first profile to which
IP and port matches ?
  what i observe from logs is that it is picking up the server profile with
server_name ctip.172.com for the tls handshake.


  I had a look at the code in function tls_lookup_cfg, from the debug
prints i understand it is trying to match profile for IP and port

if ((p->port==0 || p->port == port) && ip_addr_cmp(&p->ip, ip))* // IP and
port matched*
{
      if(sname && sname->len>0)     *//Incoming Client hello dint have
sname, so it will hit the else part*
     {
                 if(p->server_name.s && p->server_name.len==sname->len
                 && strncasecmp(p->server_name.s, sname->s, sname->len)==0)
                {
                  LM_DBG("socket+server_name based TLS server domain
found\n");
                 return p;
                }
   }
   else
   {
      return p; *// so it is returning the first profile to which IP and
port matched.*
   }
}


Am i missing anything or is this a bug ? if in the clienthello there is no
sni , what needs to be done to make use of the default profile for the tls
handshake ? Or is this something fixed in latest.
I just Tried and Modified the code as below, after which it is giving the
server default profile when no sni in Incoming Client Hello.

if ((p->port==0 || p->port == port) && ip_addr_cmp(&p->ip, ip))
{
      if(sname && sname->len>0)
     {
                 if(p->server_name.s && p->server_name.len==sname->len
                 && strncasecmp(p->server_name.s, sname->s, sname->len)==0)
                {
                  LM_DBG("socket+server_name based TLS server domain
found\n");
                 return p;
                }
   }
   else
   {
              if( (type & TLS_DOMAIN_SRV) && (p->server_name.s) )
              {
                 LM_DBG("Inside %s at %d\n",__FUNCTION__,__LINE__);
                return cfg->srv_default;
             }
             else
            {
                LM_DBG("Inside %s at %d\n",__FUNCTION__,__LINE__);
               return p;
            }
    }
}

Regards,
Mahesh.B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200103/d1348c61/attachment.html>


More information about the sr-users mailing list