On Wed, Mar 26, 2008 at 10:29 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > On Wed, Mar 26, 2008 at 11:01 PM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: > > wondering what measures are wise to take to secure IMAP when running live > over > > the internet. IMAP is an old fashioned protocol and is insecure by > > design. i'd like to try running JAMES IMAP live @ ApacheCon EU from a > > server in the UK but i want to think about security first. i have a > > few questions but would appreciate it if people jump in with general > > advice even if it's not covered by the questions. > > > > IMAP is not a secure protocol. running securely means deviating from > > the specification. AIUI JAMES ships with standard configurations which > > are specification compliant. > > being unsecure puts the integrity of the server and the user's data at > risk. so it is no good to be spec compliant whenever security is > converned.
true being compliant is important when running over a LAN. perhaps the TLS configuration could be secure but commented out... > > it seems a little foolish to allow an untrusted client to try > > arbitrary input against the complexity of the fully featured parser > > before logging in. perhaps a secure encoder could be used before the > > client has logged on. > > right. in the best case, only a reduced range of inputs is considered > by the server during handshake. this is what I tried in Apache Vysper. > this should not reduce spec compliance. how did you approach this problem from a design perspective? (i've been turning over the idea of using a optional wrapper for the initial handshake) > > seems foolish to allow an untrusted client to create a socket and then > > have the server retain the connection without logging in for at least > > 30 minutes before timing it out. > > right. if the server can detect obvious cases of brute force attacks, > he should close the connection. > this should not reduce spec compliance, either. specification states that all connections must not be closed as inactive for at least 30 minutes :-/ i don't know of any (legitimate) clients that refuse to login promptly so this is probably ok in practice > > seems foolish to allow an untrusted client unlimited chances to login > > over the same TLS session > > > > may want to be able to increase the difficulty of dictionary attacks > > by blocking connections from IPs which fail to login too many times. > > similarly, may want to block too many simultaneous connections from > > untrusted clients from the same IP which haven't been logged in. > > right. sounds reasonable. is this against IMAP spec? probably not it would probably make more sense to implement this at the JAMES handler framework level: just reset the socket if contacted from a blacklisted IP > > opinions? > > did you already read of http://tools.ietf.org/html/rfc2595 , > especially section 3.2? maybe this helps a bit to reduce exposure of > plain text passwords during login. i wasn't planning to use STARTTLS since IMAPS is well known but i will take another look at it... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
