You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/03/26 23:01:47 UTC
[IMAP] Securing IMAP?
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.
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.
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.
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.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 27, 2008 at 11:03 PM, Antony Bowesman <ad...@teamware.com> wrote:
> Robert Burrell Donkin wrote:
> > RFC2595 is an additional standard. when privacy mode is on it is
> > incompatible with clients written to IMAP4rev1.
> >
> > but you're right that it would not be unreasonable to ship with
> > RFC2595 privacy mode on
>
> 3501 updates some of 2595, see 11.1 STARTTLS.
yes but fails to update the revision number :-/
> >> The 30 minute timer is 'autologout', so if the client has not authenticated,
> >> either with LOGIN or AUTHENICATE, then technically, the client is not logged in,
> >> therefore the 30 minute timer does not apply.
> >
> > yes, i agree it's very reasonable to read the specification in this way
>
> :) Some of the problems with IMAP are just because the spec can be interpreted
> in a number of ways.
+1
> > thanks - this is in RFC3501 but not in RFC2060. 3501 is much better in
> > many ways (but some of the recommendations may break older clients)
>
> 2060 is sooooo old, 1996 and even 3501 is 5 years old. My major gripe with 3501
> is that it mandates STARTTLS but still keps the IMAP conformance at IMAP4rev1,
> so a client does not know if it is connecting to a 2060 server or a broken 3501.
+1
> We've not had problems with 3501 though - clients would have to be pretty old
> not to work against it.
for JAMES, being precise about the specification implemented is
important. 3501 requires STARTTLS so that would need coding. probably
would make sense for JAMES to support configurable modes of operation
based on specification targeted.
> > i can't find explicit mention in 3501 about the use of BYE in this
> > situation but it seems reasonable to me (hopefully someone will set me
> > straight if i'm mistaken)
>
> No, it's not clear, but look at 3.4 including the pic page 15. The pic shows
> the path from "Not Authenticated" state to Logout is documented at step (7) as
>
> (7) LOGOUT command, server shutdown, or connection closed
>
> 3.4 implies that the connection can be unilaterally terminated by the server, as
> long as it sends the BYE before doing so.
:-)
an imaginative interpretation perhaps but it's not inconsistent with
the specification. hopefully future revisions may clarify this.
probably the approach JAMES should adopt. should probably note
implementation interpretations down somewhere.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Antony Bowesman <ad...@teamware.com>.
Robert Burrell Donkin wrote:
> RFC2595 is an additional standard. when privacy mode is on it is
> incompatible with clients written to IMAP4rev1.
>
> but you're right that it would not be unreasonable to ship with
> RFC2595 privacy mode on
3501 updates some of 2595, see 11.1 STARTTLS.
>> The 30 minute timer is 'autologout', so if the client has not authenticated,
>> either with LOGIN or AUTHENICATE, then technically, the client is not logged in,
>> therefore the 30 minute timer does not apply.
>
> yes, i agree it's very reasonable to read the specification in this way
:) Some of the problems with IMAP are just because the spec can be interpreted
in a number of ways.
> thanks - this is in RFC3501 but not in RFC2060. 3501 is much better in
> many ways (but some of the recommendations may break older clients)
2060 is sooooo old, 1996 and even 3501 is 5 years old. My major gripe with 3501
is that it mandates STARTTLS but still keps the IMAP conformance at IMAP4rev1,
so a client does not know if it is connecting to a 2060 server or a broken 3501.
We've not had problems with 3501 though - clients would have to be pretty old
not to work against it.
> i can't find explicit mention in 3501 about the use of BYE in this
> situation but it seems reasonable to me (hopefully someone will set me
> straight if i'm mistaken)
No, it's not clear, but look at 3.4 including the pic page 15. The pic shows
the path from "Not Authenticated" state to Logout is documented at step (7) as
(7) LOGOUT command, server shutdown, or connection closed
3.4 implies that the connection can be unilaterally terminated by the server, as
long as it sends the BYE before doing so.
Antony
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 27, 2008 at 8:40 AM, Antony Bowesman <ad...@teamware.com> wrote:
> Robert Burrell Donkin wrote:
>
> > IMAP is not a secure protocol. running securely means deviating from
> > the specification. AIUI JAMES ships with standard configurations which
> > are specification compliant.
>
> Using STARTTLS, LOGINDISABLED and AUTHENTICATE with a non clear text SASL
> implementation is not deviating from the spec.
RFC2595 is an additional standard. when privacy mode is on it is
incompatible with clients written to IMAP4rev1.
but you're right that it would not be unreasonable to ship with
RFC2595 privacy mode on
> > 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.
>
> The 30 minute timer is 'autologout', so if the client has not authenticated,
> either with LOGIN or AUTHENICATE, then technically, the client is not logged in,
> therefore the 30 minute timer does not apply.
yes, i agree it's very reasonable to read the specification in this way
this will mean a change to the JAMES bio framework to introduce two
timeouts parameters
> > seems foolish to allow an untrusted client unlimited chances to login
> > over the same TLS session
>
> That statement is actually against the spec! Section 11.2 states
>
> A server SHOULD have mechanisms in place to limit or delay failed
> AUTHENTICATE/LOGIN attempts.
good spot 8-)
thanks - this is in RFC3501 but not in RFC2060. 3501 is much better in
many ways (but some of the recommendations may break older clients)
i can't find explicit mention in 3501 about the use of BYE in this
situation but it seems reasonable to me (hopefully someone will set me
straight if i'm mistaken)
> > 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.
>
> Our IMAP server allows IP address blacklists and sends an immediate BYE response
> to a connecting client from any one of those addresses. This is also spec
> conformant - see 7.1.4 (4).
7.1.5 but yes, you're right immediate BYE is allowed at connection startup
> In general, IMAP, although an old protocol with a number of problems, is still
> widely used and actively developed. Just take a look at the imapext and
> Lemonade working groups. Lemonade in particular specifically targets IMAP for
> use with mobile devices. Our IMAP server provides secure IMAP service for
> mobile devices.
true
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Antony Bowesman <ad...@teamware.com>.
Robert Burrell Donkin wrote:
> IMAP is not a secure protocol. running securely means deviating from
> the specification. AIUI JAMES ships with standard configurations which
> are specification compliant.
Using STARTTLS, LOGINDISABLED and AUTHENTICATE with a non clear text SASL
implementation is not deviating from the spec.
> 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.
The 30 minute timer is 'autologout', so if the client has not authenticated,
either with LOGIN or AUTHENICATE, then technically, the client is not logged in,
therefore the 30 minute timer does not apply.
> seems foolish to allow an untrusted client unlimited chances to login
> over the same TLS session
That statement is actually against the spec! Section 11.2 states
A server SHOULD have mechanisms in place to limit or delay failed
AUTHENTICATE/LOGIN attempts.
> 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.
Our IMAP server allows IP address blacklists and sends an immediate BYE response
to a connecting client from any one of those addresses. This is also spec
conformant - see 7.1.4 (4).
In general, IMAP, although an old protocol with a number of problems, is still
widely used and actively developed. Just take a look at the imapext and
Lemonade working groups. Lemonade in particular specifically targets IMAP for
use with mobile devices. Our IMAP server provides secure IMAP service for
mobile devices.
Antony
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Apr 4, 2008 at 5:50 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Robert Burrell Donkin wrote:
<snip>
> > in terms of blacklisting IPs, this is probably more naturally done at
> > the JAMES bio framework level.
> >
> > opinions?
> >
>
> +1. for the sake of re-usability, configurability, yes.
ideas about algorithms, designs etc?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Robert Burrell Donkin wrote:
> On Sun, Mar 30, 2008 at 4:21 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>
>> > unfortunately being more strict probably means bending the
>> > specification a little too far
>>
>> ... or, in contrast, being unable to control/counteract out-of-memory
>> exploits and more generally attacks which exploit well-formendness
>> related issues. :-/
>
> TAG and COMMAND could be checked for well-formedness. IMAP is a
> line-based protocol. each line starts with a TAG.
>
> from the spec:
>
> tag = 1*<any ASTRING-CHAR except "+">
> ASTRING-CHAR = ATOM-CHAR / resp-specials
> ATOM-CHAR = <any CHAR except atom-specials>
> atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
> quoted-specials / resp-specials
> CHAR is any 7bit ASCII (0-127)
>
> when a session is unauthenticated, a specialist handler could check
> each octet and issue a BYE if the octet is outside the acceptable
> range. tags should also be small: there seems no reason why
> unauthenticated clients should be allowed to send tags bigger than a
> reasonable buffer size. so, issue a BYE in this case too.
>
> commands need to be extensible at assembly time so that developers can
> extend JAMES by adding new implementations. each COMMAND is an case
> insensitive ASCII alphabetic word. so using some sort of linked tree
> seems natural. begin by mapping any legimate octet -> 0...25, issuing
> a BYE if any is outside the range.
>
> L -> O -> G -> I -> N
> X X -> O -> U -> T
> C -> A -> P -> A -> B -> I -> L -> I -> T -> Y
> X
>
> potentially the space is pretty large so need to think about doing
> this efficiently. the tree is going to be sparse so probably worth
> distinguishing between the single entry (eg CAPABILITY above) and
> bucket case (LOG-IN/OUT). when the link is a single entry, just check
> it's value. when it's a bucket, use an array indexed by mapped
> character value. whenever a value is missed, BYE would be issued.
>
> different handlers can be used for unauthenticated and authenticated
> protection the majority of commands. the strict handler would just
> contain those commands appropriate for the unauthenticated state and
> so issue a BYE if the client tried to send them.
>
> (sounds like some more baroque coding will be required)
>
> opinions?
sounds pretty good, +1
>
> in terms of blacklisting IPs, this is probably more naturally done at
> the JAMES bio framework level.
>
> opinions?
+1. for the sake of re-usability, configurability, yes.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 30, 2008 at 4:21 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
> > unfortunately being more strict probably means bending the
> > specification a little too far
>
> ... or, in contrast, being unable to control/counteract out-of-memory
> exploits and more generally attacks which exploit well-formendness
> related issues. :-/
TAG and COMMAND could be checked for well-formedness. IMAP is a
line-based protocol. each line starts with a TAG.
from the spec:
tag = 1*<any ASTRING-CHAR except "+">
ASTRING-CHAR = ATOM-CHAR / resp-specials
ATOM-CHAR = <any CHAR except atom-specials>
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
CHAR is any 7bit ASCII (0-127)
when a session is unauthenticated, a specialist handler could check
each octet and issue a BYE if the octet is outside the acceptable
range. tags should also be small: there seems no reason why
unauthenticated clients should be allowed to send tags bigger than a
reasonable buffer size. so, issue a BYE in this case too.
commands need to be extensible at assembly time so that developers can
extend JAMES by adding new implementations. each COMMAND is an case
insensitive ASCII alphabetic word. so using some sort of linked tree
seems natural. begin by mapping any legimate octet -> 0...25, issuing
a BYE if any is outside the range.
L -> O -> G -> I -> N
X X -> O -> U -> T
C -> A -> P -> A -> B -> I -> L -> I -> T -> Y
X
potentially the space is pretty large so need to think about doing
this efficiently. the tree is going to be sparse so probably worth
distinguishing between the single entry (eg CAPABILITY above) and
bucket case (LOG-IN/OUT). when the link is a single entry, just check
it's value. when it's a bucket, use an array indexed by mapped
character value. whenever a value is missed, BYE would be issued.
different handlers can be used for unauthenticated and authenticated
protection the majority of commands. the strict handler would just
contain those commands appropriate for the unauthenticated state and
so issue a BYE if the client tried to send them.
(sounds like some more baroque coding will be required)
opinions?
in terms of blacklisting IPs, this is probably more naturally done at
the JAMES bio framework level.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Sun, Mar 30, 2008 at 3:35 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sun, Mar 30, 2008 at 2:13 PM, Bernd Fondermann
>
>
> <be...@googlemail.com> wrote:
> >
> > On Sat, Mar 29, 2008 at 11:06 AM, Robert Burrell Donkin
> > <ro...@gmail.com> wrote:
> > > On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
> > >
> > > <be...@googlemail.com> wrote:
> > >
> > > > On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
> > >
> > > <snip>
> > >
> > >
> > > > > > > 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)
> > > >
> > > > the parser is 'abstract' and only identifies command boundaries. every
> > > > handler receives a full representation of the command text. only then
> > > > comes interpretation into play. but before the command handler can
> > > > kick in, a processor checks if the command is valid for the current
> > > > state of the session. this effectively guards from execution of
> > > > unauthorized code.
> > >
> > > hmmm...
> > >
> > > IMAP is tricky to parse. the structure is
> > >
> > > TAG<SPACE>COMMAND<SPACE>REST-OF-LINE
> > >
> > > where REST-OF-LINE command dependent and often quite complex. i would
> > > like to protect the command parsers from arbitrary input.
> >
> > what I did in my XMPP implementation is to parse the command into a
> > command data structure (this is easy, since XMPP uses a subset of
> > XML). the handlers do not receive a String, but a ready-to-use object.
> > they only have to check nodes, attributes and so on.
> > I have no idea how to accomplish something similar for IMAP, where it
> > is depending on the command if REST-OF-LINE is well-formed.
>
> depends on how you approach the parsing problem. AIUI there are some
> complete parsers for IMAP which create a complete object model (but
> these have difficulties of their own). JAMES parses the first two
> productions and then passes the rest of the line to a parser
> specialised for the task of decoding a command of the given type. so,
> i don't think it would work given our approach to parsing.
ok, I see.
<snip/>
> > a. should cover command lengths and the set of all legal characters.
> > protocols (and implementations) should be strict in the sense that if
> > a client fails to comply to this, the communication is terminated
> > immediatly, even without sending a BYE.
> > this is my opinion. don't know how easy this is to accomplish in IMAP.
>
> IMAP does not set such limits. the protocol specifies that a BYE must
> be sent on termination.
... and I agree it is reasonable to adhere to the spec this way.
> > b. is where the handler should come into play, only.
> >
> > so if an implementation does not deal with a.) in the first place, it
> > is probably cumbersome and error-prone to deal with it in every
> > handler.
>
> IMAP is old fashioned and lacks a well-formedness layer
mmh.
> unfortunately being more strict probably means bending the
> specification a little too far
... or, in contrast, being unable to control/counteract out-of-memory
exploits and more generally attacks which exploit well-formendness
related issues. :-/
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 30, 2008 at 2:13 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
>
> On Sat, Mar 29, 2008 at 11:06 AM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
> > On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
> >
> > <be...@googlemail.com> wrote:
> >
> > > On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
> >
> > <snip>
> >
> >
> > > > > > 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)
> > >
> > > the parser is 'abstract' and only identifies command boundaries. every
> > > handler receives a full representation of the command text. only then
> > > comes interpretation into play. but before the command handler can
> > > kick in, a processor checks if the command is valid for the current
> > > state of the session. this effectively guards from execution of
> > > unauthorized code.
> >
> > hmmm...
> >
> > IMAP is tricky to parse. the structure is
> >
> > TAG<SPACE>COMMAND<SPACE>REST-OF-LINE
> >
> > where REST-OF-LINE command dependent and often quite complex. i would
> > like to protect the command parsers from arbitrary input.
>
> what I did in my XMPP implementation is to parse the command into a
> command data structure (this is easy, since XMPP uses a subset of
> XML). the handlers do not receive a String, but a ready-to-use object.
> they only have to check nodes, attributes and so on.
> I have no idea how to accomplish something similar for IMAP, where it
> is depending on the command if REST-OF-LINE is well-formed.
depends on how you approach the parsing problem. AIUI there are some
complete parsers for IMAP which create a complete object model (but
these have difficulties of their own). JAMES parses the first two
productions and then passes the rest of the line to a parser
specialised for the task of decoding a command of the given type. so,
i don't think it would work given our approach to parsing.
> > a similar schema could be adopted by rewriting the parser for TAG and
> > COMMAND more securely. ATM unlimited stringbuffers are used and will
> > continue to add more characters until whitespace is encounted. then
> > the command parser is looked up by command. a separate handler with a
> > limited charbuffer could be used for the TAG and a bytewise tree for
> > commands. more complex and may take a little while to write but should
> > be more secure.
>
> +1.
> any protocol profits from defining
> a. well-formed-ness
> b. syntactical correctness
> c. semantical correctness
>
> a. should cover command lengths and the set of all legal characters.
> protocols (and implementations) should be strict in the sense that if
> a client fails to comply to this, the communication is terminated
> immediatly, even without sending a BYE.
> this is my opinion. don't know how easy this is to accomplish in IMAP.
IMAP does not set such limits. the protocol specifies that a BYE must
be sent on termination.
> b. is where the handler should come into play, only.
>
> so if an implementation does not deal with a.) in the first place, it
> is probably cumbersome and error-prone to deal with it in every
> handler.
IMAP is old fashioned and lacks a well-formedness layer
> > prior to LOGIN, it is probably not unreasonable to use a BYE when an
> > overlong TAG or inappropriate COMMAND is encountered.
> > opinions?
>
> +1, but could even be more strict, see prev statement
unfortunately being more strict probably means bending the
specification a little too far
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Sat, Mar 29, 2008 at 11:06 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
>
> <be...@googlemail.com> wrote:
>
> > On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
>
> <snip>
>
>
> > > > > 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)
> >
> > the parser is 'abstract' and only identifies command boundaries. every
> > handler receives a full representation of the command text. only then
> > comes interpretation into play. but before the command handler can
> > kick in, a processor checks if the command is valid for the current
> > state of the session. this effectively guards from execution of
> > unauthorized code.
>
> hmmm...
>
> IMAP is tricky to parse. the structure is
>
> TAG<SPACE>COMMAND<SPACE>REST-OF-LINE
>
> where REST-OF-LINE command dependent and often quite complex. i would
> like to protect the command parsers from arbitrary input.
what I did in my XMPP implementation is to parse the command into a
command data structure (this is easy, since XMPP uses a subset of
XML). the handlers do not receive a String, but a ready-to-use object.
they only have to check nodes, attributes and so on.
I have no idea how to accomplish something similar for IMAP, where it
is depending on the command if REST-OF-LINE is well-formed.
> a similar schema could be adopted by rewriting the parser for TAG and
> COMMAND more securely. ATM unlimited stringbuffers are used and will
> continue to add more characters until whitespace is encounted. then
> the command parser is looked up by command. a separate handler with a
> limited charbuffer could be used for the TAG and a bytewise tree for
> commands. more complex and may take a little while to write but should
> be more secure.
+1.
any protocol profits from defining
a. well-formed-ness
b. syntactical correctness
c. semantical correctness
a. should cover command lengths and the set of all legal characters.
protocols (and implementations) should be strict in the sense that if
a client fails to comply to this, the communication is terminated
immediatly, even without sending a BYE.
this is my opinion. don't know how easy this is to accomplish in IMAP.
b. is where the handler should come into play, only.
so if an implementation does not deal with a.) in the first place, it
is probably cumbersome and error-prone to deal with it in every
handler.
> prior to LOGIN, it is probably not unreasonable to use a BYE when an
> overlong TAG or inappropriate COMMAND is encountered.
> opinions?
+1, but could even be more strict, see prev statement.
HTH, but maybe it doesn't, sorry ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Mar 26, 2008 at 11:28 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
<snip>
> > > > 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)
>
> the parser is 'abstract' and only identifies command boundaries. every
> handler receives a full representation of the command text. only then
> comes interpretation into play. but before the command handler can
> kick in, a processor checks if the command is valid for the current
> state of the session. this effectively guards from execution of
> unauthorized code.
hmmm...
IMAP is tricky to parse. the structure is
TAG<SPACE>COMMAND<SPACE>REST-OF-LINE
where REST-OF-LINE command dependent and often quite complex. i would
like to protect the command parsers from arbitrary input.
a similar schema could be adopted by rewriting the parser for TAG and
COMMAND more securely. ATM unlimited stringbuffers are used and will
continue to add more characters until whitespace is encounted. then
the command parser is looked up by command. a separate handler with a
limited charbuffer could be used for the TAG and a bytewise tree for
commands. more complex and may take a little while to write but should
be more secure.
prior to LOGIN, it is probably not unreasonable to use a BYE when an
overlong TAG or inappropriate COMMAND is encountered.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 26, 2008 at 11:40 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Wed, Mar 26, 2008 at 10:29 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
> > On Wed, Mar 26, 2008 at 11:01 PM, Robert Burrell Donkin
> > <ro...@gmail.com> 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)
the parser is 'abstract' and only identifies command boundaries. every
handler receives a full representation of the command text. only then
comes interpretation into play. but before the command handler can
kick in, a processor checks if the command is valid for the current
state of the session. this effectively guards from execution of
unauthorized code.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Mar 26, 2008 at 10:29 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Wed, Mar 26, 2008 at 11:01 PM, Robert Burrell Donkin
> <ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Securing IMAP?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 26, 2008 at 11:01 PM, Robert Burrell Donkin
<ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org