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

Daniel-Constantin Mierla daniel at voice-system.ro
Tue Apr 4 17:03:50 CEST 2006


Hello Klaus,

looks very good! Are this config options direct in core or you added 
them in the tlsops module?

Cheers,
Daniel


On 04/04/06 17:49, Klaus Darilion wrote:
> Hi!
>
> It would be nice if someone could review this patch - I'm still not an 
> openser expert. I did some tests and it worked fine.
>
> regards
> klaus
>
> 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&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: 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&group_id=139143 
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>



More information about the Devel mailing list