Howard Chu wrote, On 2008-08-12 19:12: > That was the other point I was trying to make about global state... It's > common practice to set up services with private CAs, so that random nosy > clients cannot connect to them. In an OpenLDAP proxy installation you'll > have one server cert/key and arbitrarily many client cert/key pairs for > connecting to various remote servers. Each of those client credentials > may use different CAs, and may be different from the server's > credentials. It would be bad if loading all of those certDBs meant that > the proxy server would then accept incoming connections from clients > using any of those CAs. Currently we can keep each context separate, > using OpenSSL and/or GnuTLS.
I didn't understand that very well, but I _think_ you're saying that if adding a CA cert that trusted to issue client certs causes that CA to also be trusted to issue server certs, that would be bad. Indeed, that would be bad, and it definitely will NOT happen with NSS. NSS divides trust up by "usages", which correspond roughly to KUs and EKUs. It has separate trust for SSL server CAs, SSL client CAs, S/MIME peer CAs, code/object signing CAs, etc. > Likewise in the Mozilla Browser/nss_ldap situation, the credentials > needed for LDAP authentication will probably be quite different from the > credentials needed for web browsing or personal addressbook lookups. It > would be extremely bad if simply using Mozilla on a system with > nss_ldap/LDAP/MozNSS allowed arbitrary browser users to get privileged > secure connections to their authentication server just by adding a new > AddressBook definition. How would that happen? What is it that you're worried about those clients' browsers obtaining? A certificate for an LDAP server? A certificate for a CA that is trusted to issue certs to LDAP servers? A private key for a client's cert, used to authenticate to the ldap server? Something else? It sounds like you're worried that the clients might obtain the remote LDAP servers' certs, or CA certs for issuers of the remote LDAP servers' certs. But of course, clients can trivially get those certs simply by starting an SSL handshake with the remote server, because the server will send the chain to the client. The client need not have a trusted anchor to be able to use the cert. It can always ignore invalid issuers (if the user so chooses) and finish the handshake anyway. Perhaps you're worried that the client will somehow get access to a private key used to authenticate to the remote server, a key that (I gather) is used when the user logs in to the system. What keeps that key out of the user's hands normally? If any user process, running with the user's credentials, has access to that key, then the user will also have access to it when he runs his browser. In short, I really don't understand what vulnerability you fear exists here, but I doubt that it exists. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
