I've marked this serious because (a) there is no detailed error from
Empathy and (b) the SIP proxy is using a cert signed by a root in the
Debian distribution, so it should be trusted and work seamlessly.  Two
other SIP softphones (Lumicall and Jitsi) are working fine in the same
network with this TLS server.

I configured Empathy to use TLS to connect to a SIP account on a proxy
running repro

The repro proxy is on the same subnet, running v1.8.5 from wheezy.  It
has a server cert signed by the CACert.org class 3 root, expiring 2014,
4096 bit

Empathy fails to connect

Running repro in debug mode with console output, I notice this error:

 ssl/TlsConnection.cxx:161 | TLS connected
 ssl/TlsConnection.cxx:175 | TLS handshake want read
 Connection.cxx:372 | Exception on socket 31 code: 32; closing connection

In Empathy, I click the setting to ignore TLS errors, and then the
connection succeeds

Note: the repro proxy has both the server cert and the CAcert.org class
3 intermediate cert in the pem file, so the client should be able to
work the trust chain up to /etc/ssl/certs/cacert.org.pem  (CAcert.org
class 1 root)

Control: severity -1 important
Yeah, no.

Cheers,
Julien

I should have also mentioned that Empathy is the default VoIP client
being deployed on a Debian desktop, that fact also contributes to my
feeling that this type of thing is over the threshold for being fixed
in wheezy

created ~/.sip and symlinked ~/.sip/auth to /etc/ssl/certs.  In a test
set of "once", it worked without selecting "ignore TLS errors".

It looks like that path comes from sofia-sip.
http://anonscm.debian.org/gitweb/?p=users/ron/sofia-sip.git;a=blob;f=libsofia-sip-ua/tport/tport_type_tls.c

Would it be wrong to change sofia-sip, in debian at least, to use the
system-ca-certificates?  I do not know where to post this information on
a wiki, for visibility for others with this issue.

Derek

clone 699103 -1
severity -1 wishlist
retitle -1 interactive TLS certificate validation
tags -1 + upstream
retitle 699103 please use Debian ca-certificates as trust anchors by default
reassign 699103 libsofia-sip-ua0 1.12.11+20110422.1-2
affects 699103 telepathy-rakia
thanks

I think that sounds like a reasonable course of action, yes.
Reassigning to sofia-sip.

If the maintainer of sofia-sip has some reason not to do that (please
reassign back if so), it might also be possible for telepathy-rakia to
set up a transient directory equivalent to ~/.sip that would do the same
thing, and push in the CAfile/CApath that way.

The ideal solution would be if telepathy-rakia could additionally use
the Telepathy ServerTLSAuthentication interface to tell UIs "this
certificate looks wrong, please deal with it" - that's what
telepathy-gabble does. This delegates handling to either Empathy or
kde-telepathy-auth-handler, which can use both system-wide configuration and
user- and desktop-specific "cert pinning" (in gnome-keyring and KWallet),
and/or prompt the user. However, I don't know whether sofia-sip has
UI for that.

I don't know SIP or sofia-sip as well as I'd like, and Telepathy's SIP experts
(the primary authors of telepathy-rakia) are no longer active in the project,
so we'd appreciate any upstream help that the VoIP team can provide.
I think this is a job for "upstream first" rather than Debian-specific
patches, though.

    S

Hi,

Yes, I think I'm a bit leery about unilaterally (and otherwise silently)
changing the trust path of all applications using this lib.

Though to be honest, I'm also a bit disturbed that this fallback to a
path under $HOME exists at all really.  If anything, I'd be inclined to
completely remove that, though that decision would also need more thought
and consultation with other users than I've given it so far.

I really think this should be something that individual applications set
explicitly for themselves - though having them use the system cert dir
by default may or may not be a reasonable choice for particular apps.

I'm not all that familiar with telepathy-rakia, but most apps should
probably be setting this explicitly with NUTAG_CERTIFICATE_DIR or
similar (depending on which interface set they are using).

If they do that, then the fallback to ~/.sip/auth should never be
used at all.  How they do that, and how they let users change it
if they wish to, is again probably best as a per-app thing (unless
the app is part of some suite that shares that sort of config).

Does setting the cert dir with that tag seem like it would be a problem
for Telepathy?  I'm certainly willing to consider other ideas and input,
but this is my first impression based on what I know so far.

  Cheers,
  Ron

