[Users] Improving TLS implementation

[Cesc]

Hi everybody,

I create a separate thread for the whole "tls improvement, let's create a
module, lets see what to do with it" because for me it was getting a bit
messier. Too many threads all talking about the same :)

The TLS bussiness, we agree, is ugly and there is no one-fits-all solution,
so we must try to be flexible, even if it means more development.
Breaking it down, one more summary:

1) TLS transport layer authentication
Allow for various levels of verification and peer certificate requirement.
That is, request a cert from the peer or not, what to do if the certificate
provided by the peer is not signed by one of our CAs (or if there is no peer
cert at all), how the verification should be done (just check against our
trusted CAs or do some DNS resolution for the provided Subject/CN on the ip
we receive the connection from), etc.

2) Lifting the TLS authentication to the SIP layer for SIP authentication
and authorization, according to "whatever" local policy
I think here a tls_tools module is what we need. Let's think on what
functions are needed to cover most needs. Proposals up to now include
functions such as: tls_check_from/to( "SubjectName"/"CN"),
tls_is_peer_cert_present(), tls_is_peer_cert_valid(),
tls_is_peer_domain_trusted() as in white/black list, etc.

3) Incoming requests
3.1) Single domain
This does not present much of a problem. Just present whatever certificate
the proxy is serving. Use the tls_tools module to further authenticate and
authorize the requeset.
3.2) Multi-domain
This present a lot of problems, but there are solutions:
3.2.a) Use a different ip:port per domain ... good enough if the domains
served are not changing often.
3.2.b) Present the host certificate, not one per domain ... usable as a
fall-back scenario if everything else fails.
3.2.c) Use TLS Extensions, so the requesting proxy notifies the receiving
proxy of the domain it is requesting. I just found some guys (i think an
initial project from stanford, i don't know now) that implemented the TLS
Servername Extension (http://www.edelweb.fr/EdelKey/). I am still waiting
for more answers on the ssl-users mailing list, hopefully it is already
included in the core, otherwise this solution would mean having to compile
openssl locally :(

4) Outgoing requests
4.1) Single domain
Again, not much of a problem.
4.2) Multiple domain
Solution here is simpler. Provided that the domains are internally setup,
select the desired one when forwarding the request (either automatically or
via some function in tls_tools module). TLS domains can currently only be
set up statically in the config file, thus some dynamic mechanism to create
new ones has to be found (database, serctl? ).

5) Out-of-the-box setup
That is, ser should allow to work using some very simplistic TLS form just
by compiling it with TLS=1 and turning the tls_disabled=0 parameter. In this
scenario, TLS could work using anonymous ciphers (no need for certificates)
and would accept any incoming request (no verification of certs against CAs,
or come with a generic root CA, but that would be more complex). In this
mode, a huuge warning should be issued.

Let's try to focus on specifics, so we can get this working as soon as
possible.

Regards,

Cesc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20051013/3b8e71bc/attachment.htm>