[openjms-developer] [ openjms-Bugs-756237 ] telnet-ing directly to tcp connector/jndi yields OutOfMemory

Discussion:

SourceForge.net

2003-06-24 10:54:12 UTC

Resolution: Later

Priority: 5
Submitted By: John Evans (lgas)

Assigned to: Tim Anderson (tanderson)

Summary: telnet-ing directly to tcp connector/jndi yields OutOfMemory

Initial Comment:
If you start the OpenJMS server with the
tcp_jms_full.xml configuration and telnet to either the
port 3030 (the tcp connector) or port 3035 (the jndi
connector) and hit return several times, you will see an
OutOfMemoryError in the output from the server.

Obviously the server is not expecting people to telnet to
it, but in "the wild" this will happen all the time, so this
is a denial-of-service problem.

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)

Date: 2003-06-24 20:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

SourceForge.net

2003-06-24 11:10:19 UTC

Permalink

Bugs item #756237, was opened at 2003-06-17 17:17
Message generated for change (Comment added) made by lgas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

Category: server
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: John Evans (lgas)
Assigned to: Tim Anderson (tanderson)
Summary: telnet-ing directly to tcp connector/jndi yields OutOfMemory

Initial Comment:
If you start the OpenJMS server with the
tcp_jms_full.xml configuration and telnet to either the
port 3030 (the tcp connector) or port 3035 (the jndi
connector) and hit return several times, you will see an
OutOfMemoryError in the output from the server.

Obviously the server is not expecting people to telnet to
it, but in "the wild" this will happen all the time, so this
is a denial-of-service problem.

----------------------------------------------------------------------

Comment By: John Evans (lgas)

Date: 2003-06-24 07:10

Message:
Logged In: YES
user_id=137603

If the connector is being replaced anyway, and the tcps
connector is a valid workaround, then I suppose it makes
sense to skip this for now.

As an aside, is it possible to get access to the certificate of
the client that sent a message using the tcps connector? To
authenticate the source of the message?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 06:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

SourceForge.net

2003-06-24 13:19:02 UTC

Permalink

Bugs item #756237, was opened at 2003-06-18 07:17
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

Category: server
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: John Evans (lgas)
Assigned to: Tim Anderson (tanderson)
Summary: telnet-ing directly to tcp connector/jndi yields OutOfMemory

Initial Comment:
If you start the OpenJMS server with the
tcp_jms_full.xml configuration and telnet to either the
port 3030 (the tcp connector) or port 3035 (the jndi
connector) and hit return several times, you will see an
OutOfMemoryError in the output from the server.

Obviously the server is not expecting people to telnet to
it, but in "the wild" this will happen all the time, so this
is a denial-of-service problem.

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)

Date: 2003-06-24 23:19

Message:
Logged In: YES
user_id=557161

No, there is no facility to do this. However, I don't think its
needed as the client must be authenticated by the server in
order for it to send messages.

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-24 21:10

Message:
Logged In: YES
user_id=137603

If the connector is being replaced anyway, and the tcps
connector is a valid workaround, then I suppose it makes
sense to skip this for now.

As an aside, is it possible to get access to the certificate of
the client that sent a message using the tcps connector? To
authenticate the source of the message?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 20:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

SourceForge.net

2003-06-25 02:55:20 UTC

Permalink

Comment By: John Evans (lgas)

Date: 2003-06-24 22:55

Message:
Logged In: YES
user_id=137603

I don't see how to authenticate a client to the server -- the
createTopicConnection(String user, String pass) method (and
the corresponding createQueueConnection method) both
ignore the user and pass parameters....?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 09:19

Message:
Logged In: YES
user_id=557161

No, there is no facility to do this. However, I don't think its
needed as the client must be authenticated by the server in
order for it to send messages.

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-24 07:10

Message:
Logged In: YES
user_id=137603

If the connector is being replaced anyway, and the tcps
connector is a valid workaround, then I suppose it makes
sense to skip this for now.

As an aside, is it possible to get access to the certificate of
the client that sent a message using the tcps connector? To
authenticate the source of the message?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 06:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

SourceForge.net

2003-06-25 07:26:09 UTC

Permalink

Comment By: Tim Anderson (tanderson)

Date: 2003-06-25 17:26

Message:
Logged In: YES
user_id=557161

We don't yet support authentication at the JMS level, but the
tcps connector (SSL over TCP) requires that clients
authenticate themselves when connecting (refer to
SSLServerSocket.setNeedClientAuth() for details).

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-25 12:55

Message:
Logged In: YES
user_id=137603

I don't see how to authenticate a client to the server -- the
createTopicConnection(String user, String pass) method (and
the corresponding createQueueConnection method) both
ignore the user and pass parameters....?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 23:19

Message:
Logged In: YES
user_id=557161

No, there is no facility to do this. However, I don't think its
needed as the client must be authenticated by the server in
order for it to send messages.

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-24 21:10

Message:
Logged In: YES
user_id=137603

If the connector is being replaced anyway, and the tcps
connector is a valid workaround, then I suppose it makes
sense to skip this for now.

As an aside, is it possible to get access to the certificate of
the client that sent a message using the tcps connector? To
authenticate the source of the message?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 20:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559

SourceForge.net

2003-06-25 07:34:20 UTC

Permalink

Comment By: John Evans (lgas)

Date: 2003-06-25 03:34

Message:
Logged In: YES
user_id=137603

Hmmm, this is better than nothing, but I have a situation
where I am going to be having multiple clients connecting and
sending/receiving messages, and I need to know which
specific client a message is from. I guess if nothing else a
workaround would be to set up a seperate server for each
client and have only their public key in the keystore for that
server.

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-25 03:26

Message:
Logged In: YES
user_id=557161

We don't yet support authentication at the JMS level, but the
tcps connector (SSL over TCP) requires that clients
authenticate themselves when connecting (refer to
SSLServerSocket.setNeedClientAuth() for details).

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-24 22:55

Message:
Logged In: YES
user_id=137603

I don't see how to authenticate a client to the server -- the
createTopicConnection(String user, String pass) method (and
the corresponding createQueueConnection method) both
ignore the user and pass parameters....?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 09:19

Message:
Logged In: YES
user_id=557161

No, there is no facility to do this. However, I don't think its
needed as the client must be authenticated by the server in
order for it to send messages.

----------------------------------------------------------------------

Comment By: John Evans (lgas)
Date: 2003-06-24 07:10

Message:
Logged In: YES
user_id=137603

If the connector is being replaced anyway, and the tcps
connector is a valid workaround, then I suppose it makes
sense to skip this for now.

As an aside, is it possible to get access to the certificate of
the client that sent a message using the tcps connector? To
authenticate the source of the message?

----------------------------------------------------------------------

Comment By: Tim Anderson (tanderson)
Date: 2003-06-24 06:54

Message:
Logged In: YES
user_id=557161

I'm a bit reluctant to spend any time fixing this as the tcp
connector is going to be replaced in the near future.

In any case, it won't fix all DOS issues - a client could
hammer the server with new connections and cause the same
problem.

The tcps connector should be able to avoid the problem you
describe.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=756237&group_id=54559