reassign 699103 telepathy-rakia 0.7.4-1
tags 699103 + upstream
thanks

Fair enough, taking this bug back. It's going to have to be an upstream
feature request, in that case.

/**@def NUTAG_CERTIFICATE_DIR(x)
 *
 * X.500 certificate directory
...
 * @par Values
 *    NULL terminated pathname of directory containing agent.pem and
   cafile.pem files.

So rakia will have to create a directory $certdir (either global or
per-account), symlink /etc/ssl/certs/ca-certificates.crt ->
$certdir/cafile.pem, and pass NUTAG_CERTIFICATE_DIR($certdir) to
nua_create(). Is that correct?

This seems more complicated than it needs to be, but entirely feasible.

smcv wrote:

Does sofia-sip have any functionality for this? It would probably be an
API intended for browser-style interactive prompting; in Telepathy we
proxy that over D-Bus, so the application checking the cert is not
necessarily actually interacting with the user, but we have the same
requirements as user-interaction in terms of "must be asynchronous". I
suspect it doesn't have this API, though?

    S

Feel free to keep me in the cc for any discussion.  I'm not disinterested
in this, just far less certain that there is One True Answer that is
correct for all applications using the lib.  Who you trust to serve you
web pages may not be the same as who you trust to secure your comms.
And likewise who you trust may not be the same for all comms applications.

So it really seems like a per-app thing.  Having a fallback that should
be empty by default seems like a lesser wrong - but having it shared by
all apps still seems kind of wrong unless the user said they explicitly
wanted that for them.

Or you could just pass it the system dir directly if that's what you
want, but yeah, that's how I understand this should work (and how I
do it in my code).

The hardcoding of 'cafile.pem' and 'agent.pem' as the files it looks
for is an unfortunate limitation that I certainly wouldn't be sorry
to see fixed.  But only needing to pass a dir is one form of keeping
it 'simple' I guess.

I'm not sure what you see as complicated there?  I assume rakia already
has a mechanism for other user selectable configuration passed to this,
it just needs a cert_dir option, which may or may not have a default if
the user doesn't set it - whichever you decide is best.

The user certainly should be able to override this if they want to.

Or do you just mean having to futz around with creating the needed dir
and file structure?

If it does, then I'm not aware of it either, yeah.  You can set
TPTAG_TLS_VERIFY_POLICY to specify the automatic response to various
TLS failure modes, but there's no hook for an external or interactive
controller for that.

To add one, you'd probably want to look in tls_verify_cb in tport_tls.c
(which is the openssl verification callback).  Though I'm not certain
offhand exactly what that will block if it has to wait for user input
before knowing exactly how to proceed.  Hopefully it _should_ just be
that one socket connection thread.

So this should be doable.  But not without a new API hook for it.
Unless I'm missing something obvious.


  Cheers,
  Ron

I tried doing the simplest thing that could possibly work -
NUTAG_CERTIFICATE_DIR("/etc/ssl/certs") - and it seems it doesn't
work unless your own private keypair is in that directory, which in
my case it isn't, because I don't have a keypair at all:

** (telepathy-rakia:18329): DEBUG: tls_init_context: private key does not match the certificate public key
** (telepathy-rakia:18329): DEBUG: tls_init_context: invalid local certificate: /etc/ssl/certs/agent.pem
** (telepathy-rakia:18329): DEBUG: tls_init_context: 140a80b1:SSL routines:SSL_CTX_check_private_key:no certificate assigned
** (telepathy-rakia:18329): DEBUG: tls_init_context: 02001002:system library:fopen:No such file or directory
** (telepathy-rakia:18329): DEBUG: tls_init_context: 20074002:BIO routines:FILE_CTRL:system lib
** (telepathy-rakia:18329): DEBUG: tls_init_context: 140ad002:SSL routines:SSL_CTX_use_certificate_file:system lib
** (telepathy-rakia:18329): DEBUG: tls_init_context: invalid private key: /etc/ssl/certs/agent.pem

Is there a way to tell sofia-sip to use a given set of trust anchors
to validate the server's certificate, without making it try to do
client-certificate authentication?

If not, sorry, this is back to "patches welcome" status; I've already
spent longer on this than I can really justify.

Regards,
    S