Disallow cleartext on the wire

[Lucas Zinato Carraro]

RFC2595 -  not recommended IMAPs, but I disagree in some points.


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.

..............................

       - 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.


 But many clients has option to confirm if  server certificate is correct.


         - 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.


 Again,   many clients has option to confirm if  connection is  secure.
 Use of SSL with a 40-bit key  can be used with other connections too.
 I do'nt see a serious provider implementing this.


         - 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.

Clients implement several methods and not only one or two.
I do'nt see any modern mail client that not implement "imaps"
but i see clients that not implement 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.

But IMAPs and SMTPs use only 2 ports.



Zinato







On Mon, Jan 10, 2011 at 9:08 PM,  <jonr at destar.net> wrote:
> Quoting Bron Gondwana <brong at fastmail.fm>:
>
>> On Mon, Jan 10, 2011 at 11:22:51AM -0600, Dan White wrote:
>>> On 10/01/11 23:32 +1100, Bron Gondwana wrote:
>>> >On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote:
>>> >>On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote:
>>> >>> >I am using Thunderbird to test with. I want completely disallow logins
>>> >>> >without TLS for IMAP.
>>> >>> Have a look at /etc/cyrus.conf:
>>> >>>
>>> >>> Just hash out imap and restart cyrus.
>>> >>
>>> >>Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL.
>>> >>Secure IMAP (IMAP w/TLS) still uses TCP/143.   IMAP-over-SSL is rather
>>> >>hackish.
>>> >
>>> >What war are you trying to win here?  Stopping people using plaintext
>>> >connections, or stopping passwords being potentially exposed to snoopers?
>>> >
>>> >Because "Secure IMAP" on port 143 just means that once the user has sent
>>> >their plaintext password over the wire already, you tell them to get lost
>>> >rather than let them in.  It doesn't stop stupid client programs sending
>>> >the plaintext password out in the first place.
>>>
>>> That was addressed in RFC 3501, section 7.2.1 and presumably why the
>>> LOGINDISBLED response was created.
>>>
>>> If there are any imap clients that send over-the-wire cleartext passwords
>>> when server policy forbids it, then that would be grounds for a CVE report
>>> on that client.
>>>
>>> Running IMAP over 143 should be safe from over the wire snooping, if the
>>> server is properly configured.
>>
>> Yeah, that's what's known as "wishful thinking" I suspect.  Has anyone
>> actually done any testing on this?
>>
>>> >IMAP-over-SSL does, because no client sends the password over the network
>>> >until it has a TCP connection - and it doesn't get one of them if it tries
>>> >to connect to port 143 and you don't have it turned on.
>>> >
>>> >So what's so hackish about IMAP-over-SSL precisely?
>>>
>>> RFC 2595 discourages it and lists some reasons.
>>
>> Sorry, I don't buy any of those reasons.  "The server may be using a low
>> grade cipher" - so layer a better one inside, or don't use such an ancient
>> server.  I think that's a past artifact.  The "Secure vs Non-Secure" client
>> interface issues is a boat that's sailed sorry.  Besides more clients are
>> auto-configuring anyway (see Thunderbird's ability to query a URL to get
>> configuration parameters) - or just probing both ports one-off and selecting
>> the SSL one if available.
>>
>> Port numbers are a limited resource - ok, I'll credit that one - but the fact
>> is that you can't really take them back now.  They're in use widely enough
>> that it's not going to change any time soon.
>>
>> Sorry - there's wishful thinking, and there's the reality - and the reality
>> is that enabling just port 993 is safe against poor implementation in the way
>> that hoping everyone checked for "LOGINDISABLED" isn't.
>>
>
> So are you saying that because a MUA might not check for LOGINDISABLED
> and send the password anyway that if I want secure authentication then
> only use ports 465, 993 and 995?
>
> So because a MUA might not honor the LOGINDISABLED that using TLS on
> ports 25,110 and 143 is not a good idea?
>
> Jon
>
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>