Re: bacula and TLS

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 10/10/14 4:47 PM, Fredrik Pettai wrote:
> On Oct 9, 2014, at 18:38 , J. Lewis Muir <jlmuir%imca-cat.org@localhost> wrote:
>> On 10/9/14 11:14 AM, Havard Eidnes wrote:
>>> Is there a particular reason SSL encryption isn't turned on by
>>> default where it can?
>
>> Another reason might be that it increases the dependencies for the
>> package.
>
> Generally, OpenSSL is included in base on most OSes.

Hi, Fredrik.

Well, it's still a dependency.  But in general I agree with you; adding
a dependency on OpenSSL when it's probably already part of the base OS
is not much of a burden.

>> Another reason might be to avoid linking with OpenSSL since it has
>> had a difficult security track record, and linking against it could
>> be seen as a security liability.
>
> I find this argumentation a bit weird?
>
> It sounds like are you arguing that using no encryption whatsoever
> "might" be safer for the user, because the way encryption is provided
> is thru using a library that has had some serious vulnerabilities
> (which btw. because of that, already got more traction and both more
> funding and resources to shape up the project [1])
>
> Even other "high profile" security software like OpenSSH doesn't have
> a close-to-zero security track record [2] (well, nothing in there as
> bad as the "heartbleed" bug), but I would never suggest or argue that
> could be safer to go back to non encrypted Telnet just because there
> has been 30+ security issues in OpenSSH.

Keep in mind that these aren't necessarily my reasons; I was just trying
to give some reasons that I thought might be there for some people.  It
could be that no one thinks this, in which case I'm wasting everyone's
time, and for that I would be truly sorry.

I thought the OpenSSL code was considered overly complex and difficult
to read, and it has the custom memory allocator which can make some
analysis tools unable to catch certain classes of problems.  I haven't
looked at the source code, so I'm not saying this; I'm just saying what
I've heard.  I was unaware of major security holes in OpenSSH.  If
there have been such holes, then it certainly weakens the argument for
avoiding linking against OpenSSL.

I was not suggesting "no encryption" over "encryption with increased
risk of a security vulnerability" (e.g. going back to Telnet instead
of SSH because OpenSSH has had lots of security vulnerabilities).
Certainly, if the encryption is needed, then include it.

For the case where the encryption is needed, I thought there could be
a benefit to avoiding linking against OpenSSL.  I thought the idea was
that using something like stunnel could be safer since, if the stunnel
process was compromised through an OpenSSL security vulnerability, the
program tunneling through it would still be uncompromised.  But I just
did a quick Web search and didn't find anything supporting this, so
maybe I'm totally wrong.  If I am wrong, I'm sorry for suggesting this.
If anyone has insight into this, I'd be very interested in hearing.  But
please be nice to me. :-)

Regards,

Lewis