Subject: Logging plaintext logins? (SSLTYPE=unix -> nopwd transition)

From: Rich Graves <[email-masked]>
Date: Thu, 9 Jan 2003 17:37:11 -0500 (EST)

We are finally going to do the right thing and change from SSLTYPE=unix to
SSLTYPE=nopwd (allow cleartext logins only in encrypted sessions).

We would very much like to identify all users who have ignored our
instructions and will be affected by this change.

It's not clear to me how to do this. Identifying port 993/995 connections
is relatively easy, but the server doesn't seem to log successful STARTTLS
transitions, nor do I see a difference between cleartext AUTH logins and
GSSAPI logins.

I'd be happy to hack the syslog() lines in the source if I could find a 
single or set of global variables that would tell me if the login currently 
being attempted *would* be allowed under SSLTYPE=nopwd conditions.

We are currently running imap-2001.315+security and local patches. Secure
mechanisms we currently support are alternative SSL port, STARTTLS,
AUTH=GSSAPI, and rimapd preauthentication.

I could go to imap-2002 if it would make this easier, but I'm trying to
play nice with future sysadmins by making maximum use of RedHat packages.
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 9 Jan 2003 15:20:05 -0800 (Pacific Standard Time)

> being attempted *would* be allowed under SSLTYPE=nopwd conditions.

If the syslog() says "Login" then the user used the plaintext LOGIN
command.

If the syslog() says "Authenticated" then the user used SASL.  It is a
simple hack to the syslog() in imapd.c (search for "Authenticated user")
to include the SASL mechanism name (which should still be pointed to by
variable "s").

SASL mechanisms LOGIN and PLAIN are plaintext and would not be allowed by
SSLTYPE=nopwd.

> play nice with future sysadmins by making maximum use of RedHat packages.

I think that imap-2002 would make things easier since it has a year of
bugfixes and enhancements over imap-2001.  imap-2002b is being released
later today.  I don't know what RedHat may have changed though.

-- Mark --

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

---

From: Rich Graves <[email-masked]>
Date: Thu, 9 Jan 2003 18:49:47 -0500

> SASL mechanisms LOGIN and PLAIN are plaintext and would not be allowed by

OK, that does most of it. I will log tcp_serverport in the same place
(993/995 are ssl) so my log parser doesn't have to be stateful.

How would I know if a client on 143/110 has negotiated STARTTLS, though?
There shouldn't be many of these because up until very recently we were
running under a inetd/tcpd setup that breaks STARTTLS (as mentioned in the
FAQ), but it'd be nice to know.

> later today.  I don't know what RedHat may have changed though.

RedHat is actually changing very little nowadays, and only one of their
patches is clearly wrong (lockEaccesError = NIL, which doesn't affect us).

I guess I'm more concerned with how bugfixes might interact poorly with
inherited client or server bugs. Fixes to locale could theoretically break
access to saved mailboxes in non-us locales, for exapmple.

Anyway, at 2001.315 plus bodystructure-extension and \015 overflow patches
we seem to be 2 builds ahead of your own deskmail server... :-)

---

From: Mark Crispin <[email-masked]>
Date: Thu, 9 Jan 2003 16:00:52 -0800 (Pacific Standard Time)

> FAQ), but it'd be nice to know.

Well, you could add a log when STARTTLS is negotiated...

> patches is clearly wrong (lockEaccesError = NIL, which doesn't affect us).

Sheesh, are they still doing that?  No wonder I am getting these
occasional reports of corrupted mail from RedHat users.

> access to saved mailboxes in non-us locales, for exapmple.

We would not be doing any local hacking in the IMAP toolkit.  It has its
own i18n facilities.

> we seem to be 2 builds ahead of your own deskmail server... :-)

I don't directly have anything to do with deskmail.  Supposedly, they are
going to update their system.  What is this "\015 overflow patch" that
you're talking about?

-- Mark --