Disallow cleartext on the wire

[jonr at destar.net]

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