[vtls] vtls background

[Tim Ruehsen]

On Monday 09 February 2015 13:48:40 Kamil Dudka wrote:
> On Monday 09 February 2015 11:52:44 Tim Ruehsen wrote:
> > Hi Dago,
> > 
> > On Monday 09 February 2015 11:32:53 Dagobert Michelsen wrote:
> > > Hi Tim,
> > > 
> > > > Am 09.02.2015 um 11:21 schrieb Tim Ruehsen <tim.ruehsen at gmx.de>:
> > > > Just for my understanding:
> > > > 
> > > > For a (Debian ) Linux system, it could be (basically) organized like
> > > > /usr/lib/libmetassl.so -> (symlinks to)
> > > > 
> > > >  /usr/lib/libmetassl-openssl.so
> > > >  /usr/lib/libmetassl-gnutls.so
> > > >  ...
> > > > 
> > > > So an administrator could change the link (update-.alternatives ?) to
> > > > globally change the backend (of course you have to restart the
> > > > appropriate apps). ?
> > > > 
> > > > Also, to start a single app using a different backend, you would
> > > > symlink
> > > > to
> > > > whatever backend you like (e.g. /home/user/lib/libmetassl.so ->
> > > > /usr/lib/libmetassl-openssl.so) and use LD_LIBRARY_PATH to prioritize
> > > > /home/usr/lib/ over /usr/lib ?
> > > > 
> > > > It this what you have in mind ? (else please be more detailed and/or
> > > > provide an example).
> > > 
> > > This is horrible from a distromaker standpoint for a number of reasons:
> > > - LD_LIBRARY_PATH should be avoided as much as possible as it leads to
> > > all
> > > kinds of problems and needs to be done for every user
> > > - global configuration is bad for a situation where you run different
> > > applications linked against lib<whatever> and require different backend
> > > ssl
> > > libs for each app - alternatives is distro-specific and generally hard
> > > to
> > > manage. It is already bad to have that for e.g. mta but without strong
> > > necessity I would avoid it
> > > 
> > > From a distro usability standpoint I would prefer a situation where you
> > > compile lib<whatever> against a set of backend libraries. Applications
> > > linked against it can then be told to select a specific backend, but
> > > this
> > > should be done in the specific application, not globally. If the library
> > > already contains the full glue or if the specific glue is dlopened in a
> > > future version is not that much different from a deployment perspective.
> > 
> > Well it was just a question. I don't like the  LD_LIBRARY_PATH either (and
> > it is not compatible).
> > 
> > How would you handle the following (if you were an administrator):
> > 
> > Imagine I have a dozen services running, all with backend A (because that
> > is 'the best' for my purpose). Assume that not all of these services have
> > a switch to select the backend - they use the system default.
> > Now a 0-day exploit strikes me, there is no patch yet. With vtls (+ global
> > config) I just could switch to backend B and restart all services (or
> > better - reboot). Happy me !
> 
> In the enterprise world, you cannot switch the backend of libcurl without
> having it already tested for few months and fixed the bugs it introduces.
> 
> > Another question is (I just don't know): is there dlopen support on each
> > plattform that we want to support ?
> > 
> > If dlopen is not an issue, I would go with you.
> > 
> > Tim
> 
> Making libcurl dlopen() crypto libraries sounds like a really bad idea to
> me.

It's an idea, but not a 'bad' one.

> libcurl used to dlopen() the OpenLDAP library it caused problems:
> 
> https://bugzilla.redhat.com/215928#c6

The libcurl implementation was simply buggy and nobody fixed it. Besides this, 
proper ABI versioning / checksumming does prevent this pitfall. Much 'plugin' 
technology is based on dyn loading of 'libraries' (in this case 'plugins'). 
There is no magic.

BTW, my formerly suggested libmetassl.so + backend 'plugins' are tightly 
coupled, so a version A would only load version A backends. Thus a 
distribution package would hold all of these. You can't just update one plugin 
without updating the other parts. 

libldap and libcurl weren't coupled that tight and thus an ABI breakage was 
possible (and likely).

> Additionally, some crypto libraries are too sensitive to the way they are
> initialized, especially when being loaded multiple times in the application
> stack:
> 
> https://bugzilla.redhat.com/738456

Seems very clearly a typical library design flaw that already has been 
addressed and fixed. This can happen with any library that you load via 
dlopen. To address this you either need a context version of the init function 
(if this is not ineffective) and/or a lock/mutex. Again: no magic here.

> It also paralyzes automatic ELF-based dependency scanners that modern
> packaging systems tend to use.

If these scanners can't detect dynamic loading via dlopen (of course they 
can't), there need to be additional mechanisms, e.g. exception databases.
Problem solved.

> Not talking about security certifications
> that would be invalidated by allowing to switch the TLS backend on the fly.

Who certifies what in which way ? This is not an dlopen issue. E.g. apache has 
mod_ssl and mog_gnutls (with limited functionality, ok). You can stop apache, 
configure the other module and restart. Outch.
Certifications is a wide field. Some certs my be given, when you pass a 
security check from outside (via some sort of scanner). Other cert processes 
include the whole IT structure / organisation (countless points to check) and 
may or may not explicitely define even the version of all your involved 
software + configurations. Touch anything and the certification process has to 
start at 0.
Sorry, cert process in general are not an argument against usage of dlopen.

Please don't get me wrong. I don't want to say dlopen is a must.
I just want to comment your arguments for the record.
At one point in time, we should put all pros and cons together (the wiki may 
be a good place) and than find a consensus.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mayfirst.org/pipermail/vtls/attachments/20150209/a4accd72/attachment-0001.sig>