Main Page | Report this Page
Linux Forum Index  »  Linux Security  »  How practically risky is it to use unsecured IMAP...
Page 1 of 1    

How practically risky is it to use unsecured IMAP...

Author Message
Ignoramus17493...
Posted: Tue May 26, 2009 1:01 pm
Guest
I have a Linux box that is on Comcast cable.

I also have a Android Cell phone that is on a phone company's IP
network.

The home Linux server runs dovecot IMAP server, uses SSL and does NOT
have any officially signed site certificate.

It works fine with most IMAP clients, but Android phone requires a
valid certificate. It will, however, work with an unsecured
connection, which I have not yet enabled for security reasons.

So, my question is, how practically risky is it to enable plain text
log in from my cell phone?

Inside the home, I use network switches only (not hubs) and I am the
root level administrator.

i
 
Mike Rechtman...
Posted: Tue May 26, 2009 9:36 pm
Guest
Ignoramus17493 wrote:
Quote:
I have a Linux box that is on Comcast cable.

I also have a Android Cell phone that is on a phone company's IP
network.

The home Linux server runs dovecot IMAP server, uses SSL and does NOT
have any officially signed site certificate.

It works fine with most IMAP clients, but Android phone requires a
valid certificate. It will, however, work with an unsecured
connection, which I have not yet enabled for security reasons.

So, my question is, how practically risky is it to enable plain text
log in from my cell phone?

Inside the home, I use network switches only (not hubs) and I am the
root level administrator.

i
Look up how to create a self-signed certificate. If you trust yourself

that is just as secure as trusting a CA

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this
message.
--
 
David Woolley...
Posted: Wed May 27, 2009 12:45 am
Guest
Mike Rechtman wrote:

Quote:
i
Look up how to create a self-signed certificate. If you trust yourself
that is just as secure as trusting a CA

I hope that is what he is saying he has already done. He seems to be
suggesting that Android has no facility for users to install root
certificates. Not having one, I don't know if that is true, although it
is not inconsistent with either the idea that they may want tight
control of the platform, or they use a split client, where the SSL
terminates in the fixed network.

If they don't allow users to install root certificates, they will annoy
the more sophisticated parts of the business market, but it is possible
that businesses who equip their employees with Androids are deemed to
have money to burn on Verisign and friends.

Overall, though the security would be similar to that of making a voice
call from a landline. The exact details will depend on the mobile
network, the country (presumably the USA, where over the air encryption
will not have been limited), physical protection of the broadband
connection, whether copper or fibre, and the general threat to the
individual.
>
 
Sabine Dinis Blochberger...
Posted: Wed May 27, 2009 2:42 am
Guest
Mike Rechtman wrote:

Quote:
Ignoramus17493 wrote:
I have a Linux box that is on Comcast cable.

I also have a Android Cell phone that is on a phone company's IP
network.

The home Linux server runs dovecot IMAP server, uses SSL and does NOT
have any officially signed site certificate.

Can you install root certificates? Then look into CACert

<http://www.cacert.org>, they provide free certificates for SSL traffic.
Or rather, they will sign your certificate for free.

Quote:
It works fine with most IMAP clients, but Android phone requires a
valid certificate. It will, however, work with an unsecured
connection, which I have not yet enabled for security reasons.

So, my question is, how practically risky is it to enable plain text
log in from my cell phone?

Inside the home, I use network switches only (not hubs) and I am the
root level administrator.

i
Look up how to create a self-signed certificate. If you trust yourself
that is just as secure as trusting a CA

If I understand the OP correctly, Android doesn't like those.


--
Op3racional - www.op3racional.eu
---------------------
If you're reading this, you're on Usenet
<http://oakroadsystems.com/genl/unice.htm>
 
Ignoramus20538...
Posted: Wed May 27, 2009 6:45 am
Guest
On 2009-05-27, Mike Rechtman <mike at (no spam) rechtman.com> wrote:
Quote:
Ignoramus17493 wrote:
I have a Linux box that is on Comcast cable.

I also have a Android Cell phone that is on a phone company's IP
network.

The home Linux server runs dovecot IMAP server, uses SSL and does NOT
have any officially signed site certificate.

It works fine with most IMAP clients, but Android phone requires a
valid certificate. It will, however, work with an unsecured
connection, which I have not yet enabled for security reasons.

So, my question is, how practically risky is it to enable plain text
log in from my cell phone?

Inside the home, I use network switches only (not hubs) and I am the
root level administrator.

i
Look up how to create a self-signed certificate. If you trust yourself
that is just as secure as trusting a CA


The phone does not accept such certificates. This is the problem.

i
 
