Educause Security Discussion mailing list archives
Re: Blocking POP3 and IMAP
From: Shumon Huque <shuque () ISC UPENN EDU>
Date: Thu, 11 Oct 2007 15:25:24 -0400
On Thu, Oct 11, 2007 at 01:33:27PM -0500, Ken Connelly wrote:
We allow POP and IMAP, but require that they be the secure implementations of each. Those run on TCP/995 and TCP/993 by default. We try very hard to eliminate any plain-text authentication scheme, including within our on-campus, switched network. -ken
It is worth noting that the recommended way to support SSL/TLS for these applications (and generally any application) is not to use an alternate port, but to make use of the STARTTLS extension on the standard ports (143, 110 etc). It is possible to configure servers to allow plaintext mechanisms only after STARTTLS has been successfully negotiated. Here's what RFC 2595 ( "Using TLS with IMAP, POP3 and ACAP" http://www.ietf.org/rfc/rfc2595.txt ) has to say about this: --Shumon. Excerpt: 7. imaps and pop3s ports Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands. A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems. - Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like "click here if your browser supports SSL." This is a decision the browser is often more capable of making than the user. - Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the "secure" port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. - Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS. - Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption.
Current thread:
- Blocking POP3 and IMAP Hammon, Gary (Oct 11)
- <Possible follow-ups>
- Re: Blocking POP3 and IMAP Ken Connelly (Oct 11)
- Re: Blocking POP3 and IMAP Pace, Guy (Oct 11)
- Re: Blocking POP3 and IMAP Alex Everett (Oct 11)
- Re: Blocking POP3 and IMAP Michael Sinatra (Oct 11)
- Re: Blocking POP3 and IMAP Michael Sinatra (Oct 11)
- Re: Blocking POP3 and IMAP Valdis Kletnieks (Oct 11)
- Re: Blocking POP3 and IMAP Geoff Nathan (Oct 11)
- Re: Blocking POP3 and IMAP Harry E Flowers (flowers) (Oct 11)
- Re: Blocking POP3 and IMAP Shumon Huque (Oct 11)
- Re: Blocking POP3 and IMAP Paul Russell (Oct 11)
- Re: Blocking POP3 and IMAP Mike Iglesias (Oct 11)
- Re: Blocking POP3 and IMAP Geoff Nathan (Oct 11)
- Re: Blocking POP3 and IMAP Michael Sinatra (Oct 11)
- Re: Blocking POP3 and IMAP ssgsa (Oct 17)