Backup Central

Attachments: PGP.sig

Sorry for the late arrival. An opendarwin.org e-mail hiccup ate my
subscription.

Kern Sibbald wrote:

Well, I care, and I don't trust DNS at all. From what I read here,
IMO the current implementation is nothing like I imagined -- it is
not the state of the art in security. With ssh, I generate a public/
private key pair and I am sure that no one that does not have the
private key can enter. This is the *minimum* that I expected for
the TLS implementation.

I hope this is just a misunderstanding on my part.

The TLS implementation does not, under any circumstances, rely on the
security of DNS. It is implemented using standard internet best
practices:
- The remote host must present a certificate that is signed by a
**trusted** certificate authority
- The certificate must match the hostname we requested. (eg, Address
= fqdn.example.org)
- The certificate must not have expired.
- The certificate must contain the correct role (ie, server, or
client).

This is the standard x509 model, used to secure all SSL sites --
including my bank. I was very careful to adhere to best practices
while implementing the TLS support -- we use it to backup highly
sensitive billing data.

Jorj Bauer wrote:

All that TLS/SSL does is verify that the certificate is signed
properly.
Bacula is then validating the contents of the certificate based on CN.

So if you use your own custom CA, then only certificates which you
signed will be verified. But if you use a public CA, and have the
certificate cut by another authority, then you have to trust that no
public authority (which is listed in your CA directory or CA
bundle) has
issued a certificate with the same embedded CN information.

If you do not trust the CAs listed in your CA bundle to correctly
issue certificates, then you can't trust "www.hsbc.com" to be HSBC
Bank, either.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party. If a CA
issues a duplicate certificate for a given CN to an unverified,
untrusted party, then that CA has failed in their primary task. That
is to say, your failure case is analogous to providing the private
key to an attacker -- of course security fails.

-landonf

Attachments: Message as HTML

I didn't actually craft this patch to address any TLS weakness; I wrote
it to address a feature flaw/conflict.

Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say, you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)

This is the standard x509 model, used to secure all SSL sites -- =20

=2E.. when verifying the server's identity from the point of view of the
client. It's also assumed that the server, upon changing its name, will
also change its certificate. This is a valid assumption because servers
are essentially public resources that have to be advertised.

If you do not trust the CAs listed in your CA bundle to correctly =20
issue certificates, then you can't trust "www.hsbc.com" to be HSBC =20
Bank, either.

This is only true from the client to the server in the TLS model (in
Bacula's case, the Director can validate that the FD is what it thinks
it should be). It does not offer protection in the opposite direction by
default.

Bacula has an option for any server process to validate arbitrary data
in the corresponding client's CN to try and accomodate the reverse (as
I'm sure you're aware, you probably wrote it).

I don't understand your failure case -- the *entire purpose* of a CA =20
is to sign certificates by validating the requesting party.

Okay. Let's look at two features in Bacula. This gets to the heart of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the Address
field in the Director's configuration, and the Address field is used as
the DNS name to look up in order to connect to the FD).

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director more
flexible (i.e. separate the piece of information embedded in the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to separate
the cert CN from the information used to connect to the client (the CN
contains something other than the hostname, and is manually validated).
The other is analogous: have the director keep a second string for the
address update via setip, and then connect to the alternate string but
validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of flexibility,
and Bacula already (by and large) has the infrastructure to deal with
this.

That's the patch that we're discussing.

More discussion is welcome.

-- Jorj

Attachments: PGP.sig

On Mar 14, 2007, at 13:41, Jorj Bauer wrote:

Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say,
you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)

Sure -- this is the point of centralized x509 infrastructure. The
best defense is limiting ones exposure by not trusting a wide array
of CAs.

In an ideal world, we'd have nice PGP-style web of, and levels, of
trust.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.

Okay. Let's look at two features in Bacula. This gets to the heart
of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the Address
field in the Director's configuration, and the Address field is
used as
the DNS name to look up in order to connect to the FD).

