This is getting out of hand. I am subcribed to what is supposed to be a
daily digest. Today I received *seven.* What is going on?
EJP
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands,
Mark
Can I direct your attention to java.beans.Statement and
java.beans.Expression. They already do all the matching you're talking
about.
EJP
Forward to the list as per Marks' request.
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, 17 September 2013
The hack attempts that started this thread aren't denial of service attacks
at all. They are attempted penetration attempts which if successful lead to
installation of a viral servlet. The way I fixed them was to put an Apache
HTTPD in front with a whitelist so that only known management IP
be
connected to from outside the localhost. That's not 'security by obscurity',
that's security via a well-known feature of TCP. It is in effect a firewall.
EJP
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Monday, 15 April 2013 8:25 PM
To: Esmond Pitt
Cc: 'Tomcat Users List
I agree with your comment. Adding a second box for Tomcat only means I
also have to configure a firewall between them, whereas using
127.0.0.x for Tomcat protects it completely.
No it doesn't!
Obfuscation or indirection != security.
HTTPD doesn't magically provide you with some extra
/1.0
404
241112 by: Esmond Pitt
241113 by: Howard W. Smith, Jr.
241114 by: Howard W. Smith, Jr.
241119 by: Jeffrey Janner
RE : Tomcat 6.0.35 Crashed again
241115 by: saumil shah
Re: Inno Setup Script?
241116 by: James Green
241117
You would have had to intentionally enable the default password.
I had clearly done that.
The attacker installed a viral servlet application that killed the
server completely, we had to rebuild it.
I -- like most people I would guess -- don't run under a SecurityManager,
but doing so can
We had lots of these and finally an attack last year on a Tomcat where the
manager password somehow hadn't been changed. The attacker installed a viral
servlet application that killed the server completely, we had to rebuild it.
We:
- Hid the Tomcat behind an Apache HTTPD on port 80.
- Closed
Tomcat by default should accept all the enabled cipher suites in an
SSLSocket, unless it has been configured to do differently. That list is far
longer than either of the client lists supplied.
-Original Message-
From: Giuseppe Sacco [mailto:giuse...@eppesuigoccas.homedns.org]
Sent:
1. The ciphers parameter in Connecter determines the enabled cipher suites
in the SSLSocket. See SSLSocket.setEnabledCipherSuites(). That in turn
restricts which actual cipher suite can be negotiated with the client,
depending also on the client's cipher suites and how JSSE chooses among
those
The peer can't receive the SSL close_notify or the TCP FIN until it has
received all the pending data from the sender. Conversely, if there is any
TCP data in flight back to the sender when the peer receives the
close_notify and FIN it will not be discarded. The response close_notify and
FIN can
Yes but he *already has* an SSL session which he states is being
invalidated. To the limited extent to which I could make sense of your
incomprehensible post, it appears to be 100% irrelevant.
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Wednesday, 5 December
thrown.
Re loss of the SSL session, I suppose it is plausible that SSL discards it
on security grounds because of the broken connection.
EJP
_
From: Vincent Goelen [mailto:goel...@gmail.com]
Sent: Wednesday, 5 December 2012 9:19 PM
To: Esmond Pitt
Subject: Re: Tomcat 7 SSL Session ID
Broken pipes don't invalidate the SSL session. They just break the TCP
connection. The SSL session persists, across multiple TCP connections, until
it is specifically invalidated by someone: for example, timed out by the
SSLSessionContext.
EJP
_
From: Vincent Goelen
, all the
connections on the backlog queue will get closed, and the clients concerned
will get 'connection reset' if they are still sending, or, even worse,
premature EOFs when trying to receive the reply.
You don't seem to know much about it.
Esmond Pitt FACS
Author, 'java.rmi: the Guide to Remote
Asankha
To reiterate what Christopher said, if you close the listening socket
because you think you can't service one extra client, you will lose all the
connections on the backlog queue, which could be hundreds of clients, that
you *can* service.
In addition, those clients will then get exactly
Hi Esmond
That wouldn't have any different effect to not calling accept() at all
in blocking mode
Clearly there is a difference.
There isn't a difference. All that deregistering OP_ACCEPT does is prevent
the application from calling accept(). It has exactly the same effect as
Asankha
I haven't said a word about your second program, that closes the listening
socket. *Of course* that causes connection refusals, it can't possibly not,
but it isn't relevant to the misconceptions about what OP_ACCEPT does that
you have been expressing here and that I have been addressing.
That wouldn't have any different effect to not calling accept() at all in
blocking mode, or to thread starvation such that the accept thread didn't
get a run. It wouldn't make any difference to whether the client got a
connection refused/reset. The backlog queue would still fill up in exactly
the
Asankha
What you are looking at is TCP platform-dependent behaviour. There is a
'backlog' queue of inbound connections that have been completed by the TCP
stack but not yet accepted by the application via the accept() API. This is
the queue whose length is specified in the 'C' listen() method
The HttpServletRequest.logout function was added in Servlet 3.0. I don't
know what your citation is talking about but there is no
HttpSession.logout() method in the Servlet Specification 2.4 or anywhere
else.
EJP
-Original Message-
From: javed Ansari [mailto:javid@gmail.com]
Sent:
Javed
I don't know why you are invalidating the session when you log *in.* I said
to invalidate it to log *out*.
EJP
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
Javed
Just call Session.invalidate() or HttpServletRequest.logout(). The JAASRealm
will do the rest, and call logout() on your LoginModule. Note that you can't
assume it is the same instance of your login module, that's what all the
shared state is for.
EJP
For information of the list, this was first opened as a feature request:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53359 but after
discussion the following was implemented instead and will be in 7.0.28:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53373. Basically
whitespace is now
I have a large and growing number of requirements for aliases, and the
existing (new for Tomcat 7) aliases= attribute is unwieldy for me. The line
is already 289 characters long ;-(
It would be a lot more convenient if aliases could be specified individually
via a repeatable nested Alias entry,
I am not sure that mod_jk mappings follow the principle of longest match
wins.
They follow a logic of their own whereby wildcard matches outrank
non-wildcard matches, so for example:
JkMount /*
JkUnmount /
doesn't operate to unmount the Tomcat root, not because it is shorter but
because it
26 matches
Mail list logo
