Buggy IMAP authentication on Nokia 6233

I bought a Nokia 6233 yesterday, because I lost my Nokia N80 a few days ago. One of its important features besides 3G and Bluetooth, for me, is the ability to read e-mail. Unfortunately, the devices has some serious problems with non-cleartext authentication in IMAP. What is strange is that SMTP authentication using CRAM-MD5 and DIGEST-MD5 works fine. Actually, there is more strangeness to it than this…

My first attempt was to enable SSL. First, this means SSL over port 993 and not STARTTLS on port 143. Attempting the download fails with a general purpose error, but the server logs gave me some hints:

cyrus/imapd[18687]: imaps TLS negotiation failed
cyrus/imapd[18687]: Fatal error: tls_start_servertls() failed

I tried to add the CA certificate for my server to the phone’s CA store. This can be done by using the built-in web browser and retrieving a DER encoded version of the certificate. A PEM encoded certificate does not work (it says the certificate “contains an error”). The server messages now became:

cyrus/imapd[19203]: starttls: TLSv1 with cipher RC4-MD5 (128/128 bits new) no authentication

One can question Nokia’s wisdom of using RC4-MD5, but that is another story. However, the error message on the phone remains the same. There is no indication that the phone attempts to authentication to the server inside the successfully negotiated TLS session. My theory is that the phone expects “SSL” to mean authentication with client-side certificates, but I have not tried to import a client-side certificate into the phone. I gave up on SSL at this point.

I disabled SSL and selected CRAM-MD5. The server logs are fine, but the phone error messages remains. The server logs contains:

cyrus/imapd[22402]: login: [1.2.3.4] jas CRAM-MD5 User logged in

That actually means the phone successfully authenticated! However, using tcpdump on the server, I can see the following exchange:

server: * OK yxa-iv Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1+sarge2 server ready
client: A0 AUTHENTICATE CRAM-MD5
server: + ...
client: ...
server: A0 OK Success (no protection)
client: \r\n
server: * BAD Invalid tag
[20 seconds delay]
client: A1 NOOP
server: A1 OK Completed
client: A2 EXPUNGE
server: A2 BAD Please select a mailbox first
client: A3 CLOSE
server: A3 BAD Please select a mailbox first
client: A4 LOGOUT
server: * BYE LOGOUT received

The conclusion is that the 6233 sends a spurious rn and interprete the error message as an authentication error.

I tried DIGEST-MD5 instead, but the error message on the phone was the same. Sniffing the network traffic reveals that authentication works, and the phone does not send the spurious \r\n.

server: * OK yxa-iv Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1+sarge2 server ready
client: A0 AUTHENTICATE DIGEST-MD5
server: + ...
client: ...
server: + ...
client:
server: A0 OK Success (no protection)
client: A1 NOOP
server: A1 OK Completed
client: A2 EXPUNGE
server: A2 BAD Please select a mailbox first
client: A3 CLOSE
server: A3 BAD Please select a mailbox first
client: A4 LOGOUT
server: * BYE LOGOUT received
client: A4 OK Completed

This time there is no 20s delay. The whole transaction was done under 2s. The error message on the phone remains though.

At this point, I gave up and tried clear-text authentication just to see what would happen. PLAIN did not work, since my server correctly requires TLS. LOGIN did not work, because my server doesn’t support this non-standard SASL mechanism. If I disabled secure login, it would use the plain IMAP LOGIN command, and things would work.

For completeness, here is what happened if I selected ‘Automatic’. It appears to try DIGEST-MD5 first, CRAM-MD5 then, and then resort to LOGIN. There is no 20s delay here either, the entire transaction is again done under 2s. The error is that it fails to notice successes.

