Date: Sun, 14 Jul 2002 12:01:08 +0200 From: Bernd Walter <ticso@cicely5.cicely.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: ticso@cicely.de, Gregory Neil Shapiro <gshapiro@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Mail subsystem defaults, adding authentication. Message-ID: <20020714100108.GA63545@cicely5.cicely.de> In-Reply-To: <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> <3D3133AA.8387DA1E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 14, 2002 at 01:17:46AM -0700, Terry Lambert wrote: > 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)); Now I understand what you mean with "socket type conversion". Mmm - That way I can't have a different SSLcontext on incoming connects? Currently I do it after accept, but before I only have the listen descriptor and if accept already does the SSL handshake... Not that it's an important thing to me - I just wonder. > > 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. Maybe I should spend more time into IPSEC. > > 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. OK - that's both possible. > 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. But it's a nice to have feature. It brings encryption of the whole session together with certificates. Certificates are great to deliver safly to dynamic IPs. Together with ETRN this was the first real option to replace rmail only UUCP nodes with SMTP - asuming that IP is available. > > 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. I never saw this as a big point as it was forseeable that one day you can just plug in a crypto card directly in each border mailhost :) -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?20020714100108.GA63545>