18 Nov
2005
18 Nov
'05
3:19 p.m.
Mikael Magnusson wrote:
Bogdan-Andrei Iancu wrote:
AFAIK this is possible:
http://openser.org/docs/tls.html#AEN343
But I think this is not nice solution (restart ser, firewall settings
...). It might be useful when hosting multiple domains, but only one
federation. But if you take part in several federations you would have
to publish different ingress points for each federation. That does nto
scale. E.g. if you use ENUM (e164.arpa) to publish your ingress point,
you can publish a sinlge URI for all federations.
regards
klaus
Hi Klaus,
indeed this is a long email ;).
please see my inline comments.
regards.
Bogdan
Klaus Darilion wrote:
Can't openser use different ports for each domain it's serving? This of
course requires that SRV records are configured in the DNS and that the
UAC supports SRV.
domain port certificate
atlanta.com 5061 /etc/openser/federationAcert.pem
biloxy.com 5063 /etc/openser/federationBcert.pem
chicago.com 5065 /etc/openser/federationAcert.pem Hi all!
There are several scenarios where TLS will be used to interconnect
SIP proxies. (open)ser's TLS implementation should be generic enough
to handle all the useful scenarios. Thus, to better understand the
requirements, first I present some examples where (open)ser+TLS will
be useful. (I do not propose which of the following interconnect
models are good or bad. However, openser should be capable to handle
all of them, best in a mixed mode).
Enterprise scenario:
A company uses TLS to interconnect their SIP proxies via public
Internet. The proxies import the companies selfsigned CA-cert as
trusted CAs. The proxies trust other proxies as soon as their cert is
validated using the root CA.
This is already possible using openser 1.0.0 (= or ser+experimental TLS)
Federation scenario:
Some ITSPs form a federation. The federation-CA signs the certs of
the ITSPs. Here, the validation is like in the enterprise scenario.
(open)ser validates against the federations CA-cert. This works with
openser 1.0.0 as long as the ITSP is only in one federation, or uses
different egress/ingress points for each federation. If the ITSP is
member of two federations and uses one egress/ingress proxy, it has
to decide which certificate it should present to the peer. The
originating proxy could choose the proper client certificate for
example by using a table like (or having the certificate as blob
directly in the DB):
dst_domain certificate
sip.atlanta.com /etc/openser/federationAcert.pem
sip.biloxy.com /etc/openser/federationBcert.pem
sip.chicago.com /etc/openser/federationAcert.pem
Presenting the proper server certificate, is more difficult. The
server does not know if the incoming TLS request belongs to a member
of fedA, fedB or someone else. Thus, presenting the wrong certificate
will lead to the clients rejecting the certificate due to failed
validation. One solution would be sending the "trusted_ca_keys" (TLS
extension) in Client Hello. Unfortunatelly this is not supported in
openssl (and gnutls). Any workaround for this?
As I understood from Cesc, gnutls already support this extension, but
to migrate to gnutls and restart all testing may not pay the effort as
time as it's just a matter of time until the extension will be also
available in openssl.
As temporary solution I will suggest to go by default without the
extension patch, but to provide the patch into the TLS directory and
people interested in these multi-domain scenarios will have to apply
and recompile the openssl lib. And maybe we should do some lobby (read
pressure) on the openssl mailing list in order to push this extension
in the official tree.
Just an idea.