On Fri, Feb 01, 2013 at 07:22:52PM +0000, Nathan Smyth wrote:
> 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.
By interact, do you mean just initiate connections (be clients) or
also accept connections (be servers)?
> 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.
No. Instead of me telling you what to do, you should be able
to understand what your options are and what are the pros and cons.
- A server may have:
i. a certificate that client's can verify,
ii. a certificate that client's can't verify,
iii. or no certificate at all.
- A client may have:
a. a certificate that server's can verify,
b. a certificate that server's can't verify,
c. or no certificate at all.
- A server may offer aNULL (anonymous) ciphers as well any other
ciphers to clients in cases i) and ii) and MUST offer aNULL
ciphers in case iii). If it offers aNULL ciphers it should
make them preferred offer other ciphers or else they won't
as a rule get used.
- A server can only request client certificates when the
handshake selects a ciphersuite with a server certificate.
- If both client and server enable anonymous ciphersuites and
the preferred ciphersuite is anonymous, the server won't get
a client certificate even if the client falls under cases a) or b),
and the client won't see a server certificate even if the
server falls under cases i) or ii).
- A client MUST offer anonymous ciphersuites to communicate with
any server in case iii).
- A server MUST not require client certificates to communicate with
clients in case c).
- Enabling aNULL on servers makes servers aware of clients that
are willing to establish unauthenticated sessions, and also
enables authentication via non-TLS protocols (e.g. GSSAPI
with channel bindings after the anonymous TLS handshake is
complete).
This may hide certificates from both parties, even when both
have them, provided the client is willing to initiate an
anonymous connection to this server. This is not a problem
if clients have prior configuration about which servers
should be authenticated and which should not.
- When you enable aNULL ciphers you don't need to explicitly
disable other ciphers, they just don't get used if not
preferred or not possible for lack of suitable keys, ...
- The default OpenSSL 1.x cipherlist is equivalent to:
ALL:+RC4:!aNULL:!SSLv2:@STRENGTH
To enable aNULL, we drop the '!aNULL' filter, and add and
delete the aNULL ciphers (thus making them preferred over
other ciphers with the same symmetric key size). I then
also disable EXPORT and LOW:
aNULL:-aNULL:ALL:!EXPORT:!LOW:!SSLv2:@STRENGTH
I generally don't bother with avoiding 128-bit RC4, it has held
up reasonably well.
So you need to decide whether your clients know a-priori which
servers they can always validate and therefore will not offer
aNULL with those servers, will check those server's trust
chains and peer names.
For case ii) servers clients must be willing to accept untrusted
certificates and should offer aNULL unless they have useful client
certificates even to untrusted servers.
For case iii) servers clients MUST offer aNULL and will not be
able to offer their own certificates in return.
Note that the client ceritificate is sent unencrypted during the
handshake, and should not contain sensitive information about the
client. In some instances client certificates are requested during
a re-negotiation at some point after the initial handshake completes,
in this case the client certificate exchange is encrypted.
Understand the options available and choose sensibly.
> In that way, if a process without a cert tries to connect to any
> other process -- the anon cipher will be negotiated + used.
TLS anonymous ciphers support server anonymity rather than client
anonymity, you're still confused. When the server is anonymous,
the client is always also anonymous. However, when the server is
not anonymous, the client may or may not present a certificate,
this is up to the server to request and/or require.
> 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.?
This depends on whether they know this before establishing the connection.
If the client does not know which servers have certificates, it can't
ever avoid MITM attacks, since it is always willing to allow the server
not to have them. At best you get an audit trail that you were lucky
each time a valid certificate was found. The price for this audit
trail is that servers don't know which clients are willing to forgo
secure connections.
> (I suppose there is some priority <perhaps configurable> to
> selecting the cipher that is negotiated??)
You really need to start reading expository and reference documentation.
> After the connection is established, a process can then determine
> what cipher was used,
Generally, not worth it except for logging. However certificate
verification may involve application code depending on how server
and client identities are mapped onto certificate attributes, and
how trusted CAs are managed, ...
> Is that a correct interpretation?
I think it is time to figure this out for yourself.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
