POP3 client behavior re. hosts.deny

I have stunnel and teapop set up on a Debian server. I want to avoid
sending my POP password cleartext if I accidentally misconfigure my
email client not to use SSL, so I've set up hosts.allow/hosts.deny
appropriately. In testing, I notice that tcpd closes the connection
without sending any data, just as hosts.deny told it to. However, I
wonder if this is sufficient to keep the password from being sent.

Do most POP clients wait for the "+OK..." line, or do some of them start
sending before they receive anything from the server? I'm most
interested in Thunderbird, but am curious about other POP clients as
well. I could sniff packets and test myself, but I haven't used
sniffers in about 9 years. I'd have to learn one, then probably
wouldn't use that knowledge again in a long time. I was hoping somebody
on this group would just know.

In hindsight, changing inetd.conf and stunnel to do POP on a different
port would have solved the problem more easily than even writing this
message, but now I'm curious. Have people checked this?

Thanks!
Bruce

Bruce Lewis <brlspam@yahoo.com> writes:

> I have stunnel and teapop set up on a Debian server. I want to avoid
> sending my POP password cleartext if I accidentally misconfigure my email
> client not to use SSL, so I've set up hosts.allow/hosts.deny
> appropriately. In testing, I notice that tcpd closes the connection
> without sending any data, just as hosts.deny told it to. However, I
> wonder if this is sufficient to keep the password from being sent.
>
> Do most POP clients wait for the "+OK..." line, or do some of them start
> sending before they receive anything from the server?

I would've thought any attempt to send application-level data like that
would be a pretty naff violation of TCP, being as the application should
have received a TCP RST from the hosts.deny-induced connection-rejection.

There's a similar phenomenon in SMTP, btw, whereby exim has `protocol
synchronization violation' - when people start shouting without waiting for
banners and `200 OK' lines, etc. I'm certainly not aware of such a thing in
a POP-client, but that doesn't mean it won't exist at some stage.

> I'm most interested in Thunderbird, but am curious about other POP
> clients as well. I could sniff packets and test myself, but I haven't
> used sniffers in about 9 years. I'd have to learn one, then probably
> wouldn't use that knowledge again in a long time. I was hoping somebody
> on this group would just know.

tcpdump -s 1500 -n -w somefile.log.net port 110
<do things>
^C
tcpdump -v -r somefile.log.net | less

> In hindsight, changing inetd.conf and stunnel to do POP on a different
> port would have solved the problem more easily than even writing this
> message, but now I'm curious. Have people checked this?

How about using a firewall so there can be *no* connection established at
all, not even as far as tcpwrappers? Keep the ssl-wrapped high port open
for as few IP#s as you need, make it wrap down to localhost:110 and then
leave port 110 blocked-off from the outside world (by default, along with
every other non-provided-service port). You could also try to bind teapop
to localhost only, as well, that would be rather effective too.

~Tim
--
Back on the stamping ground |piglet@stirfried.vegetable.org.uk
Where it all began |http://pig.sty.nu/

Tim Haynes <usenet-20040902@stirfried.vegetable.org.uk> writes:

> I would've thought any attempt to send application-level data like that
> would be a pretty naff violation of TCP, being as the application should
> have received a TCP RST from the hosts.deny-induced connection-rejection.

Except the connection is not rejected. It's accepted (presumably by
inetd), then closed (presumably by tcpd). I don't think tcpd has any
way to cause the connection to be rejected.

> tcpdump -s 1500 -n -w somefile.log.net port 110
> <do things>
> ^C
> tcpdump -v -r somefile.log.net | less

Ah, cool. Now I can at least check Thunderbird.

> How about using a firewall so there can be *no* connection established at
> all, not even as far as tcpwrappers?

This is a virtual server (User-Mode Linux) on linode.com. I'm pretty
sure the firewall option is unvailable to me.

> You could also try to bind teapop
> to localhost only, as well, that would be rather effective too.

Hmm...that really looks like the cleanest solution. Maybe it's time to
switch to xinetd. I don't see any option for inetd to bind to a
specified address, nor in the teapop docs for its standalone mode.

Bruce Lewis <brlspam@yahoo.com> writes:

> Tim Haynes <usenet-20040902@stirfried.vegetable.org.uk> writes:
>
>> I would've thought any attempt to send application-level data like that
>> would be a pretty naff violation of TCP, being as the application should
>> have received a TCP RST from the hosts.deny-induced connection-rejection.
>
> Except the connection is not rejected. It's accepted (presumably by
> inetd), then closed (presumably by tcpd). I don't think tcpd has any way
> to cause the connection to be rejected.

Yes, but it's either an RST or a FIN... either way, the client has to be
pretty rude not to take the hint :)

>> How about using a firewall so there can be *no* connection established at
>> all, not even as far as tcpwrappers?
>
> This is a virtual server (User-Mode Linux) on linode.com. I'm pretty sure
> the firewall option is unvailable to me.

Ah. Hmmm. Well, it would be a nice layer to put between you and nasty
twits, if you can :)

>> You could also try to bind teapop to localhost only, as well, that would
>> be rather effective too.
>
> Hmm...that really looks like the cleanest solution. Maybe it's time to
> switch to xinetd. I don't see any option for inetd to bind to a specified
> address, nor in the teapop docs for its standalone mode.

xinetd *good*. Muchly recommended. Can bind things to interfaces when they
don't know how to. Can also do nice restrictions based on IP# and rate and
CPU/resource-usage, etc.

~Tim
--
Gabrielle and Madelene were just dolls. |piglet@stirfried.vegetable.org.uk
|http://pig.sty.nu/

Tim Haynes <usenet-20040902@stirfried.vegetable.org.uk> writes:

> Yes, but it's either an RST or a FIN... either way, the client has to be
> pretty rude not to take the hint :)

When I was testing using telnet, telnet gave its "Connected to" message,
then sat there for a second or two before saying the connection was
closed. A client would have time to send packets.

> xinetd *good*. Muchly recommended. Can bind things to interfaces when they
> don't know how to. Can also do nice restrictions based on IP# and rate and
> CPU/resource-usage, etc.

I ended up using xinetd, also uw-imapd. Debian (I use their "testing"
distribution) by default installs uw-imapd with only SSL enabled, which
is good. It automatically changed inetd.conf, and gave a warning that I
needed to configure xinetd myself. Fine with me; it wasn't hard.

I could have stuck with inetd and used stunnel with the -l argument.
The first stunnel examples I looked at all dealt with running daemons,
so I had just set up teapop standalone. However, I'm glad for what I
learned in this process. I expect xinetd will prove useful down the
line.