Re: Problem while trying to implement TLS

[Bob]

[EMAIL PROTECTED] wrote:

On Thu, 12 May 2005, John Peacock wrote:

Charlie Brady wrote:

Not relevant to your I/O problems, but this is not yet a full implementation of starttls. You'll need to discard any data from before the switch to tls (helo host, from/rcpto, authentication state). IOW, an implicit rset, I think.

In qpsmtpd as distributed, it ought to be all the same info
except taking out STARTTLS. Custom implementations
are allowed to change anything as long as they take out
STARTTLS from the re-advertisement in tls mode.

The other thing I'd like to know before any TLS patch gets committed: how do most MTA's respond to self-signed certs, since most people don't expect to pay NetSol/Thawte/etc. for a server cert for each of their MX servers. And if self-signed certs are acceptable, it would be a very good idea to document how to generate a cert (or even provide a script). I do it often enough that the command is still in my shell history (!), but I suspect most people would be lost without any hints...

You'd have to do it with hooks for TLS so that you can enforce signed certs with a plugin, or make TLS mandatory for some senders/recipient combinations.

John Peacock gave me a link to the starttls rfc.
http://www.faqs.org/rfcs/rfc2487.html

As far as starttls on port 25, the server cannot EVER require
tls, according to rfc(unless an internal relay), but once a client
requests tls, anything goes for a custom(write it yourself) server
configuration (can require client cert etc).

Leaving that to site admins, qpsmtpd ought to only go as far as
advertising STARTTLS, set up transparent tls, issue the new
capability advertisement which rfc requires have the starttls taken
out, then if we were using IO::Socket::[family] everything else
works as usual, tls is transparent.

In the new advertisement, anything is allowed to be changed, including
hostname and protocols.

We definitely don't need to deal in the server with how long
it is until certs expire or if the cert has the correct server
name etc or has been revoked. A client could do that(in a
queue plugin qp may be the client relay and do that, check
rcl, date, CA etc, re-use osca perl code for that or leave it
to site admins--tls works fine with expired certs).

Since tls is only wrapping one connection, that ought to satisfy
the suggestion about "auto-vivification".

Always enforce "no export crap", as cyrus docs phrase it--
'SSL_cipher_list' =>
 'TLSv1:SSLv3:SSLv2:!NULL:!EXPORT:!LOW:@STRENGTH'
...it is otherwise possible for a tls connection to be accepted
to use "null encryption".

-Bob Dodds

Here's how we could set up arg% server side for qp's
&start_tls().

sub start_tls {

....whoami..my $config=.....#?

my $as_server = $config->('me') . ":smtp" ;
my %arg =
   ( 'SSL_server'    => $as_server ,
     'SSL_key_file'  => 'certs/key.pem' ,
     'SSL_cert_file' => 'certs/cert.pem' ,
     'SSL_ca_file'   => 'certs/cacert.pem' ,
     'SSL_ca_path'   => 'CA/' ,
     'SSL_use_cert'  => $as_server ,
     'SSL_version'   => 'tlsv1' ,
     'SSL_verify_callback' => 0 ,
     'SSL_cipher_list' =>
       'TLSv1:SSLv3:SSLv2:!NULL:!EXPORT:!LOW:@STRENGTH' ) ;

use IO::Socket::SSL ;

IO::Socket::SSL->context_init( %arg ) ;

# converting old $sock and old $sock_class
my $sock_class = ref ( $sock ) ;

return ( "something useful" )
if IO::Socket::SSL->start_SSL( $sock_class , $sock , %arg ) ;

 my $err = $@;

# if fell through to here, no tls, revert to non-tls--not even sure
# if we should test, maybe just assume failure if not returned
 if ($sock_class ne ref($sock)) {
   $err = $sock->errstr;
   bless $sock, $sock_class ;
 }
}