Either the CN, or the subjectAltName. For mobile clients, without
dynamic DNS, this isn't really workable.

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will
fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director
more
flexible (i.e. separate the piece of information embedded in
the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to separate
the cert CN from the information used to connect to the client (the CN
contains something other than the hostname, and is manually
validated).
The other is analogous: have the director keep a second string for the
address update via setip, and then connect to the alternate string but
validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of
flexibility,
and Bacula already (by and large) has the infrastructure to deal with
this.

Supporting arbitrary CN values in Bacula is a cheap and effective way
of decoupling TLS authentication from the hostname, and seems
reasonable.

If Kern doesn't have any objections, I'd like to merge it into HEAD.

-landonf

Hello Landon,

On Wednesday 14 March 2007 20:34, Landon Fuller wrote:
Sorry for the late arrival. An opendarwin.org e-mail hiccup ate my
subscription.

Kern Sibbald wrote:
Well, I care, and I don't trust DNS at all. From what I read here,
IMO the current implementation is nothing like I imagined -- it is
not the state of the art in security. With ssh, I generate a public/
private key pair and I am sure that no one that does not have the
private key can enter. This is the *minimum* that I expected for
the TLS implementation.

I hope this is just a misunderstanding on my part.

The TLS implementation does not, under any circumstances, rely on the
security of DNS. It is implemented using standard internet best
practices:
- The remote host must present a certificate that is signed by a
**trusted** certificate authority
- The certificate must match the hostname we requested. (eg, Address
= fqdn.example.org)
- The certificate must not have expired.
- The certificate must contain the correct role (ie, server, or
client).

This is the standard x509 model, used to secure all SSL sites --
including my bank. I was very careful to adhere to best practices
while implementing the TLS support -- we use it to backup highly
sensitive billing data.

Jorj Bauer wrote:
All that TLS/SSL does is verify that the certificate is signed
properly.
Bacula is then validating the contents of the certificate based on CN.

So if you use your own custom CA, then only certificates which you
signed will be verified. But if you use a public CA, and have the
certificate cut by another authority, then you have to trust that no
public authority (which is listed in your CA directory or CA
bundle) has
issued a certificate with the same embedded CN information.

If you do not trust the CAs listed in your CA bundle to correctly
issue certificates, then you can't trust "www.hsbc.com" to be HSBC
Bank, either.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party. If a CA
issues a duplicate certificate for a given CN to an unverified,
untrusted party, then that CA has failed in their primary task. That
is to say, your failure case is analogous to providing the private
key to an attacker -- of course security fails.

The (minor) problem that concerned me was not at all the trust of the CA since
each user can decide which CAs he trusts, but it was the problems that could
occur if a CA issued a certificate with a duplicate name to one that you are
using.

Regards,

Kern

On Wednesday 14 March 2007 22:29, Landon Fuller wrote:
On Mar 14, 2007, at 13:41, Jorj Bauer wrote:
Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say,
you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)

Sure -- this is the point of centralized x509 infrastructure. The
best defense is limiting ones exposure by not trusting a wide array
of CAs.

In an ideal world, we'd have nice PGP-style web of, and levels, of
trust.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.

Okay. Let's look at two features in Bacula. This gets to the heart
of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the Address
field in the Director's configuration, and the Address field is
used as
the DNS name to look up in order to connect to the FD).

Either the CN, or the subjectAltName. For mobile clients, without
dynamic DNS, this isn't really workable.

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will
fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director
more
flexible (i.e. separate the piece of information embedded in
the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to separate
the cert CN from the information used to connect to the client (the CN
contains something other than the hostname, and is manually
validated).
The other is analogous: have the director keep a second string for the
address update via setip, and then connect to the alternate string but
validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of
flexibility,
and Bacula already (by and large) has the infrastructure to deal with
this.

Supporting arbitrary CN values in Bacula is a cheap and effective way
of decoupling TLS authentication from the hostname, and seems
reasonable.

If Kern doesn't have any objections, I'd like to merge it into HEAD.

I don't have any objections with the feature enhancement, but at the current
time we cannot use the patch supplied because it is copyrighted by the
University, and they seem to be unlikely (to the best of my knowledge) to
sign or agree to the FLA.

Nor do I have problems with "fixing" the bug reported by Jorj (if I remember
right) where there is a problem handling wild-card CNs.

Best regards,

Kern


-landonf

Jorj Bauer wrote:
I didn't actually craft this patch to address any TLS weakness; I wrote
it to address a feature flaw/conflict.

Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say, you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)


Bacula does its normal HMAC-MD5 password authentication before starting
TLS. It would also be necessary for an attacker to have the FD password,
in which case either the FD or the Dir has already been compromised.


This is the standard x509 model, used to secure all SSL sites --


... when verifying the server's identity from the point of view of the
client. It's also assumed that the server, upon changing its name, will
also change its certificate. This is a valid assumption because servers
are essentially public resources that have to be advertised.


If you do not trust the CAs listed in your CA bundle to correctly
issue certificates, then you can't trust "www.hsbc.com" to be HSBC
Bank, either.


This is only true from the client to the server in the TLS model (in
Bacula's case, the Director can validate that the FD is what it thinks
it should be). It does not offer protection in the opposite direction by
default.

