12 Dec
2007
12 Dec
'07
9:35 p.m.
Thanks Vincent & Nathan for your quick replies.
The bit I was missing was that even when you specify ssl_listen, you
need to specify the real server port as 143. I tcpdumped headers from
the perdition box to the back-end server, and when I saw it going to
port 993, I assumed it was still trying SSL to the back-end server when
I had specified ssl_listen.
On Vincent's comment that ssl on the backend shouldn't really matter, I
agree- this isn't the 90s, and I've got very beefy hardware. On the
other hand, the servers are both on a protected subnet which no user can
plug into, so there's not even a possibility of arp-spoofing MITM
attacks.. so why waste resources which are totally unnecessary? Also,
you can then avoid the extra work of configuring & maintaining multiple
SSL certificates.
Cheers
Ross
-----Original Message-----
From: Vincent Fox [mailto:vbfox@ucdavis.edu]
Sent: Wednesday, December 12, 2007 1:28 PM
To: Ross Becker
Cc: perdition-users(a)vergenet.net
Subject: Re: [PERDITION-USERS] Perdition config question
Ross Becker wrote:
Looking at the ssl_mode options, there doesn't
appear to be a
none_outgoing, which is what I believe I want.
Read the man page again.
If you specify ssl_listen only, then outoing is unencrypted by default.
We fine-grain each protcol, with 4 config files:
perdition.imap4.conf
perdition.imaps.conf
perdition.pop3.conf
perdition.pop3s.conf
Our setup is actually the reverse, we enforce all backend
connections to the server to SSL. The penalty of encryption
to backends is IMO overstated and a waste of time to pursue.
Setting up a private network to keep all your passwords from
being sniffed sniffed blah blah is a common solution, but it's
spending dollars worth of man-hours to save a few pennies.
SSL imposes at most a 20% overhead on CPU these days.
This is not the 90's unless you are trying to run 10K users on
a Pentium III you will not run out of CPU.
12 Dec
12 Dec
9:50 p.m.
New subject: Perdition config question
I work in the UC Davis Data Center we have about
70K users plus or minus a few hundred.
When more than a couple of systems end up getting attached
to your "private" network, at some point you will have
to do a LENGTHY investigation when some system
you didn't even know about, gets hacked and then the
security folks wonder whether 70K users could have
had their passwords sniffed. Let's not get into proper
security practice discussion, if you work in a Data Center
you know you have enough systems something will go
wrong or maybe you'll just get hit with a 0-day sploit.
Things do go wrong and I prefer to not trust anything
will take advantage of any layers of security handy.
IMO plaintext is not worth the trouble. I like the added security
of being able to say "I didn't trust the network" because
sometimes you really can't unless it's a one-man show
with a handful of systems.
If you are not using this in a big shop and do not
have these problems then by all means. I can tell you
from running Perdition in this mode, the CPU on our
4 Perdition frontends are barely ticking over at load peak
of MAYBE 0.2 during the Fall quarter rush. Our frontends
are nothing exciting really just some COTS 1U Opterons.
We use internally generated certs for Perdition to backend
mail-store and that is no big deal to set up.
It is very nice having Perdition in the front, we can migrate
users around in the backend to all kinds of mail-stores Exchange
or Cyrus or whatever, it's transparent. We just update the record
in LDAP as to what backend they are stored on.
I just wish Perdition had GSSAPI support.
10:44 p.m.
New subject: Perdition config question
Hello all, I've been monitoring this list for a bit watching for updates
and waiting for the release of 1.18.
Another option, that we chose to do here is to use ipsec between our
perdition box and our imap boxes. We also use ipsec between our web mail
boxes and the perdition box.
We use SSL (port 993) between our clients and the perdition box and SSL
(port 443) on the web mailers. It's worked very well for us so far.
We also think our server subnet is pretty secure but frankly you just
never know what will occur. We'd been running the setup for a while now
but only started enforcing it for all of our users recently. It works
well for us.
Clark
Vincent Fox wrote:
I work in the UC Davis Data Center we have about
70K users plus or minus a few hundred.
When more than a couple of systems end up getting attached
to your "private" network, at some point you will have
to do a LENGTHY investigation when some system
you didn't even know about, gets hacked and then the
security folks wonder whether 70K users could have
had their passwords sniffed. Let's not get into proper
security practice discussion, if you work in a Data Center
you know you have enough systems something will go
wrong or maybe you'll just get hit with a 0-day sploit.
Things do go wrong and I prefer to not trust anything
will take advantage of any layers of security handy.
IMO plaintext is not worth the trouble. I like the added security
of being able to say "I didn't trust the network" because
sometimes you really can't unless it's a one-man show
with a handful of systems.
If you are not using this in a big shop and do not
have these problems then by all means. I can tell you
from running Perdition in this mode, the CPU on our
4 Perdition frontends are barely ticking over at load peak
of MAYBE 0.2 during the Fall quarter rush. Our frontends
are nothing exciting really just some COTS 1U Opterons.
We use internally generated certs for Perdition to backend
mail-store and that is no big deal to set up.
It is very nice having Perdition in the front, we can migrate
users around in the backend to all kinds of mail-stores Exchange
or Cyrus or whatever, it's transparent. We just update the record
in LDAP as to what backend they are stored on.
I just wish Perdition had GSSAPI support.
______________________________________________
Perdition-users mailing list
Perdition-users(a)vergenet.net
http://lists.vergenet.net/listinfo/perdition-users
--
____________________________________
Clark W. Coffman - System Admin - EduTech (education technology services)
North Dakota State University - 1320 Albrecht Blvd, IACC 218D
Clark.Coffman(a)Sendit.Nodak.Edu
Work: 701-231-8825 - Fax: 701-231-8541
Hamster: Whack!!
Rabbit: Did you just whack me with a carrot? ...
Hamster: Whoa! Oh boy!!
------------------------------------
6003
days inactive
6003
days old
2 comments
3 participants
participants (3)
-
Clark Coffman -
Ross Becker -
Vincent Fox