[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:09:19 CEST 2006
answering myself ...
On 04/04/06 18:03, Daniel-Constantin Mierla wrote:
> Hello Klaus,
>
> looks very good! Are this config options direct in core or you added
> them in the tlsops module?
looking into the patch, I see that the options were added in the core ...
>
> 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
>>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
More information about the Devel
mailing list