Confused about email security in the P800

I beleave it support both.. but I could be wrong.

frankly, I'm getting quite tired of this crap...
I cannot find anything about this "Secure connection" setting when setting up a mail account in the p800. Not inte the manual, not on the internet. I've tried every possible combination when it comes to this option and a imap server (SSL, TLS etc etc).. and nothing works... only thing that works is when I don't use any encryption at all, i.e a "normal" imap connection.
If you have the option, print in the darn manual exactly what it does.. damnit..

any progress on this issue? i cant get the "secure" connection to even be a checkable item in the email settings.. SMTP auth seems to work though, which is good.

I might be wrong, but what the manual is imlpying is that it's up to your network or ISP to secure and encrypt you data, not up to your unit. It is the same thing with home computers. Your Emails are as secure as your ISP makes them. Otherwise you would have to send or share a specific encryption code with the recipient, and unless oyu work for the CIA that is not very practical.

So, call your provider and ask them about the security meassures they take and how they would apply to oyur phone.

As an example. When you use your Credit Card online and a notice comes out saying connection is now secured...That is not your computer! and yes, it also means that up to that point your connection was public.

Wether using a laptop ar a phone anybody with an anthena and the right software can pick up your signals. Believe me! there is an actual market and people waking around cicies picking up signals. As a rule, never broadcast through radio frequencies any sensitive information, because until your provider gets it it is not secure.

what are you talking about? this has nothing to do with carriers, isps, etc. this is a transport issue end-to-end.

this is pretty simple actually:

IMAP supports using SSL. Pure and simple. On port 993 versus port 143. The P800 has a check box for secure connections. If you select secure connections, and say do NOT adjust the port.. the P800 returns an error message saying "Secure connections not available on this server" which means to me that it is smart enough to recognize a lack of SSL.. because when I adjust to port 993 for my server (which is running IMAP/SSL on port 993) it doesn't give that error message.. BUT it doesn't connect for some reason. I looked at my router, and I can see the P800 is trying to connect to port 993.. so something is broken on the P800s implementation of Secure IMAP. I've contacted SE, but no reply on this issue.

Anyone gotten SSL email either IMAP or Pop working?

Rob

[quote="rob"]what are you talking about? this has nothing to do with carriers, isps, etc. this is a transport issue end-to-end.

...
Anyone gotten SSL email either IMAP or Pop working?
Rob[/quote]
I've got mail sending over SSL-enabled SMTP working. Even more: It was with userid/password authentication. Apparently SMTP can accept either plain or SSL links on the same port 25.
Maybe that's how IMAP should be set-up on the mail server: Listen to both plain and SSL on port 143. Like you, I couldn't connect on port 993.

Martin

[quote="Anonymous"][quote="rob"]what are you talking about? this has nothing to do with carriers, isps, etc. this is a transport issue end-to-end.

...
Anyone gotten SSL email either IMAP or Pop working?
Rob[/quote]
I've got mail sending over SSL-enabled SMTP working. Even more: It was with userid/password authentication. Apparently SMTP can accept either plain or SSL links on the same port 25.
Maybe that's how IMAP should be set-up on the mail server: Listen to both plain and SSL on port 143. Like you, I couldn't connect on port 993.

Martin[/quote]

Secure SMTP will work if the mail server supports the STARTTLS command, which most ones do.
However, the IMAP and POP3 security settings on the P800 got me totally baffled. I don't know what kind of pseudo security commands it tries to use, but the equivalent of STARTTLS for POP3 and IMAP isn't standard, nor have I seen it in any IMAP or POP3 server. An IMAP client wishing to use SSL should connect to an SSL port (993 standard) and nothing else...
I would really like to know what SE is trying to achieve here.

So tired...

well, if their IMAP would work w/SSL on port 143, it should work on port 993 stnd right? for my imap server im using nt40, so i cant bind an SSL to the same port as regular imap in this instance.. only for my SMTP which is running on linux. regardless, i dont think thatll fix the problem.

im totally perplexed by this & really need a solution since sending clear text passwords isnt in the game plan for me. ill play around with it a bit more this week & see if i can sniff the packets.

im amazed that nobody @ se can shed any light on this.. very disturbing.

rob

okay, after playing around some more, ive determined that the p800 isnt trying to use SSL over IMAP but IS trying to use TLS commands through IMAP.. here:

02/14/2003 01:06:29.277 (TID:3f): IMAP connection accepted from 216.155.166.101
02/14/2003 01:06:29.277 >>> (TID:3f): * OK Microsoft Exchange IMAP4rev1 server version 5.5.2653.23 (hostxxx.xxx.com) ready
02/14/2003 01:06:30.219 <<< (TID:3f): 1 CAPABILITY
02/14/2003 01:06:30.219 >>> (TID:3f): * CAPABILITY IMAP4 IMAP4rev1 IDLE LITERAL+ LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE
02/14/2003 01:06:30.219 >>> (TID:3f): 1 OK CAPABILITY completed.
02/14/2003 01:06:31.120 (TID:3f): IMAP connection to 216.155.166.101 lost

