[Devel] [ openser-Patches-1464264 ] support for TLS client domains
(name based and socket based)
Klaus Darilion
klaus.mailinglists at pernau.at
Thu Apr 6 12:24:04 CEST 2006
Hi Dan!
I agree with you - the only reason why I added it into openser.cfg was
that it was the easiest way for a "prototype" implementation.
nevertheless some comments below.
Dan Pascu wrote:
> It would be a good idea to store these peer settings in a table in a
> database (like with the SIP domains) so they can be easily added at
> runtime without a need to change the configuration file and restart
> openser.
Storing the config in the database is one thing. The other thing is
about the SSL context. Currently, the contexts are generated at startup
and when a new TLS connection is needed, the existing SSL contexts are
used. When adding new TLS domains in runtime during a database table,
there are two options (like in the domain module):
- Caching: which needs a reload command like the domain module. In this
case the SSL contexts can be generated in advance durign reload
- Non-caching: In this case, the SSL contexts are generated when the TLS
connection is needed. I do not know if generating the SSL contexts takes
lot of time and may influence performance. Has someone more knowledge
about this?
> An alternative would be to have these settings in an additional
> file that is checked for changes from time to time and reloaded if
> changed on disk.
Is is the status in ser's TLS implementation. Jan has written a parser
(which in the moment is a little bit buggy) for an external
configuration file. Does someone of you knows existing frameworks for
configuration files? I do not want to write the whole parser - I guess
there will existing frameworks (like for .ini files in Windows).
> A 3rd alternative would be to have openser have a reload fifo/socket
> command to be able to reload the configuration at runtime without
> restarting. This would be a generic solution to such changes that need to
> be done to the configuration.
If either the config is stored in a DB with caching, external file or in
openser.cfg, reloading is not a trivial task. You still would have to
keep old SSL contexts for currently open TLS connections. There may also
be race conditions between reloading and concurrently created TLs
connections.
The thread http://mail.iptel.org/pipermail/serdev/2006-March/006893.html
will discuss such things.
IMO it would be great if all the configuration can be changed on runtime
and reloading of TLS configuration works. It would also be nice to tear
down a certain (or all) existing TLS/TCP connections (when changing
certificates or removing TLS domains).
But at the moment I can live with my patch.
btw: there is one problem when different client TLS domains try to
connect to the same peer. e.g.:
TLS client domain 1 ---------TLS--------> ip1:port1
TLS client domain 2 ---------TLS--------> ip1:port1
In this case the TCP part detects that there is an existing connection
and reuses the TLS connection from the first TLS client domain.
regards
klaus
>
> On Tuesday 04 April 2006 17:47, SourceForge.net wrote:
>> Patches item #1464264, was opened at 2006-04-04 16:47
>> Message generated for change (Tracker Item Submitted) made by Item
>> Submitter You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1464264&gr
>> oup_id=139143
>>
>> Please note that this message will contain a full copy of the comment
>> thread, including the initial issue submission, for this request,
>> not just the latest update.
>> Category: core
>> Group: ver devel
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Submitted By: Klaus Darilion (klaus_darilion)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: support for TLS client domains (name based and socket based)
>>
>> Initial Comment:
>>
>> _________________________________________________________
>>
>> 1.6.12. tls_client_domain_avp=number
>>
>> This sets the interger AVP used for name based TLS
>> server
>> domains (please see tls_client_domain for more details).
>> Setting the value to 0 disables name based TLS
>> client domains.
>>
>> It's usable only if TLS support was compiled.
>>
>> Default value is 0.
>>
>> Example 1-12. Set tls_client_domain_avp variable
>> ...
>> tls_client_domain_avp=400 # only integer named AVPs
>> are supported
>> ...
>>
>> _________________________________________________________
>>
>> If you only run one domain, the main one is enough.
>> If you are
>> running several TLS servers (that is, you have more
>> than one
>> listen=tls:ip:port entry in the config file), you
>> can specify
>> some parameters for each of them separately (not all the
>> above).
>>
>> The wording 'TLS domain' means that this TLS
>> connection will
>> have different parameters than another TLS
>> connection (from
>> another TLS domain). Thus, TLS domains must are not
>> directly
>> related to different SIP domains, although they are
>> often used
>> in common. Depending on the direction of the TLS
>> handshake, a
>> TLS domain is called 'client domain' (=outgouing TLS
>> connection) or 'server domain' (= incoming TLS
>> connection).
>>
>> For example, TLS domains can be used in virtual hosting
>> scenarios with TLS. OpenSER offers SIP service for
>> multiple
>> domains, e.g. atlanta.com and biloxi.com. Altough
>> both domains
>> will be hosted a single SIP proxy, the SIP proxy needs 2
>> certificates: One for atlanta.com and one for
>> biloxi.com. For
>> incoming TLS connections, the SIP proxy has to
>> present the
>> respective certificate during the TLS handshake. As
>> the SIP
>> proxy does not have received a SIP message yet (this
>> is done
>> after the TLS handshake), the SIP proxy can not
>> retrieve the
>> target domain (which will be usually retrieved from
>> the domain
>> in the request URI). Thus, distinction for these
>> domains must
>> be done by using multiple sockets. The socket on
>> which the TLS
>> connection is received, identifies the respective
>> domain. Thus
>> the SIP proxy is able to present the proper certificate.
>>
>> For outgoing TLS connections, the SIP proxy usually
>> has to
>> provide a client certificate. In this scenario,
>> socket based
>> distinction is not possible as there is no dedicated
>> outgoing
>> socket. Thus, the certificate selection (selection
>> of the
>> proper TLS client domain) will be name based. For this
>> purpose, TLS client domains can be associated with a
>> name
>> (e.g. the domain can be used as name). If the SIP proxy
>> establishes a new outgoing TLS connection, it checks
>> for the
>> TLS client domain AVP (parameter
>> tls_client_domain_avp). If
>> this AVP is set (e.g. in OpenSER.cfg), OpenSER
>> searches for a
>> TLS client domain with the same name and uses the
>> certificates
>> defined in the respective tls_client_domain section.
>>
>> TLS client domains can also be socket based. If name
>> based
>> domains are disabled or no name based AVP is found,
>> OpenSER
>> searches for socket based TLS client domains. In
>> this case the
>> mapping between to the TLS client domain is done
>> based on the
>> destination socket of the underlying outgoing TCP
>> connection.
>>
>> Note: If there is already an existing TLS connection
>> to the
>> remote target, it will be reused wether the TLS
>> client domain
>> AVP matches or not.
>>
>> ...
>> listen=tls:IP_2:port2
>> listen=tls:IP_3:port4
>> ...
>> # set the TLS client domain AVP
>> tls_client_domain_avp = 400
>> ...
>> # socket based TLS server domains (for virtual SIPS
>> hosting)
>> tls_server_domain[IP_2:port2] {
>> #specify parameters for a domain in particular,
>> otherwise,
>> #it will use the default. These are the possible
>> parameters to
>> #change for each domain
>> tls_certificate = "/certs/atlanta.com/cert.pem"
>> tls_private_key = "/certs/atlanta.com/privkey.pem"
>> tls_ca_list = "/certs/wellknownCAs"
>> tls_method=tlsv1
>> }
>> tls_server_domain[IP_3:port3] {
>> tls_certificate = "/certs/biloxy.com/cert.pem"
>> tls_private_key = "/certs/biloxy.com/privkey.pem"
>> tls_ca_list = "/certs/wellknownCAs"
>> tls_method=tlsv1
>> }
>> # name based TLS client domains (for virtual SIPS hosting)
>> tls_client_domain["atlanta.com"] {
>> tls_certificate = "/certs/atlanta.com/cert.pem"
>> tls_private_key = "/certs/atlanta.com/privkey.pem"
>> tls_ca_list = "/certs/wellknownCAs"
>> tls_method=tlsv1
>> }
>> tls_client_domain["biloxi.com"] {
>> tls_certificate = "/certs/biloxy.com/cert.pem"
>> tls_private_key = "/certs/biloxy.com/privkey.pem"
>> tls_ca_list = "/certs/wellknownCAs"
>> tls_method=tlsv1
>> }
>> # socket based TLS server domains (for TLS based
>> downstream from GW pro
>> vider)
>> tls_client_domain[IP_5:port5] {
>> tls_certificate = "/certs/local/cert.pem"
>> tls_private_key = "/certs/local/privkey.pem"
>> tls_ca_list = "/certs/GWproviderSelfSignedCA"
>> tls_method=tlsv1
>> }
>> # socket based TLS client domains (for TLS based
>> upstream to GW provide
>> r)
>> # GW IP: 1.2.3.4, GW port: 6677
>> tls_client_domain[1.2.3.4:6677] {
>> tls_certificate = "/certs/local/cert.pem"
>> tls_private_key = "/certs/local/privkey.pem"
>> tls_ca_list = "/certs/GWproviderSelfSignedCA"
>> tls_method=tlsv1
>> }
>> ...
>> route{
>> ...
>> # calls to other SIP domains
>> # set the proper SSL context (certificate) for
>> local hosted domains
>> avp_write("$fd","$avp(i:400)");
>> t_relay(); # uses NAPTR and SRV lookups
>> exit;
>> ...
>> # calls to the PSTN GW
>> t_relay("tls:1.2.3.4:6677");
>> exit;
>> ...
>>
>> _________________________________________________________
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1464264&gr
>> oup_id=139143
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>
More information about the Devel
mailing list