Subject: more SSL support?

From: "Abraham Backus" <[email-masked]>
Date: Tue, 10 Jun 2003 13:38:20 -0700

Hello,

Has there been any consideration for adding functionality such as peer verification and other customizations that can be passed to openssl?

For instance, I'd like to be able to provide a file containing a set of trusted certificate authorities and enable peer verification.  (See openssl docs for SSL_CTX_load_verify_locations and SSL_CTX_set_verify).  Also, I'd like to be able to control which SSL versions are used, particularly enabling SSLv3 and TLSv1, while disabling SSLv2 (passing SSL_OP_NO_SSLv2 to SSL_CTX_set_options).  A couple of other options that I'd like to control is SSL_CTX_set_cipher_list (disabling lower quality ciphers, etc.) and the data passed to RAND_seed.  After reading Oreilly's "Network Security with OpenSSL" book a few months back, I've gained a better warm fuzzy by using "stunnel" and similar products that allow control of these options, but I'd like to take away as much of these indirections as possible.

If it's a matter of time or resources and you don't mind, I could spend some time on it and contribute a patch, which I might work on anyway for my own use :)

thanks!
-Abe

---

From: Mark Crispin <[email-masked]>
Date: Tue, 10 Jun 2003 14:32:14 -0700 (Pacific Daylight Time)

On Tue, 10 Jun 2003, Abraham Backus wrote:
> For instance, I'd like to be able to provide a file containing a set of
> trusted certificate authorities and enable peer verification.  (See
> openssl docs for SSL_CTX_load_verify_locations and SSL_CTX_set_verify).

Why not just install any added CAs in /usr/local/ssl/certs?  Isn't it
better to have the CAs set up properly for all applications?

Also, are you intending to add a SASL authenticator for EXTERNAL?  If not,
then what does peer verification buy you, given that there is already
authentication in IMAP (in effect, you'll be authenticating twice)?
Aren't you worried about not being able to access your mail from
elsewhere?

> Also, I'd like to be able to control which SSL versions are used,
> particularly enabling SSLv3 and TLSv1, while disabling SSLv2 (passing
> SSL_OP_NO_SSLv2 to SSL_CTX_set_options).

Not a good idea, and likely to cause interoperability problems.  On the
SSL port (port 993 in IMAP), you need to use the SSLv23 method and not
TLSv1.  On TLS (STARTTLS command on the regular ports), you need to use
TLSv1 and not the SSL methods.

I hope I've talk you out of doing this.

> A couple of other options that
> I'd like to control is SSL_CTX_set_cipher_list (disabling lower quality
> ciphers, etc.)

This is alright, provided that you do NOT disable the
TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite (this is mandatory).  You also
should NOT disable the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher
suite.

All other suites are optional.

The only reason why I haven't disabled them is that cypher suites seem to
go in and out of fashion on a regular enough basis that I'm leery in
getting into the business of deciding what to use.  If, for example, I had
disabled all but TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (which was once the
sole mandatory suite), all software builts using that source code would be
broken today now that TLS_RSA_WITH_RC4_128_MD5 is the mandatory suite.

Unless there is evidence of penetrations, it may well be more costly to
get into that business than just leaving well (bad?) enough alone.

It's reported that crypto cracking isn't even a blip on the radar screen
in terms of systems being broken into.  The big name cracks are in
exploiting known bugs and human error.

But, as long as you don't disable the mandatory suite (and the previous
mandatory suite), this ought to be harmless.  I have to prevaricate,
because I've never tried it.

> and the data passed to RAND_seed.

What operating system are you using?  If your system has /dev/urandom
(e.g. most Linux systems), then RAND_seed() is not called (and is not
necessary to call).

I'll admit that the data supplied to RAND_seed() for systems that don't
have /dev/urandom isn't NSA-quality, but I haven't heard of anyone being
cracked because of it either.

Nevertheless, this is harmless; so if you really want to do this don't let
me talk you out of it.  You might make things better.

> After reading
> Oreilly's "Network Security with OpenSSL" book a few months back, I've
> gained a better warm fuzzy by using "stunnel" and similar products that
> allow control of these options, but I'd like to take away as much of
> these indirections as possible.

An important part of any security measures is a good threat assessment.
You won't score a net gain if, by being extreme on crypto, you create
vulnerabilities in user behavior.

>From a threat-assessment point of view, I have a difficult time in giving
credibility to the notion that bad guys are going to attack the crypto, as
opposed to much easier and less costly attacks.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Abraham Backus" <[email-masked]>
Date: Tue, 10 Jun 2003 15:09:16 -0700

Mark,

Thanks a lot for the response and your time.

> better to have the CAs set up properly for all applications?

After reading the code more, I discovered that most (if not all) of this is
already available and that I should probably learn more about manipulating
the NET_NOVALIDATECERT flag and how to make c-client/imapd do what I want it
to (only allow connections that use certificates issued by a private CA).
My query was largely based on some documentation available that doesn't
mention verification/validation.

> exploiting known bugs and human error.

I'm just really really paranoid  There is only a limited set of external
sites from where I would like to connect to my server and I'm just learning
how to explicitly disallow all connections except those from specific
addresses by using linux's iptables service.  By using peer verification, it
gives me another level of restriction, in case someone finds a way to use ip
spoofing to connect.  This is probably overkill for my scenario and I don't
know too much about the statistics and probability for intrusions.  In any
case, it looks like I can use existing functionality that is already built
into c-client and be as paranoid as I want to.

> TLSv1 and not the SSL methods.

I think that SSLv23 also enables TLSv1, then setting the SSL_OP_NO_SSLv2
flag disables SSLv2.  In the code, SSL_OP_ALL is set, which probably sets
this option, so I'm not really worried about this anymore either.

> I hope I've talk you out of doing this.

Yep, you and the code have talked me out of it.

Please accept my apologies for not reading the code more before sending a
query, and thanks again! :)

-Abe

---

From: Mark Crispin <[email-masked]>
Date: Tue, 10 Jun 2003 16:10:05 -0700 (Pacific Daylight Time)

> to (only allow connections that use certificates issued by a private CA).

NET_NOVALIDATECERT is an internal flag used by the low-level net_open()
call, reflecting the /novalidate-cert switch in the specification used in
the name in the higher-level call.

It doesn't stipulate "only validate certificates issued by a private CA".

But, if this is a system you manage, why not just install only your
private CA certs on /usr/local/ssl/certs and not the regular certs?

> mention verification/validation.

I think the issue of validation was mentioned in the release notes.

> This is probably overkill for my scenario

I think that you hit the nail on the head.  IMHO, you'd be better off
using physical isolation, e.g. having clients and servers on a private
network (possibly with a NAT box to the outside world).

One of the dangers of being overly paranoid is if the day comes that you
may have to crack your own network to get in...

> flag disables SSLv2.

I am pretty sure that SSLv23 does not allow TLSv1.  Or at least it doesn't
in one of the combinations.  In any case, TLSv1 is only to be used with
the STARTTLS command.

-- Mark --