[Devel] [ openser-Patches-1464264 ] support for TLS client domains (name based and socket based)

Wed Apr 26 20:27:33 CEST 2006

Patches item #1464264, was opened at 2006-04-04 16:47
Message generated for change (Comment added) made by klaus_darilion
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1464264&group_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: Closed
>Resolution: Out of Date
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;
...

_________________________________________________________

----------------------------------------------------------------------

>Comment By: Klaus Darilion (klaus_darilion)
Date: 2006-04-26 20:27

Message:
Logged In: YES 
user_id=1318360

a new patch is on the way ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1464264&group_id=139143