Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix TLS client config selection based on dst ip and port #842

Closed
wants to merge 2 commits into from

Conversation

sergey-vb
Copy link
Contributor

Hi All.

After some try to configure kamailio 4.4.3 to act as SPI TLS client for Cisco SIP TLS gateways I have found one issue.

If I do client configuration for tls

[client:10.1.23.19:5061]
verify_certificate = yes
ca_list = /etc/kamailio/CAs/ca1.pem

[client:10.1.23.29:5061]
verify_certificate = yes
ca_list = /etc/kamailio/CAs/ca2.pem

[client:default]
verify_certificate = no
require_certificate = no

Kamailo always do default profile selection (I do configuration without server_name or server_id, with it kamailio works fine but there are some troubles to make selection of this parameters from
config script, I need additional checks and queries)

after some research in tls module source code I have added some debug information in file tls_server.c:

 	if (c->flags & F_CONN_PASSIVE) {
 		state=S_TLS_ACCEPTING;
 		dom = tls_lookup_cfg(cfg, TLS_DOMAIN_SRV,
 								&c->rcv.dst_ip, c->rcv.dst_port, 0, 0);
 	} else {
 		state=S_TLS_CONNECTING;
 		sname = tls_get_connect_server_name();
 		srvid = tls_get_connect_server_id();
// -------------------------------------------------------------
                DBG("Entered client config loockup (c->rcv.dst_port %d)\n", c->rcv.dst_port);
                DBG("Entered client config loockup (&c->rcv.dst_ip %s)\n", ip_addr2a(&c->rcv.dst_ip));
                DBG("Entered client config loockup (c->rcv.src_port %d)\n", c->rcv.src_port);
                DBG("Entered client config loockup (&c->rcv.src_ip %s)\n", ip_addr2a(&c->rcv.src_ip));
// -------------------------------------------------------------
 		dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI,
						&c->rcv.dst_ip, c->rcv.dst_port, sname, srvid);
	}

After making a test call:
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [parser/msg_parser.c:597]: parse_msg(): method:
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [parser/msg_parser.c:599]: parse_msg(): uri: sip:9098@10.1.23.19:5061;transport=TLS
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [parser/msg_parser.c:601]: parse_msg(): version: <SIP/2.0>

I see:

Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 10.1.23.19
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [tcp_main.c:985]: tcpconn_new(): on port 5061, type 3
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: [tcp_main.c:1295]: tcpconn_add(): hashes: 1394:0:0, 1
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:160]: tls_get_connect_server_name(): xavp with outbound server name not found
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:140]: tls_get_connect_server_id(): xavp with outbound server id not found
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:219]: tls_complete_init(): Entered client config loockup (c->rcv.dst_port 40123)
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:220]: tls_complete_init(): Entered client config loockup (&c->rcv.dst_ip 10.1.23.23)
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:221]: tls_complete_init(): Entered client config loockup (c->rcv.src_port 5061)
Oct 26 09:23:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:222]: tls_complete_init(): Entered client config loockup (&c->rcv.src_ip 10.1.23.19)

Where:
&c->rcv.dst_ip 10.1.23.23 - it is my local kamailio tls socket ip address to make tls connect from
c->rcv.dst_port 40123 - it is my local kamailio tls socket port
&c->rcv.src_ip 10.1.23.19 - ip of my TLS device to make tls connection to
c->rcv.src_port 5061 - port of my TLS device to make tls connection to

so if I change line

 		dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI,
						&c->rcv.dst_ip, c->rcv.dst_port, sname, srvid);
to
   	dom = tls_lookup_cfg(cfg, TLS_DOMAIN_CLI,
   					&c->rcv.src_ip, c->rcv.src_port, sname, srvid);

I got correct client domain selection from tls.cfg:

Oct 26 09:33:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_server.c:233]: tls_complete_init(): Using initial TLS domain TLSc<10.1.23.19:5061> (dom 0x7fd2eefa3d68 ctx 0x7fd2ef7e70a8 sn [])
Oct 26 09:33:56 sip1 /usr/sbin/kamailio[20712]: DEBUG: tls [tls_domain.c:703]: sr_ssl_ctx_info_callback(): SSL handshake started

@miconda
Copy link
Member

miconda commented Nov 2, 2016

The [client...] section in the tls config is meant to specify the attributes when kamailio opens a connection from that socket (kamailio acts as the client from the point of view of tls connection). It is supposed to be local ip:port, not remoteip:port.

I understand that you are looking at having a section to match on remote IP, am I right?

@sergey-vb
Copy link
Contributor Author

sergey-vb commented Nov 2, 2016

As i understand from

https://github.com/kamailio/kamailio/blob/master/modules/tls/tls.cfg

# Special settings for the iptel.org public SIP
# server. We do not verify the certificate of the
# server because it can be expired. The server
# implements authentication using SSL client
# certificates so configure the client certificate
# that was given to use by iptel.org staff here.
#
#[client:195.37.77.101:5061]
#verify_certificate = no
#certificate = ./modules/tls/iptel_client.pem
#private_key = ./modules/tls/iptel_key.pem
#ca_list = ./modules/tls/iptel_ca.pem
#crl = ./modules/tls/iptel_crl.pem

this is for match with remote ip and port when kamailio acts as client.

@miconda
Copy link
Member

miconda commented Nov 2, 2016

The client in this case is kamailio, so it's its certificate. Kamailio is not supposed to have access to private key of the remote end point. iptel.org is the portal that was used for SIP Express Router (SER), previous name of kamailio project.

@sergey-vb
Copy link
Contributor Author

sorry for incorrect formating.
i have made comment using mobile version

@sergey-vb
Copy link
Contributor Author

In my case kamailio acts as client to cisco sip tls gateway to make outgoing calls.

and private_key is not remote server private key it is client private key to make client authorization on remote server.
Without this cisco close tls connection.

@miconda
Copy link
Member

miconda commented Nov 2, 2016

The patch is breaking the expected behaviour so far. I see benefits on matching based on remote address, but existing one has to be preserved as well.

One solution would be to add a new attribute in the section to specify the address to match, like:

match=local
# or
match=remote

This can also be added for the server sections.

@sergey-vb
Copy link
Contributor Author

It is interesting but not easy solution.

Because tls_lookup_cfg accepting only one ip and port...

Another solution can be in [MANAGE_BRANCH] route add next check condition:

if ($rP == "TLS") {
     $xavp(tls=>server_name) = $rd + ":" + $rp;
     $xavp(tls=>server_id) = $rd + ":" + $rp;
}

and in tls.cfg:

[client:10.1.23.19:5061]
verify_certificate = yes
ca_list = /etc/kamailio/CAs/ca1.pem
private_key = /etc/kamailio/CAs/client1.key
server_name = 10.1.23.19:5061
server_id = 10.1.23.19:5061

It works too.

After location check i have ruri like 9098@10.1.23.19:5061;transport=TLS

May bee this is the simplest solution...

@miconda
Copy link
Member

miconda commented Nov 3, 2016

The prototype of tls_lookup_cfg() can be changed if needed, that's not a problem.

The solution with xavp is ok and available now, the one with new match attribute may be an alternative the config simpler.

Anyhow, I am closing this one, given there is a solution. If anyone considers to implement the match config option, then a new pr should be opened.

@miconda miconda closed this Nov 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants