View Issue Details

IDProjectCategoryView StatusLast Update
0000433bareos-corefile daemonpublic2023-05-09 16:56
Reportercviecco Assigned Tobruno-at-bareos  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSUbuntuOS Version14.04
Product Version14.2.3 
Summary0000433: Make all director-> fd communication protected via TLS
DescriptionCurrently 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.
TagsNo tags attached.

Activities

mvwieringen

mvwieringen

2015-03-21 17:39

developer   ~0001329

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).
cviecco

cviecco

2015-03-21 19:07

reporter   ~0001331

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?)
mvwieringen

mvwieringen

2015-03-22 20:29

developer   ~0001332

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.
bruno-at-bareos

bruno-at-bareos

2023-05-09 16:56

manager   ~0005030

New version have TLSPSK

Issue History

Date Modified Username Field Change
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
2023-05-09 16:56 bruno-at-bareos Assigned To => bruno-at-bareos
2023-05-09 16:56 bruno-at-bareos Status acknowledged => closed
2023-05-09 16:56 bruno-at-bareos Resolution open => fixed
2023-05-09 16:56 bruno-at-bareos Note Added: 0005030