TLS improvements
Camilo Viecco
I just have installed bareos and because I like to minimize
configuration I wondered how difficult it would be to add TLS-PSK
support to the director to filedaemon traffic (so that I did not had to
have certificates for all my clients). For this I started looking that
the filed code (src/filed/authenticate.c) and noticed that even in the
case of using TLS (server side) the authentication of the client (when
not using client based certificates) happens in clear text using
cram-md5. This implies that if you only use server side TLS certificates
the communication is susceptible to MITM attacks by active adversaries.
(it does protect against passive ones, assuming your password is strong
enough to prevent direct attacks on the cram-md5).
So I was wondering how willing is the list for me to explore the
possibility of a non-bacula compatible per director preference where the
TLS is done just after the the "Hello Director $XX calling" message
(before the cram-md5 challenge). By doing it there we be able to be
identify the connecting director and keep backwards compatibility with
the current TLS (or not) Transport. By doing this communications that
use TLS server side certificates will be protected against active
attackers (the director name will not be protected).
IE the change will be from the current:
Director-D File-D
Hello Director ->
<-Cram Challenge
Cram Response->
Client TLS Hello->
<--Server TLS Hello
To (option A):
Director-D File-D
Hello Director ->
Client TLS Hello ->
< Server TLS HEllo
..... (rest of handshake)
<-Cram Challenge
Cram Response->
Or To (option B):
Director-D File-D
Hello Director ->
<- *NEW* About to start TLS handshake (message)
Client TLS Hello ->
<Server TLS Hello
.... (rest of handshake)
<-Cram Challenge
Cram Response->
Notice that I am not protecting the director name using this scheme (but
code changes would not be large and assuming in genreal usernames are
not expecte to be keep secret). Another possbility (Ithink now cleaner)
would have been to create a hew hello mesage that means startTLS from
the connecting party (this is option B).
One might wonder why not start the client side connection with a
STARTTLS like message. For backwards compatiblity issues since the
current configuration directives allow each director connection to have
different trust anchors.
Any toughts or things that I a missing before I start coding this?
Thanks for your time
Camilo
Marco van Wieringen
>
> Hello List
>
> I just have installed bareos and because I like to minimize
> configuration I wondered how difficult it would be to add TLS-PSK
> support to the director to filedaemon traffic (so that I did not had to
> have certificates for all my clients). For this I started looking that
> the filed code (src/filed/authenticate.c) and noticed that even in the
> case of using TLS (server side) the authentication of the client (when
> not using client based certificates) happens in clear text using
> cram-md5. This implies that if you only use server side TLS certificates
> the communication is susceptible to MITM attacks by active adversaries.
> (it does protect against passive ones, assuming your password is strong
> enough to prevent direct attacks on the cram-md5).
Correct the original design added TLS support to start after the actual
challenge response is done. With CRAM-MD5 the password is of course never
exchanged but it might give a possible attack surface against the
authentication strings exchanged. We have made some changes over time
to allow a somewhat less strict TLS handshake etc. but this is something
we eventually wanted to tackle but until now its not come on top of the
priority list.
>
> So I was wondering how willing is the list for me to explore the
> possibility of a non-bacula compatible per director preference where the
> TLS is done just after the the "Hello Director $XX calling" message
> (before the cram-md5 challenge). By doing it there we be able to be
> identify the connecting director and keep backwards compatibility with
> the current TLS (or not) Transport. By doing this communications that
> use TLS server side certificates will be protected against active
> attackers (the director name will not be protected).
>
The compatibility to Bacula is not a wholly grail and as Bacula 7 decided
to change the authentication protocol to be incompatible anyway its also
something we don't have to care about anymore. As long as things are
configurable and the default is the old protocol I see no harm in
changing this. We already changed quite a bit to make TLS more flexible
so adding this and possibly also some extra TLS extensions are not really
a big problem.
> IE the change will be from the current:
>
> Director-D File-D
> Hello Director ->
> <-Cram Challenge
> Cram Response->
> Client TLS Hello->
> <--Server TLS Hello
>
> To (option A):
> Director-D File-D
> Hello Director ->
> Client TLS Hello ->
> < Server TLS HEllo
> ..... (rest of handshake)
> <-Cram Challenge
> Cram Response->
>
> Or To (option B):
>
> Director-D File-D
> Hello Director ->
> <- *NEW* About to start TLS handshake (message)
> Client TLS Hello ->
> <Server TLS Hello
> .... (rest of handshake)
> <-Cram Challenge
> Cram Response->
>
I think option B makes more sense as that makes it possible
to detect the new behavior in the FD instead of hard coding
the new behavior using a config option.
> Notice that I am not protecting the director name using this scheme (but
> code changes would not be large and assuming in genreal usernames are
> not expecte to be keep secret). Another possbility (Ithink now cleaner)
> would have been to create a hew hello mesage that means startTLS from
> the connecting party (this is option B).
>
That is also a possibility we are adding extra Hello formats anyway
in the FD to DIR communication for client initiated backups in the future.
I would only not look strictly at the DIR to FD connection but possibly
also to the console to DIR connectivity etc. It might make sense to allow
this additional TLS first config for other communication channels. If we
start adding things like PAM authentication to the DIR for consoles we
would like TLS to start as early as possible so you can send passwords
also over the TLS connection as that is needed for PAM. B.T.W. changing
the Hello message from DIR to FD does need a config option in the client
as you want to talk the old protocol to the older FDs that is one of the
reasons it now exchanges an FD protocol number so the DIR knows to what
FD version its talking.
> One might wonder why not start the client side connection with a
> STARTTLS like message. For backwards compatiblity issues since the
> current configuration directives allow each director connection to have
> different trust anchors.
I guess you are talking about setting a config option in the DIR section
of the FD configuration right ? Problem with such a change is that you have
to do it in a lot of configs while doing configs in the client config on
the DIR at least has it in one place.
>
> Any toughts or things that I a missing before I start coding this?
Other then that is only part of where you probably want to change
it not really. You might run into some surprises as not everything
is always as clear but at least you have the clear advantage that the
code is already clearly separated and refactored over time so changing
behavior should be doable in its current form.
--
Marco van Wieringen marco.van...@bareos.com
Bareos GmbH & Co. KG Phone: +49-221-63069389
http://www.bareos.com
Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
P. Storz, M. v. Wieringen
Camilo Viecco
Will have more news when actual code is built
Camilo