C. (http://symcbean.blogspot.com/)...
Posted: Thu May 28, 2009 2:30 am
Guest
On May 27, 1:45 pm, Ignoramus20538 <ignoramus20... at (no spam) NOSPAM.
20538.invalid> wrote:
Quote:
On 2009-05-27, Mike Rechtman <m... at (no spam) rechtman.com> wrote:



Ignoramus17493 wrote:
I have a Linux box that is on Comcast cable.

I also have a Android Cell phone that is on a phone company's IP
network.

The home Linux server runs dovecot IMAP server, uses SSL and does NOT
have any officially signed site certificate.

It works fine with most IMAP clients, but Android phone requires a
valid certificate. It will, however, work with an unsecured
connection, which I have not yet enabled for security reasons.

So, my question is, how practically risky is it to enable plain text
log in from my cell phone?

Inside the home, I use network switches only (not hubs) and I am the
root level administrator.

i
Look up how to create a self-signed certificate. If you trust yourself
that is just as secure as trusting a CA

The phone does not accept such certificates. This is the problem.

i

According to a comment on http://code.google.com/p/android/issues/detail?id=1077
it does after a config change (although the poster seems to think that
will allow MITM attacks!!!!)

Failing that, just go buy a signed cert - a quick surf shows them
available from around £8 GBP/annum (approx 10 USD). But the CN on the
cert will still need to match the DNS entry you use to connect.

C.
 
Snowbat...
Posted: Thu May 28, 2009 8:50 pm
Guest
On Wed, 27 May 2009 07:45:44 -0500, Ignoramus20538 wrote:

Quote:
The phone does not accept such certificates. This is the problem.

s/problem/bug/
http://code.google.com/p/android/issues/detail?id=1016
 
David Woolley...
Posted: Fri May 29, 2009 4:06 pm
Guest
C. (http://symcbean.blogspot.com/) wrote:

Quote:

According to a comment on http://code.google.com/p/android/issues/detail?id=1077
it does after a config change (although the poster seems to think that
will allow MITM attacks!!!!)

What they seem to be suggesting is turning off authentication. If one
is operating this secure email system properly, one will have installed
the SSL certificate (or one higher in the tree, if not self signed) in
the client, which then guarantees that the server is the true server to
the same level of assurance as the weakest enabled root certificate on
the device.

In practice though, too few people understand MITM and SSL certificates
role in preventing it, for certificates to actually provide much
protection. Also devices come with some pretty weakly authenticated,
but enabled, root certificates.

As an example of MITM risks that the public is totally unaware of, 3D
Secure (VbV and SecureCode) are totally vulnerable to MITM attacks,
unless you check their SSL certificates - the challenge phrase is
worthless. Moreover, at least one major card payment service that I
recently tried to use actually goes man in the middle (presumably to
avoid framing the VbV formk -i.e. the common problem of marketing
compromising security). The HTML purports to actually submit to the
card issuer, but I wasn't going to check the scripting, so I just
abandoned, but 99.9% of users would give out their password without even
realising that the authentication was badly compromised.
Quote:

Failing that, just go buy a signed cert - a quick surf shows them
available from around £8 GBP/annum (approx 10 USD). But the CN on the
cert will still need to match the DNS entry you use to connect.
 
Alan J Rosenthal...
Posted: Fri May 29, 2009 5:41 pm
Guest
David Woolley <david at (no spam) ex.djwhome.demon.co.uk.invalid> writes:
[imap without ssl]
Quote:
Overall, though the security would be similar to that of making a voice
call from a landline.

Except that you don't normally read your unix password over the telephone for
the benefit of eavesdroppers.

Plus the fact that I don't think you're right, in general, because I
understand that some cable modems see some other houses' data, depending
on the network topology. You can't normally get other houses' data with
land-line telephone service. (Assuming it's not a "party line", you're
not using any "cordless" telephone units, etc.)
 
David Woolley...
Posted: Fri May 29, 2009 6:46 pm
Guest
Alan J Rosenthal wrote:
Quote:
David Woolley <david at (no spam) ex.djwhome.demon.co.uk.invalid> writes:
[imap without ssl]
Overall, though the security would be similar to that of making a voice
call from a landline.

Except that you don't normally read your unix password over the telephone for
the benefit of eavesdroppers.

On the other hand, people feel more comfortable giving credit card
details over it than they do with broadband.
Quote:

Plus the fact that I don't think you're right, in general, because I
understand that some cable modems see some other houses' data, depending

That's possible. I'm in the UK and most people are on routed ADSL,
which doesn't have that problem.

Quote:
on the network topology. You can't normally get other houses' data with
land-line telephone service. (Assuming it's not a "party line", you're
not using any "cordless" telephone units, etc.)
 
Dave {Reply Address In.Sig}...
Posted: Sat May 30, 2009 4:58 am
Guest
David Woolley wrote:

Quote:
Alan J Rosenthal wrote:
David Woolley <david at (no spam) ex.djwhome.demon.co.uk.invalid> writes:
[imap without ssl]
Overall, though the security would be similar to that of making a voice
call from a landline.

Except that you don't normally read your unix password over the telephone
for the benefit of eavesdroppers.

On the other hand, people feel more comfortable giving credit card
details over it than they do with broadband.

Plus the fact that I don't think you're right, in general, because I
understand that some cable modems see some other houses' data, depending

That's possible. I'm in the UK and most people are on routed ADSL,
which doesn't have that problem.

You say that, but when I first got my ADSL installed, I was receiving not

only my traffic but copies of packets for someone in the next town (but on
the same exchange) as well. Admittedly it was only stuff he was downloading
so it wouldn't have contained passwords, but I would have been able to read
all his email if he was using unsecured IMAP, and I knew some of his hobbies
based on some of the websites he visited.

I deduced his ISP from the IP address and sent a small dump of traffic to
their tech people and also my ISP tech people. Both said "that's
impossible!" while acknowledging that indeed it was possible because it was
happening. Eventually it stopped happening (I assume, I've since changed my
setup so the Netgear router might be hiding it from me) so I guess someone
fixed it.
--
Dave
da ve at (no spam) llondel.org (without the space)
So many gadgets, so little time.
 
Alan J Rosenthal...
Posted: Sat May 30, 2009 10:08 am
Guest
"Dave {Reply Address In.Sig}" <noone$$ at (no spam) llondel.org> writes:
Quote:
You say that, but when I first got my ADSL installed, I was receiving not
only my traffic but copies of packets for someone in the next town
....


This, btw, is part of a larger point. The fact that a given computer
sees only network traffic destined for it is generally implemented as
an optimization, not as a security guarantee.

For example, an ethernet switch will generally send a packet out to all ports
(those RJ45 sockets on the switch) if it doesn't have the MAC address in its
arp cache. It's not considered bad that ports _occasionally_ see traffic
not destined for computers down that port; it would only be considered bad
if ports _often_ saw such traffic, because it would decrease the bandwidth
available for their own use.

That is to say, it's a bandwidth optimization, not a security guarantee.
For a security guarantee, use cryptographic protocols.

And to go back to the original question for a moment -- I evaluate
appropriate level of concern about password-interception based not only on
what the password gives you direct access to, but also what you can leverage
it into. A stolen imap password may or may not also be a general-purpose
unix password on the same computer. In the latter case, you can likely
leverage it into all sorts of other accesses. On the other hand, if the
e-mail messages available via imap contain passwords, that in itself could
provide substantial leverage opportunities.

Oh... and... I can't let someone's mention of credit card numbers go by
without commenting. Credit card numbers aren't passwords.
 
Anne & Lynn Wheeler...
Posted: Sat May 30, 2009 11:36 am
Guest
flaps at (no spam) dgp.toronto.edu (Alan J Rosenthal) writes:
Quote:
Oh... and... I can't let someone's mention of credit card numbers go by
without commenting. Credit card numbers aren't passwords.

in effect knowledge of credit card number is sufficient to perform a
fraudulent financial transactions ... that makes them "something you
know" authentication ... in the same way that PINs & passwords are
"something you know" authentication.

from 3-factor authenticaton model ... some past posts
http://www.garlic.com/~lynn/subintegrity.html#3factor

* something you have
* something you know
* something you are

we had been called in to consult with a small client/server startup that
wanted to do payment transactions on their server ... the small
client/server startup also had invented something called "SSL" that they
wanted to use; it is now frequently referred to as "electronic
commerce". Part of that effort including doing something called a
"payment gateway" ... some number of past posts
http://www.garlic.com/~lynn/subnetwork.html#gateway

somewhat as part of that effort, in the mid-90s, we were invited to
participate in the x9a10 financial standard working group which had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments (i.e. *ALL*, credit, debit,
stored-value, ACH, internet, face-to-face, point-of-sale, unattended,
i.e. *ALL*). As part of that we did detailed, end-to-end threat and
vulnerability studies of various retail payments. The outcome of that
effort was the X9.59 financial standard ... some refs:
http://www.garlic.com/~lynn/x959.html#x959

One of the major identified threat & vulnerabilities were data breaches,
skimming, evesdropping, etc ... i.e. being able to obtain credit card
numbers (frequently from previous transactions) for the purpose of
account fraud (sub-category of identity theft) and fraudulent
transactions. One of the things done in the x9.59 financial standard was
to slightly tweak the paradigm, making such information useless to
crooks for the purpose of fraudulent financial transactions.

Now, the major use of SSL in the world today is hiding the transaction
information (& account numbers and credit card numbers) as part of the
effort for "electronic commerce". It turns out that x9.59 eliminates
that need/use of SSL (i.e. eliminating credit card numbers as a
"something you know" authentication). It also eliminates the threat and
vulnerability from the majority of data breaches that have been in the
news.

--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
 
 
Page 1 of 1    
All times are GMT - 5 Hours
The time now is Mon Nov 30, 2009 11:57 am