the capability command is the first step in setting up a TLS session. when the p800 doesn't get back: STARTTLS as an available capability, it bails out.

so.. im pretty much hosed on my end, since my msft crap doesnt support TLS yet. good luck to you guys.. at least i know where the problem is now.

rob

after 2 packs of cigarettes/4 pots of coffee.. i finally got this damn thing working:

first, if your IMAP server isnt capable of handling STARTTLS commands (such as mine), then you need to setup a proxy. if your IMAP can handle STARTTLS, then you shouldn't even be reading this 😊

go to: www.delegate.org. download the source code for this amazing package. if you dont have openssl, get that tar ball as well. you'll need it.

follow the instructions for sslway install on the delegate web page. the ONLY change you need to do is you need to hack sslway.c and change the capability response from: "* CAPABILITY STARTTLS" to "*CAPABILITY IMAP4 IMAP4rev1 STARTTLS". the p800 is *very* picky on the response from capability and will crap out unless you do this.

compile both delegate & sslway as instructed on web page, create your host certs.

you can call delegate with a similar line to this if you are passing back to an insecure IMAP server:

./delegated -P143 SERVER=IMAP://inseucre.server.com:143 FCL="sslway -St" -f -v PERMIT="*:*:*" DGROOT=/etc/delegate -cert /etc/delegate/lib/server-cert.pem

this of course turns on all logging in the foreground with -f & -v options. i have NOT yet tried this to backend to a secure IMAP SSL port on 993.. and im not sure if i really need/want to since my backend lan is pretty secure anyways.

i'm still seeing a bug with IMAP though (with or without TLS): it doesn't mark read/unread items, nor does it acknowledge read/unread from the server.. it only marks them locally... which really sucks. hopefully SE fixes this asap.

good luck! now if SE would have only put more info in the damn manual.

rob

Wow, you have the same patience and stubbornness as me I see 😉

Wierd though... It seems that it starts with the STARTTLS but then I always get

## SSLway[15752](x.mobileonline.telia.com) STARTTLS to client -- IMAP
## SSLway[15752](x.mobileonline.telia.com) STARTTLS prologue: S-C: * OK Microsoft Exchange 2000 IMAP4rev1 server version 6.0.6249.0 (x.x.x) ready.
## SSLway[15752](x.mobileonline.telia.com) STARTTLS prologue: C-S: [1][CAPABILITY]
## SSLway[15752](x.mobileonline.telia.com) STARTTLS prologue: C-S: [2][STARTTLS]
## SSLway[15752](x.mobileonline.telia.com) STARTTLS from IMAP client -- OK
## SSLway[15752](x.mobileonline.telia.com) accept failed
02/15 02:35:39.29 [15751] 4+0: C: EOF
02/15 02:35:39.29 [15751] 4+0: disconnected [16] -@[217.213.248.56]x.mobileonline.telia.com:51378 (6.801s)(0)
02/15 02:35:39.29 [15751] 4+0: CFI process [15752] done (1/1 AFT-0)

Wonder what it can be. Login/passwd are correct.
Any ideas? 😊

PS. And yes, I got the string right. You forgot a space by the way in "*CAPABILITY IMAP4 IMAP4rev1 STARTTLS" - should be a space after * (or else the P800 will say something like unexpected protocol) 😊

well, i think we are probably two of a handful of ppl that will actually get this working 😊

here is my log for a good connection:

## SSLway[28499](216.155.166.5) STARTTLS from IMAP client -- OK
02/14 18:14:24.29 [28498] 3+0: C: 3 CAPABILITY^M
02/14 18:14:24.30 [28498] 3+0: S: 3 OK CAPABILITY completed.^M
02/14 18:14:25.33 [28498] 3+0: C: 4 LOGIN rob ****
02/14 18:14:25.40 [28498] 3+0: S: 4 OK LOGIN completed.^M

my guess is something is broken in your SSLway.. but

a *very* strange problem i just encountered with MSFT Exchange IMAP is that if youve set your NTLMcompatibility to anything above 0 in your registry, then the damn IMAP wont accept logins.. so ive had to lower my internal security to get this working. really stupid on behalf of MSFT (they dont do that for HTTP and other inet services). i dont think that is your problem in this case... i didnt keep the log from when i ran into that problem though, so i cant be sure.

btw, you can drop me an email to [email protected] for faster response. im playing with this tonight, so ill be around.

rob

I would say that something is up with SSLway as well.
My IMAP server accepts both unsecure connection on port 143 and secure connections on 993 from example outlook express, so I don't think there should be any problems there.