Bacula has an option for any server process to validate arbitrary data
in the corresponding client's CN to try and accomodate the reverse (as
I'm sure you're aware, you probably wrote it).


I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.


Okay. Let's look at two features in Bacula. This gets to the heart of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the Address
field in the Director's configuration, and the Address field is used as
the DNS name to look up in order to connect to the FD).

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director more
flexible (i.e. separate the piece of information embedded in the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to separate
the cert CN from the information used to connect to the client (the CN
contains something other than the hostname, and is manually validated).
The other is analogous: have the director keep a second string for the
address update via setip, and then connect to the alternate string but
validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of flexibility,
and Bacula already (by and large) has the infrastructure to deal with
this.

That's the patch that we're discussing.

More discussion is welcome.



The FD address cannot be part of the certificate (CN or any other field)
if roaming FDs are ever to be supported. An arbitrary CN will
effectively make TLS used for encryption only, not authentication,
albeit the cert will still have to be signed by a trusted CA. There's
nothing wrong with that. Most secure websites use TLS in this manner,
requiring password auth after TLS is started. The difference here is
that Bacula does HMAC-MD5 auth before starting TLS, but it is the same
net effect.

Your patch (or something similar) is necessary to support roaming
clients using TLS. So with this patch the cert can be used regardless of
FD address, getting a step closer to support of roaming FDs. But how and
when does the "SetIP" console command get sent to the Dir?

I see several problems with the SetIP approach. What if Bacula attempts
to run the job before the SetIP is issued? What if the SetIP is issued,
but before the job is run bacula-dir is restarted or reloaded? For
roaming clients that are not on all of the time it is entirely likely
that they will only rarely if ever be backed up. The patch allows TLS to
work for these clients, but still leaves it a guessing game as to when
to run the job. I don't see how roaming FDs are really feasible until
client-initiated backups are implemented. Still, separating the FD
address from the cert is going to be required in order to support
roaming clients.

--- Josh

-- Jorj

------------------------------------------------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
------------------------------------------------------------------------

_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

Attachments: Message as HTML

Bacula does its normal HMAC-MD5 password authentication

I never meant to imply that it did not, although my message was
obviously interpreted that way by at least two people.

The FD address cannot be part of the certificate (CN or any other field)=
=20
if roaming FDs are ever to be supported.

Agreed.

An arbitrary CN will effectively make TLS used for encryption only,
not authentication,

Not true; with my proposed patch, the required CN is specified in the
Client clause of the Director's config file. One would be verifying that
it is the correct machine by virtue of the contents of the CN field, but
with something other than a hostname. Of course one could neuter this by
embedding the same information in each certificate if one wanted to, but
I don't see a reason for that.

Your patch (or something similar) is necessary to support roaming=20
clients using TLS. So with this patch the cert can be used regardless of=
=20
FD address, getting a step closer to support of roaming FDs. But how and=
=20
when does the "SetIP" console command get sent to the Dir?

That's done through a restricted console.

I see several problems with the SetIP approach. What if Bacula attempts=
=20
to run the job before the SetIP is issued?

Then the job will fail.

What if the SetIP is issued, but before the job is run bacula-dir is
restarted or reloaded?

I assume the job will fail, as the Director will be looking at the wrong
address.

For roaming clients that are not on all of the time it is entirely
likely that they will only rarely if ever be backed up.

My intent is to not schedule roaming clients at all, but rather have the
clients issue a "setip" followed by a "run job=3D".

The patch allows TLS to work for these clients, but still leaves it a
guessing game as to when to run the job.

I don't see how roaming FDs are really feasible until client-initiated
backups are implemented.

And this is possible now, to some extent, using a console. It's not yet
clear to me whether or not the restricted-console needs to be expanded
to be able to run jobs for the given client, or if the security of the
"name" being correct is sufficient, or if subsequent TLS cerificate
information would need to be present (and validated in some manner).

Still, separating the FD address from the cert is going to be required
in order to support roaming clients.

Indeed.

-- Jorj

On Thu, Mar 15, 2007 at 12:04:00AM +0100, Kern Sibbald wrote:
On Wednesday 14 March 2007 22:29, Landon Fuller wrote:
On Mar 14, 2007, at 13:41, Jorj Bauer wrote:
Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say,
you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)

Sure -- this is the point of centralized x509 infrastructure. The
best defense is limiting ones exposure by not trusting a wide array
of CAs.

In an ideal world, we'd have nice PGP-style web of, and levels, of
trust.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.

