On Tue, Oct 02, 2007 at 07:16:19PM +0200, Andreas Hellstr?m wrote:

> Thanks for answering. The ADH ciphers is a little above my head right
> now though. ;-)

That means that what you are trying to do is beyond your present ability
to understand, security is about threat models and mitigations, and SSL
is a security toolkit, so you must start with a threat-model and mitigate
the important threats. Encryption without authentication only addresses
those attacks in which the traffic arrives at the right unmolested, but
may have been passively intercepted in transit (wiretap, SIGINT, ...).

The ADH ciphers support certificateless unauthenticated encryption,
plug and play. All you need to do is tell both client and server to
enable anonymous ciphers. If the server software wants a cert anyway,
just give a self-signed cert that it won't end up using. In some cases it
may be possible to tell the server software that there is no cert, and ADH
ciphers are all that's available. Depends on how the server is written.

> As for the approach I'm sketching, I was under the impression that SSL
> could function as easy as that, where the server has got a self-signed
> certificate with a public and secret key, and then whatever client,
> with a certificate on their own, could connect to the server with SSL
> and get an encrypted connection. Am I wrong?

No, you can also give the server a cert, use ciphers that perform
pointless RSA ops to sign the key exchange and then have the client
ignore the signature. This may be easier to configure, but it ADH is
likely more efficient if client/server support configurable cipherlists.

> At the server side I don't care that any client can connect. Whoever
> connects still has to supply a username/password that is matched with
> a back-end database to grant them access to the service.

Fine, but the client does not know that it is disclosing its password
to the right server. When PSK becomes available with 0.9.9, you may want
to consider using it instead.

> As for the client side, all servers will reside within our network,
> and the clients will connect to our IP-numbers (not domain names).
> Either they trust us when we hand them an IP to connect to, or they
> don't.

There are redirection attacks on switched networks that can steal the
server IP. Most security breaches are inside jobs. Yes, the frequency
of attacks from inside is lower than from outside, but the severity is
often higher.

Why do you need SSL anyway? If your network is secure, why encrypt?
If traffic can be diverted, why not authenticate?

-- 
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to