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.
