Re: [Bacula-users] Feature request: more flexible TLS cert validation

2007-03-11 Thread Pierre Bernhardt 
Kern Sibbald schrieb:
 Hello,
Hi,
 
 Unless I am mistaken, even if there is a duplicate CN as you fear, it seems 
 to 
 me it should pose no problems because the certificate would not match.
 
 Does someone more experienced with TLS know the answer to that?
Hmm. I'm not an expert but I've learned much of tls/ssl by installing
them on bacula 2 :-)

you must use for every IP/Hostname an own certificate.
But it's ok to use one key per machine with different related
certificates (you should know that one key can have much of
certificates) I do this.

I have a full TLS and PKI solution on test at the moment. I've created my own
root certificate so I can use trusted connections. The certificates
which are installed are related to:

1. Certificate for a access from a user.
2. Certificate for grant the bacula service.
3. Decryption Key for every user.
4. Decryption Key for bacula service.

5. Certificate for PKI Master encryption.
6. Certificate for PKI FD-Related encryption.

So I have one key for every real user (me at the moment, the server and
every (at the moment one) client)
or better understand:

Easy:
A. Every service which opens a port have a own cert.
B. Every clientmachine which opens a connection have a own cert,
including the bacula server, too.

Why:
The director will connect to the storage deamon.
In this situation the director is the client (B.) and the storage daemon is
the service (A.)

or:
The bconsole (B.) will connect to the director (A.)

or:
The director (B.) will connect to a file daemon (A.)

or:
The storage deamon (B.) will connect to the director (A.)

any more...?

If all is on the same machine under the same user:

A. is a service cert from a key related on the interface.
B. is a user cert from a key related from the [EMAIL PROTECTED]

On my server I'm using only one key with two certs created from:

eg. cn = bserver.localnet for A.
cn = [EMAIL PROTECTED] for B.

For a second fd client I use a different key but with two certs, too:

eg. cn = client.localnet for A.
cn = [EMAIL PROTECTED] for B.

For a bconsole I use an own key/cert:

eg. cn = [EMAIL PROTECTED]

Further information:

The cn for A. must the same configured in the rules for Address


The cn for B. can be all you want (include the one for A.).
But I'd trouble before I used good identified cn's.

Any questions?

MfG...
Pierre Bernhardt


-
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] Feature request: more flexible TLS cert validation

2007-03-08 Thread Jorj Bauer 
What: The ability for the director to validate a Client (FD) CN against
an arbitrary set of patterns (cf. TLS Allowed CN options for
clients), rather than the hostname.

Why: DNS is not secure. Also, computers may move to new networks, and
local policy may tie hostnames to a physical location. For
example, in UPenn's school of Engineering, hostnames are of the
form building-room.seas.upenn.edu. When someone changes offices,
their hostname changes.

Notes: The following patch (written for 2.0.2, but also applies cleanly
to 2.0.3) implements this feature. If TLS Allowed CN clauses are
provided in the Client{} stanza, then pattern matching is used in place
of hostname matching against the Certificate's CN. As an example, we
have certificates which (a) use a local CA, and (b) have a CN of the
form client_123. A client's stanza in the director's config file may
read like this:

Client {
  Name = client_123
  Address = fqdn.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = ** some password here **
  File Retention = 30 days
  Job Retention = 60 days
  AutoPrune = yes
  TLS Require = yes
  TLS CA Certificate File = /usr/local/etc/bacula.d/ca.crt
  TLS Certificate = /usr/local/etc/bacula.d/client.crt
  TLS Key = /usr/local/etc/bacula.d/client.key
  TLS Allowed CN = client_123
}

... note that you would not want to use this feature with public CAs,
since there would be no guarantee that another certificate with that CN
had not been issued.

Additionally, UPenn/SEAS is planning for the future. Our client machines
are increasingly mobile (laptops instead of desktops). We're migrating
to Bacula from a home-grown backup system which had plans for mobile
backups. The client phones home to the director, which updates its IP
address for that client, and then backs it up at its new location.
Adding a TLS Allowed CN option for the director to validate clients
allows this sort of flexible certificate validation for future Bacula
features (whether or not this will be one of them is not my focus here).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jorj Bauer  |   [EMAIL PROTECTED]
IT Director | 3330 Walnut St.
School of Engineering and Applied Science   |Levine Building, Room 160
University of Pennsylvania  | Philadelphia, PA 19104
http://www.jorj.org/| O: 215/898-0575 F: 215/898-1195
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


