Good catch !
If the listener is called in a separate thread, as it seems from your
debugging - the attacker may have a small window
when he can still push data - and potentially get the request executed. I
guess the probability is extremely
small - but theoretically can be done.
I'll try it -
Hello,
I am currently working on my company's platform to get around this
security problem during re-negotiation. After discussing with my group
about the progress being made towards a fix for tomcat, some questions
were raised and I was hoping you could help me answer them.
We use Tomcat
On 11/11/09 09:09, Luciana Moreira Sa de Souza Signed by - PrivaSphere AG wrote:
Hello,
I am currently working on my company's platform to get around this
security problem during re-negotiation. After discussing with my group
about the progress being made towards a fix for tomcat, some
On Wed, Nov 11, 2009 at 12:09 AM, Luciana Moreira Sa de Souza Signed
by - PrivaSphere AG s...@privasphere.com wrote:
Hello,
I am currently working on my company's platform to get around this security
problem during re-negotiation. After discussing with my group about the
progress being made
On 11/11/2009 12:11 AM, Costin Manolache wrote:
openssl s_client ...
Type R ( to renegotiate ).
Unfortunately renegotiation is handled transparently and did work quite
well...
bummer, I will see what needs to be done today.
Costin
On Tue, Nov 10, 2009 at 10:53 PM, Filip Hanik - Dev Lists
Sorry for my confusion - didn't realize NIO has its own ssl AND is not the
default in the embedded tomcat.
We should make it in trunk - and maybe get rid of the old connector, APR +
NIO is enough ( plus the new one I'm
planning for lite :-)
I changed the tests - the good news is that indeed NIO
On 11/11/2009 11:13 AM, Costin Manolache wrote:
Sorry for my confusion - didn't realize NIO has its own ssl AND is not the
default in the embedded tomcat.
We should make it in trunk - and maybe get rid of the old connector, APR +
the old connector is still the most stable one. So we should
Great foresight, Filip !
public int handshake(boolean read, boolean write) throws IOException {
if ( initHandshakeComplete ) return 0; //we have done our initial
handshake
...
}
+ no handling of the SSLEngineResult - just perfect security !
I have an update to the
On 10.11.2009 01:17, Mark Thomas wrote:
Costin Manolache wrote:
Unless someone has a better solution - I'll submit the fix ( tonight ), will
disable re-negotiation for
Jsse-mode.
I added a system property to allow people how don't care about this, IMO by
default it should
be on.
Sounds
openssl s_client ...
Type R ( to renegotiate ).
Unfortunately renegotiation is handled transparently and did work quite
well...
Costin
On Tue, Nov 10, 2009 at 10:53 PM, Filip Hanik - Dev Lists
devli...@hanik.com wrote:
I don't think NIO allows a renegotiation as it is today. I will have to
2009/11/7 Mark Thomas ma...@apache.org:
We also need to think about what to do with tc native. Maybe something like:
I think that we can
- recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
our sources
- for those architectures where binaries are available for 1.1.16
(windows
On 09/11/09 11:34, Konstantin Kolinko wrote:
2009/11/7 Mark Thomasma...@apache.org:
We also need to think about what to do with tc native. Maybe something like:
I think that we can
- recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
our sources
- for those architectures
Konstantin Kolinko wrote:
2009/11/7 Mark Thomas ma...@apache.org:
We also need to think about what to do with tc native. Maybe something like:
I think that we can
- recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
our sources
- for those architectures where binaries are
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
BIO/NIO connectors using JSSE.
Vulnerable when renegotiation is triggered by the client or server.
We could prevent server initiated
On 09/11/09 11:56, Mark Thomas wrote:
- We can release 1.1.17 with the binaries built with 0.9.8l. This
will also protect users at the risk of breaking any
configurations that require renegotiation. Mladen is doing this
now.
I've uploaded binaries with APR-1.3.9/OpenSSL 9.8.8l.
Should
2009/11/9 Mark Thomas ma...@apache.org:
Konstantin Kolinko wrote:
My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29
and later and vice versa, because of some API changes, and thus won't
be useful until those versions are released.
That isn't my understanding.
On 09.11.2009 11:56, Mark Thomas wrote:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
BIO/NIO connectors using JSSE.
Vulnerable when renegotiation is triggered by the
2009/11/9 Mark Thomas ma...@apache.org:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
BIO/NIO connectors using JSSE.
Vulnerable when renegotiation is triggered by the client
Konstantin Kolinko wrote:
2009/11/9 Mark Thomas ma...@apache.org:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
BIO/NIO connectors using JSSE.
Vulnerable when renegotiation
On 09.11.2009 17:16, Mark Thomas wrote:
Konstantin Kolinko wrote:
2009/11/9 Mark Thomas ma...@apache.org:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
BIO/NIO connectors
On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko
knst.koli...@gmail.comwrote:
2009/11/9 Mark Thomas ma...@apache.org:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. Rainer who have done most of the actual
work to find the info below).
On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache cos...@gmail.com wrote:
On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:
2009/11/9 Mark Thomas ma...@apache.org:
Summarising the information gathered so far from various channels
(thanks to Bill B., Bill
Unless someone has a better solution - I'll submit the fix ( tonight ), will
disable re-negotiation for
Jsse-mode.
I added a system property to allow people how don't care about this, IMO by
default it should
be on.
Also got the test case to work - please let me know if it's acceptable to
commit
Costin Manolache wrote:
Unless someone has a better solution - I'll submit the fix ( tonight ), will
disable re-negotiation for
Jsse-mode.
I added a system property to allow people how don't care about this, IMO by
default it should
be on.
Sounds good. Any chance it could be a connector
On 07.11.2009 17:59, Mark Thomas wrote:
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
renegotiation.
Yes, client side initiated (AFAIK
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
renegotiation.
On this basis I suggest something along the following lines:
SSL using JSSE (BIO
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org wrote:
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
renegotiation.
On this
Mark Thomas ma...@apache.org wrote in message
news:4af5a776.70...@apache.org...
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org wrote:
All,
I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.
My current understanding is that the MITM attack is triggered by a
renegotiation.
On this
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41202.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
/show_bug.cgi?id=41202
Summary: strange ssl tomcat response
Product: Tomcat 5
Version: 5.5.20
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev
Hello list!
First of all thank you for developing such a good software as tomcat!
I am concerned about an issue that i could not find a solutions for:
after installing and configuring tomcat 5.5 to use ssl if i am trying to
request the ssl
port with non ssl protocol i am getting a result that i
telnetting into my local apache2.2 on ssl and typeing GET / HTTP/1.0 is
fun!
$ telnet localhost 443
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
GET / HTTP/1.0
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title400 Bad Request/title
Thanks for reply.
If i understand correctly you tried apache not tomcat,right?
The behaviour you described is exactly what i expect the tomact to do.
But in place i am getting those strange responses (bits as i described it)
What i am worried about is mostly security and since i don't know what
34 matches
Mail list logo
