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 ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