diff --recursive -u bacula-2.0.2/src/console/authenticate.c 
bacula-2.0.2.patched/src/console/authenticate.c
--- bacula-2.0.2/src/console/authenticate.c 2006-11-21 15:14:46.0 
-0500
+++ bacula-2.0.2.patched/src/console/authenticate.c 2007-02-16 
15:06:23.0 -0500
@@ -127,7 +127,7 @@
if (have_tls) {
   if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK) {
  /* Engage TLS! Full Speed Ahead! */
- if (!bnet_tls_client(tls_ctx, dir)) {
+ if (!bnet_tls_client(tls_ctx, dir, NULL)) {
 sendit(_(TLS negotiation failed\n));
 goto bail_out;
  }
diff --recursive -u bacula-2.0.2/src/dird/authenticate.c 
bacula-2.0.2.patched/src/dird/authenticate.c
--- bacula-2.0.2/src/dird/authenticate.c2006-11-21 08:20:08.0 
-0500
+++ bacula-2.0.2.patched/src/dird/authenticate.c2007-02-16 
15:12:13.0 -0500
@@ -131,7 +131,7 @@
/* Is TLS Enabled? */
if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK) {
   /* Engage TLS! Full Speed Ahead! */
-  if (!bnet_tls_client(store-tls_ctx, sd)) {
+  if (!bnet_tls_client(store-tls_ctx, sd, NULL)) {
  stop_bsock_timer(tid);
  Jmsg(jcr, M_FATAL, 0, _(TLS negotiation failed with SD on 
\%s:%d\\n),
 sd-host, sd-port);
@@ -235,7 +235,8 @@
/* Is TLS Enabled? */
if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK) {
   /* Engage TLS! Full Speed Ahead! */
-  if (!bnet_tls_client(client-tls_ctx, fd)) {
+  if (!bnet_tls_client(client-tls_ctx, fd, client-tls_allowed_cns)) {
+
  stop_bsock_timer(tid);
  Jmsg(jcr, M_FATAL, 0, _(TLS negotiation failed with FD on 
\%s:%d\.\n),
   fd-host, fd-port);
diff --recursive -u bacula-2.0.2/src/dird/dird_conf.c 
bacula-2.0.2.patched/src/dird/dird_conf.c
--- bacula-2.0.2/src/dird/dird_conf.c   2006-12-22 10:40:15.0 -0500
+++ bacula-2.0.2.patched/src/dird/dird_conf.c   2007-02-16 21:44:51.0 
-0500
@@ -189,6 +189,7 @@
{tlscacertificatedir,  store_dir,   ITEM(res_client.tls_ca_certdir), 
0, 0, 0},
{tlscertificate,   store_dir,   ITEM(res_client.tls_certfile), 0, 
0, 0},
{tlskey,   store_dir,   ITEM(res_client.tls_keyfile), 0, 
0, 0},
+   {tlsallowedcn, store_alist_str, ITEM(res_client.tls_allowed_cns), 
0, 0, 0},

Re: [Bacula-users] Feature request: more flexible TLS cert validation

2007-03-08 Thread Kern Sibbald 
Hello,

Unless I am mistaken, even if there is a duplicate CN as you fear, it seems to 
me it should pose no problems because the certificate would not match.

Does someone more experienced with TLS know the answer to that?

Best regards,

Kern

On Thursday 08 March 2007 15:00, Jorj Bauer wrote:
 What: The ability for the director to validate a Client (FD) CN against
   an arbitrary set of patterns (cf. TLS Allowed CN options for
   clients), rather than the hostname.

 Why: DNS is not secure. Also, computers may move to new networks, and
   local policy may tie hostnames to a physical location. For
   example, in UPenn's school of Engineering, hostnames are of the
   form building-room.seas.upenn.edu. When someone changes offices,
   their hostname changes.

 Notes: The following patch (written for 2.0.2, but also applies cleanly
 to 2.0.3) implements this feature. If TLS Allowed CN clauses are
 provided in the Client{} stanza, then pattern matching is used in place
 of hostname matching against the Certificate's CN. As an example, we
 have certificates which (a) use a local CA, and (b) have a CN of the
 form client_123. A client's stanza in the director's config file may
 read like this:

 Client {
   Name = client_123
   Address = fqdn.example.com
   FDPort = 9102
   Catalog = MyCatalog
   Password = ** some password here **
   File Retention = 30 days
   Job Retention = 60 days
   AutoPrune = yes
   TLS Require = yes
   TLS CA Certificate File = /usr/local/etc/bacula.d/ca.crt
   TLS Certificate = /usr/local/etc/bacula.d/client.crt
   TLS Key = /usr/local/etc/bacula.d/client.key
   TLS Allowed CN = client_123
 }

 ... note that you would not want to use this feature with public CAs,
 since there would be no guarantee that another certificate with that CN
 had not been issued.

 Additionally, UPenn/SEAS is planning for the future. Our client machines
 are increasingly mobile (laptops instead of desktops). We're migrating
 to Bacula from a home-grown backup system which had plans for mobile
 backups. The client phones home to the director, which updates its IP
 address for that client, and then backs it up at its new location.
 Adding a TLS Allowed CN option for the director to validate clients
 allows this sort of flexible certificate validation for future Bacula
 features (whether or not this will be one of them is not my focus here).

 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=- Jorj Bauer  |   [EMAIL PROTECTED]
 IT Director | 3330 Walnut St.
 School of Engineering and Applied Science   |Levine Building, Room 160
 University of Pennsylvania  | Philadelphia, PA 19104
 http://www.jorj.org/| O: 215/898-0575 F:
 215/898-1195
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-


 diff --recursive -u bacula-2.0.2/src/console/authenticate.c
 bacula-2.0.2.patched/src/console/authenticate.c ---
 bacula-2.0.2/src/console/authenticate.c   2006-11-21 15:14:46.0 
 -0500
 +++ bacula-2.0.2.patched/src/console/authenticate.c   2007-02-16
 15:06:23.0 -0500 @@ -127,7 +127,7 @@
 if (have_tls) {
if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK)
 { /* Engage TLS! Full Speed Ahead! */
 - if (!bnet_tls_client(tls_ctx, dir)) {
 + if (!bnet_tls_client(tls_ctx, dir, NULL)) {
  sendit(_(TLS negotiation failed\n));
  goto bail_out;
   }
 diff --recursive -u bacula-2.0.2/src/dird/authenticate.c
 bacula-2.0.2.patched/src/dird/authenticate.c ---
 bacula-2.0.2/src/dird/authenticate.c  2006-11-21 08:20:08.0 -0500
 +++ bacula-2.0.2.patched/src/dird/authenticate.c  2007-02-16
 15:12:13.0 -0500 @@ -131,7 +131,7 @@
 /* Is TLS Enabled? */
 if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK) {
/* Engage TLS! Full Speed Ahead! */
 -  if (!bnet_tls_client(store-tls_ctx, sd)) {
 +  if (!bnet_tls_client(store-tls_ctx, sd, NULL)) {
   stop_bsock_timer(tid);
   Jmsg(jcr, M_FATAL, 0, _(TLS negotiation failed with SD on
 \%s:%d\\n), sd-host, sd-port);
 @@ -235,7 +235,8 @@
 /* Is TLS Enabled? */
 if (tls_local_need = BNET_TLS_OK  tls_remote_need = BNET_TLS_OK) {
/* Engage TLS! Full Speed Ahead! */
 -  if (!bnet_tls_client(client-tls_ctx, fd)) {
 +  if (!bnet_tls_client(client-tls_ctx, fd, client-tls_allowed_cns))
 { +
   stop_bsock_timer(tid);
   Jmsg(jcr, M_FATAL, 0, _(TLS negotiation failed with FD on
 \%s:%d\.\n), fd-host, fd-port);
 diff --recursive -u bacula-2.0.2/src/dird/dird_conf.c
 bacula-2.0.2.patched/src/dird/dird_conf.c ---
 bacula-2.0.2/src/dird/dird_conf.c 2006-12-22 10:40:15.0 -0500 +++
 bacula-2.0.2.patched/src/dird/dird_conf.c 2007-02-16 21:44:51.0
 -0500 @@ -189,6 +189,7 @@