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
