View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000433||bareos-core||[All Projects] file daemon||public||2015-03-06 02:03||2016-01-15 10:03|
|Fixed in Version|
|Summary||0000433: Make all director-> fd communication protected via TLS|
|Description||Currently the authentication phase of the communuication between the storage deamon and the file deamon happens in clear text with cram-md5 protection. Here is a proposal to enhance all bareos communication so that TLS can start before any messages (except a startTLS) is sent.|
|Tags||No tags attached.|
Hi, I removed the first patch as that was probably a reverse patch.
Some comments on the second one, first of all thanks for doing this effort
and it looks promising. Its however doesn't fully follow the design we
discussed on the devel mailinglist. The StartTLS now starts already before
the director is known and that is probably also why you need quite some
workaround later on when you know that info.
I had a look myself and I think I see a way in which things are less intrusive
(and maybe only a little bit cleaner) when using a new Hello message e.g.
Hello Director %s calling StartTLS ssl=%d
The advantage of this is that we also directly get the director name and the
TLS the remote side support.)
I'm now implementing some ideas so if you can wait a bit I can attach my ideas
and maybe you can use that as a basis to work on.
Some small remarks about your patch, if you need a boolean that you need to
pass on to some next function or down the stack it probably works better to
use an extra variable in the JCR or the BSOCK. What I did in my initial coding
is add it to the BSOCK as a bit field (there are already more of them).
|I like your method better. I will wait for your patches (do you think we should be doing starttls for the storage-deamon-fd communication too? or should we make that a separate bug?)|
The idea is no add StartTLS support to every connection.
Attached are some design principles that implement the approach
I explained above. It might not work quite right as its only
a design example which compiles. But it has most things we probably
need and some ideas to jump over the authentication and do TLS handshake
first and then jump back in the code doing the authentication. This has
the advantage that we don't recode the features to much and jump around
a bit with goto's which are used anyway to have a single exit from function.
Also the BSOCK has some new methods and fields to support StartTLS without
adding to much overhead.
This is seriously untested code but is probably a good basis to work further
on. We need more for some connections but I think it can reuse most of the
available infrastructure this patch adds.
|2015-03-06 02:03||cviecco||New Issue|
|2015-03-19 17:53||cviecco||File Added: starttls-dir-fd-comm-fd.diff|
|2015-03-19 17:56||cviecco||File Added: starttls-dir-fd-comm-fd-v1.diff|
|2015-03-19 20:43||mvwieringen||File Deleted: starttls-dir-fd-comm-fd.diff|
|2015-03-21 17:39||mvwieringen||Note Added: 0001329|
|2015-03-21 17:39||mvwieringen||Assigned To||=> mvwieringen|
|2015-03-21 17:39||mvwieringen||Status||new => feedback|
|2015-03-21 19:07||cviecco||Note Added: 0001331|
|2015-03-21 19:07||cviecco||Status||feedback => assigned|
|2015-03-22 20:29||mvwieringen||Note Added: 0001332|
|2015-03-22 20:29||mvwieringen||File Added: 0001-First-try-at-adding-first-StartTLS-support.patch|
|2015-03-22 20:31||mvwieringen||Status||assigned => feedback|
|2016-01-15 10:02||mvwieringen||File Deleted: 0001-First-try-at-adding-first-StartTLS-support.patch|
|2016-01-15 10:02||mvwieringen||File Deleted: starttls-dir-fd-comm-fd-v1.diff|
|2016-01-15 10:03||mvwieringen||Assigned To||mvwieringen =>|
|2016-01-15 10:03||mvwieringen||Status||feedback => acknowledged|