I'm baffled though how SE implemented this. I mean, it's supposed to be a "business" phone. Well, many businesses have MS crap and as far as I know, plans for STARTTLS support in the IMAP/POP3 services are non existent.

The internal browser supports "clean" SSL connections, so why did they have to come up with this? Get the client to connect directly to the 993 port damnit.

I would wonder if even one person at SE knows that the email client in the P800 connects to the non-SSL port of an IMAP/POP3 server and then issues the STARTTLS command.

I'm running out of luck it seems.

I cannot see what the problem is, even if I increase the log level.

However, SSLway doesn't complain if I don't givethe certificates, but maybe it hasn't come to that point yet.

I would guess SSLway would complain if the certificates were at fault.
But then maybe it's the client not wanting to accept the certs...

.. the mystery ravels on...

send me the command line call of delegated you are using

also, what type of certs are you using, self signed through opensll, etc?

try setting up an HTTPS proxy with delegate on your box to your HTTPS server (if you have one) and see if that works..

strange that you aren't getting a cert message on your client.

and yes, couldnt agree with you more on SEs choice here to use starttls.. very stupid. while i like open standards (which is what this is versus 993), the reality is nobody, and most importantly, microsoft, is using it yet.

btw, does your secure password authentication button ever allow to be picked? id like to do ntlm authentication if at all possible.. but the check box never allows me to select it.

rob

STARTTLS/STLS is the Good Way of doing this.

I have no problems with IMAP/POP3 or SMTP using STARTTLS/STLS - there are plenty of daemons which support it, PINE's IMAPd and POP3d support it and there's Qpopper etc.

The extremely annoying bug in the P800 is when you try to use authenticated SMTP with TLS - it just doesn't like it, it does the TLS stage and then doesn't try to authenticate.

[quote="Anonymous"]STARTTLS/STLS is the Good Way of doing this.

I have no problems with IMAP/POP3 or SMTP using STARTTLS/STLS - there are plenty of daemons which support it, PINE's IMAPd and POP3d support it and there's Qpopper etc.[/quote]

By using a different port (993) you can block the insecure port 143. Using STARTTLS, you have to keep 143 open, which in turn means people may accidentally connect unencrypted and thus send their password in clear text.

Get a different IMAPd ...

I can certainly disable non-TLS, and probably disable it based on specific ACLs.

[quote="lcs"]
By using a different port (993) you can block the insecure port 143. Using STARTTLS, you have to keep 143 open, which in turn means people may accidentally connect unencrypted and thus send their password in clear text.[/quote]

The P800 IMAP client supports RFC2595 for secure IMAP connections, as pointed out the client makes a connection in the clear to the specified port usually 143. However a IMAP server that confirms to the RFC should support LOGINDISABLED, this means that a client has to first setup a secure connection using STARTTLS before passing any LOGIN information, which otherwise could be seen sent over a unencrypted connection.

Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under TLS layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed

The current UW IMAPD supports this and works well.

The only annoyingn thing as pointed out by another poster is the SMTP/S connections that correctly use STARTTLS but then don't perform a SMTP AUTH.

I had some Symbian folks check this out with access to the P800 code and it is indeed a bug :cry:

HTH

Michael

I've been hacking on this all day, so I'll just add another confirmation on the behavior some are seeing:

IMAP:
If you set it to secure mode, regardless of what port number you enter, what it's looking for is STARTTLS-based encryption, *not* the wrapper-mode encryption that is often found on port 993. UW-IMAP compiled with SSL support (I'm using version 2002d) listening on port 143 supports this correctly. There's some settings (read the docs) at compile time where you can force uw-imap to only accept passwords over SSL, which essentially means the connection is required to start up with a STARTTLS, so that nobody goes and accidentally starts sending plaintext over your port 143 by misconfiguring their client. Other than the little annoyances others noted (like not syncing up on read/unread status, and only supporting the INBOX folder and nothing else), it works well for me. It properly deletes messages off of the remote server and all.

SMTP:
Again, for encryption to work it has to be STARTTLS, not wrapper mode as was sometimes found on port 465 (ssmtp service). I can get a STARTTLS mode connection to my smtp server (postfix 2.x + ssl + sasl2) just fine, but it doesn't even try to do the authentication I asked it to. Since my mail server isn't an open relay, without auth I can't very well send emails from my phone. Since I'm authenticating against PAM (which is against my md5s in /etc/shadow), I can't use a non-cleartext auth scheme like CRAM-MD5 either, so I can't very well do AUTH without TLS, so I'm not even about to try that as a workaround and have some scummy telco employee take my password with a sniffer.

Has anyone seen smtp TLS+AUTH work right in any situation? Is the bug inversal or only limited to some firmware revs?