Date: Sun, 14 Jul 2002 01:17:46 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: ticso@cicely.de Cc: Gregory Neil Shapiro <gshapiro@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Mail subsystem defaults, adding authentication. Message-ID: <3D3133AA.8387DA1E@mindspring.com> References: <20020713034725.GB47677@ussenterprise.ufp.org> <3D2FAFB2.E2E9CF36@mindspring.com> <20020713045704.GA49379@ussenterprise.ufp.org> <3D300FD4.7479A8E5@mindspring.com> <15664.47827.844708.151118@monkeyboy.gshapiro.net> <3D30C4DA.22A255A8@mindspring.com> <20020714073559.GY63545@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote: > > IMO, this is broken. Here's why: Implementation of SSL in the > > kernel is a foregone conclusion. It is a matter of "when", not > > "if", due to work like that of Sam Leffler's recent porting of > > the OpenBSD crypto hardware interface framework to FreeBSD. > > > > Basically, asking for conversion of a socket from one type to > > another is not something that will necessarily be supportable. > > With SSL you still do a normal socket connect anyway and than > call SSL_connect/accept on the already existing connection. > What's the matter with exchanging packets before doing that? > Does that mean that the SSL API changes? Yes; it becomes something like: s = socket( PF_INET, SOCK_SSL, 0); bzero(&sa, sizeof(struct sockaddr_ssl)); sa.sin_family = PF_INET; sa.sin_port = htons( 465); /* SMTPS */ sa.sin_cert = &cert; /* Local Cert. */ connect( s, (struct sockaddr *)&sa, sizeof(struct sockaddr_ssl)); > I'm not a cryptographic expert, but I wouldn't prefer a packet > encryption over a stream encryption. The bloat in the IPSEC case is because of the KAME integration; the IPSEC in IPv4 eats a context structure, even if it's not used. The IPv6 code is better. I took it to be a political statement on IPv4 by the KAME people. 8-). The support being in the kernel instead of user space doesn't make it other than a stream encryption, though. > With STARTTLS you can probe for SSL in MTA - MTA comunications. > MTAs connect foreign SMTP servers and want to prefer SSL. > It's unpractical to try a connect to smpts port first with all those > blackhole firewalls out there. Meaning that it won't reject the initial packet, you will have to time out the connection, and then retry on port 25? Actually, you can use non-blocking I/O, simultaneously connect, and then drop whiever one doesn't pan out, or you could cache the result, or you etc.. could make it a mailer flag (e.g. "mailer smtps has flag 'Q' and uses port 465"), and control it on a peer basis. It's not really for trusted host communications anyway, since the only reason we're eating the encruption overhead is to secure a plaintext password; the that rest of the session is also encrypted is actually annoying overhead, in most cases. > The only downside with STARTTLS is that it makes it allmost impossible > to use external SSL boxes. That's a very big downside. OpenSSL does maybe 200 if you have a fas box, and you eat the whole thing doing crypto. Not worth doing onboard the box itself, if you can possibly avoid it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D3133AA.8387DA1E>