On Fri, Feb 01, 2013 at 04:24:47PM +0000, Nathan Smyth wrote:
> > On all servers that don't require client certificates
> > (can't ask for client certs when using an anonymous ciphersuite)
> > enable anonymous ciphers,?
>
> Is it possible to both - in the sense you can check the peer's
> certificate IF they're using one.
Yes, but if you're willing (for a given peer) to forgo the certificate,
there is not much to gain by checking it. You're still vulnerable to
MITM attacks. The only benefit is perhaps an audit trail when a
connection happened to be trusted.
For this to work, servers with verifiable certs can elect to not
offer aNULL ciphersuites, at the cost of not observing which clients
are exposed to MITM. Clients will then be able to inspect the server
certificate when provided.
> In my world - those who care about security will want to validate
> client certs (if possible). Though they still might want to
> communicate with those without certs.
Do you mean validate client certs, or validate certs on clients?
The former requires server certs.
> Therefore is it possible to do something like:
>
> try and negotiate a secure connection:
>
> * if client does not present a cert:
> - drop back and use an anon cipher (but take note of this, and
> flag somewhere that this client isn't super secure)
Your questions betray substantial naivete about the TLS protocol,
read a book or some good articles that cover the basics. The words
"super secure" have no technical content. You likely won't understand
this thread until you do some more reading.
Client certificates are not requested by default, and even when
requested are optional, but the server may terminate the handshake
if none are provided. You don't need to fall back to anything. If
you request client certs, you may choose to make them mandatory or
leave them optional.
When a client presents a client certificate, the server can identify
the client using its certificate rather than some other authentication
protocol. In many environments (where clients are users using a
variety of machines without crypto-smartcard readers) client certs
are largely impractical.
> (i.e. it can still communicate using the anon cypher, but it
> wants to know when this happens)
The anon ciphers are about presence or absense of *server* certificates,
client certificates are a separate story, but you can't have client
certs if you don't have server certs.
> OK so for the clients/servers that 'dont care' - they can just
> use the anon cypher from the start.
The TLS handshake *negotiates* a common ciphersuite from the totality
of ciphers (some with certs and some without) available to both client
and server. Of these, either the server's best preferred or (by default)
the client's best preferred cipher is chosen.
Clients that want MITM protection MUST check the server cert trust
chain and peername and MUST NOT accept aNULL ciphers. Clients may
need to present their own certs if the server requests them (OpenSSL
handles the details, just configure the client's cert and key via
appropriate calls before starting the connection).
Servers that want to authenticate clients via certs should request
client certificates (again pre-connection setting). They may choose
to not accept client connections that have no certificate, and should
do something useful with the client certificate (verify trust chain
and extract client name, ...). When a client certificate is valid,
the server can be reasonably confident that there is no MITM unless
the client's private key has been compromised.
Good luck.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