Okay. Let's look at two features in Bacula. This gets to the heart
of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the Address
field in the Director's configuration, and the Address field is
used as
the DNS name to look up in order to connect to the FD).

Either the CN, or the subjectAltName. For mobile clients, without
dynamic DNS, this isn't really workable.

(2) The Director's "setip" command. This allows a client to change its
Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will
fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director
more
flexible (i.e. separate the piece of information embedded in
the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to separate
the cert CN from the information used to connect to the client (the CN
contains something other than the hostname, and is manually
validated).
The other is analogous: have the director keep a second string for the
address update via setip, and then connect to the alternate string but
validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of
I don't have any objections with the feature enhancement, but at the current
time we cannot use the patch supplied because it is copyrighted by the
University, and they seem to be unlikely (to the best of my knowledge) to
sign or agree to the FLA.

The University has verbally agreed to transfer copyright. I'm working on
the paperwork now.

-- Jorj

On Thursday 15 March 2007 16:46, Jorj Bauer wrote:
On Thu, Mar 15, 2007 at 12:04:00AM +0100, Kern Sibbald wrote:
On Wednesday 14 March 2007 22:29, Landon Fuller wrote:
On Mar 14, 2007, at 13:41, Jorj Bauer wrote:
Let's take the DNS security issue off the table for the moment.
As I mentioned at some point, that's mostly paranoia. As you say,
you'd
have to compromise both DNS and one of the root CAs to exploit it. I
only mentioned it for those that are totally paranoid about securing
their clients. (I'm sure they're out there.)

Sure -- this is the point of centralized x509 infrastructure. The
best defense is limiting ones exposure by not trusting a wide array
of CAs.

In an ideal world, we'd have nice PGP-style web of, and levels, of
trust.

I don't understand your failure case -- the *entire purpose* of a CA
is to sign certificates by validating the requesting party.

Okay. Let's look at two features in Bacula. This gets to the heart
of my
original problem.

(1) TLS. This requires that a FD be at a particular DNS name
(specifically, that the FD certificate's CN is the same as the
Address field in the Director's configuration, and the Address field
is used as
the DNS name to look up in order to connect to the FD).

Either the CN, or the subjectAltName. For mobile clients, without
dynamic DNS, this isn't really workable.

(2) The Director's "setip" command. This allows a client to change
its Address registered with the Director.

If one uses (2) to change the address of the client, then (1) will
fail.
The only ways to avoid this are to

(a) issue new certificates every time the address changes;

or

(b) decouple validation from the DNS name by making the director
more
flexible (i.e. separate the piece of information embedded in
the cert
from the one that's used to connect to the client).

Where (b) can be accomplished in at least two ways. One is to
separate the cert CN from the information used to connect to the
client (the CN contains something other than the hostname, and is
manually
validated).
The other is analogous: have the director keep a second string for
the address update via setip, and then connect to the alternate
string but validate the original one.

The latter method doesn't solve a similar problem, though: what if a
device has to change name for a non-technical reason? For example, an
office move in an organization where the DNS names are tied to
geographic location. Using non-DNS information embedded in the
certificate here provides a significantly greater level of

I don't have any objections with the feature enhancement, but at the
current time we cannot use the patch supplied because it is copyrighted
by the University, and they seem to be unlikely (to the best of my
knowledge) to sign or agree to the FLA.

The University has verbally agreed to transfer copyright. I'm working on
the paperwork now.

That's really great. Thanks for your efforts! :-)

Landon, at this point, as far as I am concerned, you can proceed with adding
the code. Also, if Jorj has other points (bugs), please don't hesitate to
address them keeping me informed of you plans.

Thanks,

Kern

PS: Jorj, please let me know when the FLA is sent. That helps me track it.
Thanks.

On Thursday 15 March 2007 16:40, Jorj Bauer wrote:
Bacula does its normal HMAC-MD5 password authentication

I never meant to imply that it did not, although my message was
obviously interpreted that way by at least two people.

The FD address cannot be part of the certificate (CN or any other field)
if roaming FDs are ever to be supported.

Agreed.

An arbitrary CN will effectively make TLS used for encryption only,
not authentication,

Not true; with my proposed patch, the required CN is specified in the
Client clause of the Director's config file. One would be verifying that
it is the correct machine by virtue of the contents of the CN field, but
with something other than a hostname. Of course one could neuter this by
embedding the same information in each certificate if one wanted to, but
I don't see a reason for that.

Your patch (or something similar) is necessary to support roaming
clients using TLS. So with this patch the cert can be used regardless of
FD address, getting a step closer to support of roaming FDs. But how and
when does the "SetIP" console command get sent to the Dir?

That's done through a restricted console.

I see several problems with the SetIP approach. What if Bacula attempts
to run the job before the SetIP is issued?

Then the job will fail.

What if the SetIP is issued, but before the job is run bacula-dir is
restarted or reloaded?

I assume the job will fail, as the Director will be looking at the wrong
address.

For roaming clients that are not on all of the time it is entirely
likely that they will only rarely if ever be backed up.

My intent is to not schedule roaming clients at all, but rather have the
clients issue a "setip" followed by a "run job=".

The patch allows TLS to work for these clients, but still leaves it a
guessing game as to when to run the job.

I don't see how roaming FDs are really feasible until client-initiated
backups are implemented.

And this is possible now, to some extent, using a console. It's not yet
clear to me whether or not the restricted-console needs to be expanded
to be able to run jobs for the given client, or if the security of the
"name" being correct is sufficient, or if subsequent TLS cerificate
information would need to be present (and validated in some manner).

Though there is a project for client initiated backups, I view it as already
being implemented by using scripting with bconsole and restricted clients
that send a setip followed by a run job as you have described above.

There is one (important) case where the above does not work, and that is that
the client cannot truely run as a "server" because it is NATed or behind a
firewall. To resolve that, I envision that at some point in the future, the
FD itself will have a "mini" console implemented in it, that will connect to
the Director, issue the setip and run job, then will use the same open
connection for the backup. The client will still need *exactly* the same
restricted console privileges as the current client bconsole scripting
requires to initiate the backup.


Still, separating the FD address from the cert is going to be required
in order to support roaming clients.

Indeed.

-- Jorj

Kern Sibbald wrote:
On Thursday 15 March 2007 16:40, Jorj Bauer wrote:

Bacula does its normal HMAC-MD5 password authentication

I never meant to imply that it did not, although my message was
obviously interpreted that way by at least two people.


The FD address cannot be part of the certificate (CN or any other field)
if roaming FDs are ever to be supported.

Agreed.


An arbitrary CN will effectively make TLS used for encryption only,
not authentication,

Not true; with my proposed patch, the required CN is specified in the
Client clause of the Director's config file. One would be verifying that
it is the correct machine by virtue of the contents of the CN field, but
with something other than a hostname. Of course one could neuter this by
embedding the same information in each certificate if one wanted to, but
I don't see a reason for that.


Your patch (or something similar) is necessary to support roaming
clients using TLS. So with this patch the cert can be used regardless of
FD address, getting a step closer to support of roaming FDs. But how and
when does the "SetIP" console command get sent to the Dir?

That's done through a restricted console.


I see several problems with the SetIP approach. What if Bacula attempts
to run the job before the SetIP is issued?

Then the job will fail.


What if the SetIP is issued, but before the job is run bacula-dir is
restarted or reloaded?

I assume the job will fail, as the Director will be looking at the wrong
address.


For roaming clients that are not on all of the time it is entirely
likely that they will only rarely if ever be backed up.

My intent is to not schedule roaming clients at all, but rather have the
clients issue a "setip" followed by a "run job=".


The patch allows TLS to work for these clients, but still leaves it a
guessing game as to when to run the job.

I don't see how roaming FDs are really feasible until client-initiated
backups are implemented.

And this is possible now, to some extent, using a console. It's not yet
clear to me whether or not the restricted-console needs to be expanded
to be able to run jobs for the given client, or if the security of the
"name" being correct is sufficient, or if subsequent TLS cerificate
information would need to be present (and validated in some manner).


Though there is a project for client initiated backups, I view it as already
being implemented by using scripting with bconsole and restricted clients
that send a setip followed by a run job as you have described above.

There is one (important) case where the above does not work, and that is that
the client cannot truely run as a "server" because it is NATed or behind a
firewall. To resolve that, I envision that at some point in the future, the
FD itself will have a "mini" console implemented in it, that will connect to
the Director, issue the setip and run job, then will use the same open
connection for the backup. The client will still need *exactly* the same
restricted console privileges as the current client bconsole scripting
requires to initiate the backup.



Thank you both. That answers my questions and is what I meant by
supporting roaming FDs. For example, we have people here who travel
quite a bit and connect through hotel networks. It is perhaps possible
to backup those laptops through VPN tunnels (in which case neither
Bacula TLS nor SetIP may be needed), but they are not connected
regularly enough for a scheduled job. I am just now learning of the
ability of a client to initiate backups through the restricted console,
so I will give that a try.

Still, separating the FD address from the cert is going to be required
in order to support roaming clients.

Indeed.

-- Jorj


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users