[Pkg-telepathy-maintainers] Bug#699103: Empathy fails to connect to SIP proxy over TLS

[Ron]

On Wed, Jan 29, 2014 at 10:59:21AM +0000, Simon McVittie wrote:
> reassign 699103 telepathy-rakia 0.7.4-1
> tags 699103 + upstream
> thanks
> 
> On 28/01/14 20:06, Ron wrote:
> > Yes, I think I'm a bit leery about unilaterally (and otherwise silently)
> > changing the trust path of all applications using this lib.
> 
> Fair enough, taking this bug back. It's going to have to be an upstream
> feature request, in that case.

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.


> > 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).
> 
> /**@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?

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.

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

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?


> smcv wrote:
> >> 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.
> 
> 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?

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