[Swlug] imap server and smartphone

[Dave Cridland]

On 23 September 2016 at 08:56, Matt Willsher via Swlug
<swlug at mailman.lug.org.uk> wrote:
>
>
> On 23 Sep 2016, at 02:53, Ben Tullis via Swlug <swlug at mailman.lug.org.uk>
> wrote:
>
> Good reply Ben. I have some additional thoughts and questions.
>
> 2: You could open your IMAP port to the world, but protect it a bit,
> then use an IMAP client on the phone
> - Run the public IMAP service on a non-standard port number, using your
> firewall to forward the incoming traffic to the normal port
>
>
> While this stops drive by port scans, I've found remembering the ports if I
> need access from elsewhere to be awkward. If the server is kept patched then
> leaving it on the public port would be okay. Fail2ban is a must though,
> ideally with a longer block time than the default 10 minutes. Be sure to add
> your home network and perhaps work IP as exclusions to the block list to
> avoid accidental lock outs.
>
> 3: You could open your IMAP port to the world, but protect it
> cryptographically, then use an IMAP client on the phone
> - Use client-authenticating TLS so that you need to provide a valid
> digital certificate before you can connect to the port
>
>
> This is the gold standard really. From my experience, managing the certs can
> be a bit awkward, as can be setting them up in the first place with
> reasonable ciphers and hashes. For mobile use, I understand ECDSA has less
> computation overhead if the client supports it and can save on battery life
> on the phone if it's checking in the background.
>
> You should also use an SSL cert for IMAP even if you don't use a client
> certificate. A simple self signed one is fine if you can trust the public
> cert on your phone. Otherwise there is startssl, which is free and will be
> in the trust store already, CAcert which needs to CA loading but then gives
> free certs or let's encrypt which automatically creates and manages certs
> for free. Let's encrypt is perhaps the best choice here but it has a bit of
> a learning curve and the plethora of tools that support it doesn't help -
> some are good, some are not so good.
>
> Make sure you have strong passwords ( I use at least 20 chars random number,
> case, symbol these days, but a 4 or 5 long word password is easier to manual
> enter and remember)
>

LastPass. It's not perfect, but it's better than your memory will ever be.

> Also be sure that you only have users able to authenticate that have mail
> boxes.
>
> Over an encrypted connect PLAIN or LOGIN authentication to Cyrus is fine.
>

In the interests of being bloody awkward, it might be, but it depends
on your threat model.

PLAIN (and LOGIN, and other plaintext password mechanisms) operate by
the client sending the password to the server, which checks it. Thus
if the client can be persuaded into sending it without TLS, or the
client can be persuaded to connect to the wrong server (someone makes
a new cert or compromises the old one - because I'll bet your Android
phone isn't doing status checks), then the client will blithely send
the password to the attacker.

Mechanisms like DIGEST-MD5 and CRAM-MD5, while both cryptographically
quite weak, protect the password on the wire. This means that although
you absolutely still want TLS in place with real certificates, an
attacker has to brute force the password from a hash.

However, there's a flip side - PLAIN and LOGIN allow strongly-hashed
passwords on the server-side, whereas CRAM and DIGEST require it to be
plaintext (or at least a plaintext equivalent). There's a newer
mechanism, SCRAM, which allows the best of both worlds - a well-hashed
password on the server and nothing plaintext-equivalent exchanged on
the wire, but your client probably won't support it. SCRAM also
supports a thing called "channel binding", which effectively means the
client provides a cryptographic proof that its view of the TLS session
is the same as the server's, thus eliminating MITM attacks (well,
almost).

Client certs are the best option (well, a client cert using a hardware
cryptographic module, or HCM, is the best option, but that gets
complicated on mobile).

> A proxy in from of the server isn't a bad ideas either. Either stunnel as
> Ben says or Nginx, which can terminate the SSL connection for you so you
> don't have to touch Cyrus.
>

I'd argue this is a bad idea.

* Cyrus will then have to be configured to allow plaintext logins
without TLS. That just feels like a horrible risk to me.
* Cyrus will not be able to do any kind of client cert authentication.

The advantage from a security perspective of using a proxy is that
some attacks which result in an attacker reading memory from the
remote process will become harder - but the canonical example is
Heartbleed, which would have still resulted in an attacker reading off
the private key with a proxy.

If this is part of your threat model, you want to use some kind of HCM
- there's a "Soft HCM" knocking about which means the private key is
held in a different process, which will help.

> My question is what is a good way to manage the CA and certs for client
> authentication? Is OpenSSL still the best option or are their tools that
> make it easier to use current good practice?

http://lmgtfy.com/?q=open+source+ca :-)

I've not tried any of them, mind - though perhaps I should.

>
> Have fun!
>
> Matt
>
>
> _______________________________________________
> Swlug mailing list
> Swlug at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/swlug
>