server: * OK yxa-iv Cyrus IMAP4 v2.1.18-IPv6-Debian-2.1.18-1+sarge2 server ready
client: A0 CAPABILITY
server: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ANNOTATEMORE
server: A0 OK Completed
client: A1 AUTHENTICATE DIGEST-MD5
server: + ...
client: ...
server: + ...
client: 
server: A1 OK Success (no protection)
client: A2 AUTHENTICATE CRAM-MD5
server: A2 BAD Already authenticated
client: A3 LOGIN "..." "..."
server: A3 BAD Already logged in
client: A4 NOOP
server: A4 OK Completed
client: A5 EXPUNGE
server: A5 BAD Please select a mailbox first
client: A6 CLOSE
server: A6 BAD Please select a mailbox first
client: A7 LOGOUT
server: * BYE LOGOUT received

Cleartext passwords over wireless links is not acceptable. I urge Nokia to release a new firmware for the 6233 that fixes this bug. For the record, my firmware (according to *#0000#) is V 05.10 released 21-12-06.

11 Replies to “Buggy IMAP authentication on Nokia 6233”

  1. Hi, I was thinking about bying a Nokia N80. What do you think about it? And why I found this can it use IMAP over SSL?

  2. The N80 support IMAP over SSL, and it worked fine. Although I never managed to import third-party CA certificates (which actually do work on the 6233), so I always got a warning about an untrusted server certificate.

    I did find the N80 (series60) to be much slower than the 6233 (series40) though, and I found that I rarely used its WLAN feature. WLAN is pretty much the only important thing the N80 has that the 6233 doesn’t, at least for me. I used the N80 for about 10 months.

  3. Yeah, I hit this bug too with the 6300 model. Same tcpdump logs, also with Cyrus on MacOSX Server 10.4.
    SMTP authentication works.

    I’d like to know how you’ve made tcpdump to display nicely decoded logs. My knowledge on tcpdump must be limited (so I have to watch all the low-level stuff).

    All in all, Nokia must fix this.

  4. i;ve had imap problems with a 6234 a vodafone variant of the 6233:

    i’m happy to use it with plain login. not too bothered about that security.

    My problem was that it took ages and the call log showed it was transfering 10k of extra data.

    If there was no mail it would check just fine, but if there was mail it would take an age and the call log would show it had transfered 100k plus the appropriate ammount, so around 103k. bizarre.

  5. Exactly the same problems with my 6233 here.
    Is there a Nokia-software update yet available that fixes this issue?

  6. I no longer have the 6233 so I don’t know whether there are any updates. The firmware version I used is mentioned in the initial post, maybe you could compare that with whatever latest release Nokia has?

    FWIW, I never found a solution to this problem.

  7. Tried to send it to my Nokia 6233 using IR and I changed the mime-type for .cer files to application/x-x509-ca-cert on my webserver but the x509/DER converted file is neither way recognized.
    .cer Files from ‘official’ CA’s are properly recognised when accessing their .cer page using the Nokia-browser – and they’re using the same mime-header.
    I’m getting a bit annoyed here…

  8. I recall certificate troubles as well, and I now have a *.crt file on my web server which may have been due to Nokia.. could you see if the filename matters?

    Also, I think I also transferred the file to the file system on the phone and installed it by browsing the file system.

    Of course, I no longer have the 6233 so these are just my vague memories.

    It may be that client certificates work, but I never tried that.

  9. You’re right. The 6233 needs the .crt extension indeed. The phone displays the settings in your certificate correctly when fetched from a webserver with adequate MIME-settings. But when saving the file it states “Error safetymodule”. Bleep. Apparently you need to ‘insert a secutity module’ before you can add any non-default usercertificates.
    I have a wildcard in my FQDN that may cause the hickup; I’m not planning to change that so no SSL for me & my Nokia 6233.

  10. Just ran into a similar thing.
    My IMAP setup doesn’t support anything besides PLAIN and LOGIN and I haven’t tried SSL yet because of the certificate issue.
    So anyway AUTH=LOGIN doesn’t work either. The phone tries to “select inbox” even before the server confirmed the login what just yields to the fact that “select inbox” is ignored and the phone thinks it got no data.
    The only thing that works for me is plain auth what is annoying.

Leave a Reply to Peter Cancel reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.