E-Mail clients (such as the built-in Android 4.4.2 E-Mail client) violate the IMAP
STARTTLS
protocol, even if the mail server is properly configured to provide the LOGINDISABLED
option, and proceed to log-in to the server using a plaintext password.
Citing from RFC 2595:
"An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections. An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present."
However, the following is a captured protocol discussion between an Android 4.4.2 E-Mail client and a properly configured IMAP server:
OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready.
- this shows that the server supports STARTTLS
and the server correctly offers LOGINDISABLED
- without even offering LOGIN
!ID ("name" "com.android.email" "os" "android" "os-version" "4.4.2; KOT49H" "vendor" "samsung" "x-android-device-model" "GT-I9195" "x-android-mobile-net-operator" "FRYPAN.COM" "AGUID" "MorenaVZMLQWO2nf2JarJIZ60i3F=")
- the client is an Android 4.4.2 built-in E-Mail client (package name com.android.email
). The client is now identifying to the server.OK ID completed.
- the server accepts the identification.LOGIN username "password"
- now the client just sends a LOGIN
command, regardless whether the RFC 2595 explicitly states that it should not and regardless that the server does not even offer LOGIN
.BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
- the server is shocked and screams that the client's password is now compromised since anybody could have intercepted the plaintext password.
Using tcpdump
, the password can be easily intercepted at any node through which the traffic between the client and the server flows. For instance, by listening on the interface (eth5
) through which the conversation takes place:
tcpdump -vvv -e -n -A -i eth5 port imap
the following password has been grabbed from an Android client at 95.173.136.70
authenticating to 23.206.132.14
on port 143
:
08:55:45.018490 7c:0d:3c:7c:cf:dd > ca:ac:72:cf:94:e4, ethertype IPv4 (0x0800), length 110: (tos 0x0, ttl 63, id 33234, offset 0, flags [DF], proto TCP (6), length 96) 95.173.136.70.4721 > 23.206.132.14.143: Flags [P.], cksum 0xae74 (correct), seq 243:287, ack 338, win 245, options [nop,nop,TS val 21873310 ecr 24724117924], length 44 E..`..@.?....f:..f;..................t..... ........564625 LOGIN username "password"
at which the IMAP server responds (shocked) that plaintext authentication is not allowed without SSL/TLS and that the password has just been compromised by the client:
08:55:45.018491 ca:ac:72:cf:94:e4 > 7c:0d:3c:7c:cf:dd, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 40516, offset 0, flags [DF], proto TCP (6), length 305) 23.206.132.14.143.143 > 95.173.136.70.4721: Flags [P.], cksum 0xfafb (incorrect -> 0x6a5d), seq 338:591, ack 287, win 235, options [nop,nop,TS val 24724117925 ecr 21873311], length 253 E..1.D@.@....f;..f:............B........... ........* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. 564625 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
He, he, told ya to stop using shitty Google products. You get what you pay for.
To mitigate the issue, perhaps it would be best to disallow STARTTLS
through the standard IMAP port 143
and only offer SSL
thorough IMAPs on port 993
. At least this way the client does not automatically assume that, if port 143
is open, then it is an unencrypted connection and attempts to login by sending the plaintext password.
The Android E-Mail client is not to be the only affected product. It seems that an open 143
port is an invitation to E-Mail clients to consider that all traffic should be unencrypted, regardless whether STARTTLS
is enabled, regardless that the LOGINDISABLED
option is sent and even regardless that the IMAP server does not even offer the LOGIN
option!