Dear Victor, Thanks again for your help.
A bit of background - I'm using SSL in a peer-to-peer scenario, so each *process* - for want of a better word - (from a TLS perspective) will act as a TLS client, if they initiate a connection to another, and/or a TLS Server if they receive a connection request. In many instances, both. In our current implementation, we assume every process has a certificate associated with it, and thus, from a TLS perspective, clients will validate server certificates, and servers will request and validate client certificates for each connection. (That is, each peer will check the validate the cert of the other). We want to introduce 'processes' that don't have certificates to be able to interact with other components in the system. Can I see if I understand correctly. Essentially I should ensure that each process in the system has (at least) the anonymous (aNull) cipher in their list. Those with certificates should also include a cipher that involves certificates in list. In that way, if a process without a cert tries to connect to any other process -- the anon cipher will be negotiated + used. However, if the two processes both have certificates (and a common cipher that involves certificates in their list), the connection will be negotiated using the cipher involving the certificates. (I suppose there is some priority <perhaps configurable> to selecting the cipher that is negotiated??) After the connection is established, a process can then determine what cipher was used, and how to proceed (e.g. if negotiated with certificates, then we can validate the peer's cert, etc; if not, then we can trust a certain peer 'less' than we would others, etc). Is that a correct interpretation? Thanks again, N ----- Original Message ----- From: Viktor Dukhovni <openssl-us...@dukhovni.org> To: "openssl-users@openssl.org" <openssl-users@openssl.org> Cc: Sent: Friday, 1 February 2013, 15:22 Subject: Re: Null (or default) certificates? On Fri, Feb 01, 2013 at 01:46:46PM +0000, Nathan Smyth wrote: > Is it possible to have null, untrusted, or shared certificates, > to simplify deployment for apps that don't care about SSL? Absolutely. On all servers that don't require client certificates (can't ask for client certs when using an anonymous ciphersuite) enable anonymous ciphers, using an appropriate configuration parameter that invokes SSL_CTX_set_cipher_list(). A sensible cipher list for OpenSSL 1.x is: aNULL:-aNULL:ALL:!EXPORT:!LOW:!SSLv2:@STRENGTH This applies even to servers that have certificates. Some check-list encumbered humanoid robots will tell you that enabling anonymous ciphers on servers is bad. Don't listen to them, they don't know what they're talking about. See below. On servers where certificate deployment is impractical, or none of whose clients will verify any deployed certificate even if it is good, don't assign a private key or certificate. With anonymous ciphers enabled, you don't need to specify any certs or keys. Only clients that don't check peer certificates will be able to connect to such servers. On clients that don't check peer certificates, also enable anonymous ciphers with the same cipherlist. Here, the check-list encumbered humanoid robots will have a valid point to make, such clients are vulnerable to MITM attacks, you'll have to sign-off on that risk. Such clients will be able to connect to servers that have no certificates at all, and will also choose anonymous ciphers with servers that have certificates they don't care to inspect. As for the check-list humanoids, try to explain to them that a server is *more* secure when it enables and prefers aNULL ciphers, in fact the server should tell OpenSSL to order the cipherlist based on the server's preference, choosing aNULL whenever possible: - If a client is willing to negotiate aNULL, that client is always vulnerable to MITM attacks, the server can't stop them, since the MITM will always offer aNULL ciphers. - By also negotiating aNULL (at highest preference) the server can detect that the client is MITM-vulnerable, and log this, and perhaps even offer reduced service. - By hiding the problem under the rug and not offering aNULL a server is blissfully unware of the client's misconfiguration and potentially makes sensitive resources available to MITM vulnerable clients with no audit-trail. Therefore, get into the habit of enabling aNULL ciphers on servers, and negotiating them whenever possible. On clients, whenever possible and authentication is not implemented by other means (say GSSAPI mutual authentication with channel bindings, ....) by all means disable aNULL ciphers and verify the server certificate trust chain as well as the server identity (protocol appropriate subjectAltName or else CN). A server with no certificates at all, will only be able to complete handshakes with aNULL enabled clients. If you give such a server self-signed untrusted certificates, the handshake may proceed further, but clients that want trusted certificates will valid peernames will still reject them, so the main reason to field self-signed certs is to support any clients that don't check certs but have not been configured to allow aNULL ciphers (they pretend to care about MITM, but don't). One thing to consider is support for DANE (RFC 6698), in which you don't always need a CA to verify a peer certificate for a server. Rather, with DNSSEC-aware clients you can map the service end-point to a cert or public-key fingerprint. This makes deploying server certificates a lot simpler/cheaper, but you then need tools to publish "TLSA" records into DNSSEC zones whenever you field new services or regenerate self-signed certs. _443._tcp.www.example.com IN TLSA ( 3 1 1 <sha256-hex-digest-of-public-key> ) -- Viktor. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
