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. > > 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. > 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. > 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? > 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. Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
