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 - the
Hello,
I just added the patch created by Costin Manolache to prevent the MITM
attack during re-negotiations for JSSE to our platform. I performed some
tests and at first I found the solution quite elegant. Nevertheless,
when I did some debugging to verify if everything was really fine I
noti
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 uni
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 l
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 r
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 List
On Wed, Nov 11, 2009 at 12:09 AM, 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 fo
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 questions
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 5.
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
I don't think NIO allows a renegotiation as it is today. I will have to
look deeper in the code. But I think the negotiation is a one time deal
per connection. I will look closer.
Filip
On 11/07/2009 09:59 AM, Mark Thomas wrote:
All,
I was thinking about this on my way back from ApacheCon an
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.
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 connecto
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 i
On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache wrote:
>
>
> On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko > wrote:
>
>> 2009/11/9 Mark Thomas :
>> > Summarising the information gathered so far from various channels
>> > (thanks to Bill B., Bill W. & Rainer who have done most of the actua
On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko
wrote:
> 2009/11/9 Mark Thomas :
> > 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 JSS
On 09.11.2009 17:16, Mark Thomas wrote:
> Konstantin Kolinko wrote:
>> 2009/11/9 Mark Thomas :
>>> 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
Konstantin Kolinko wrote:
> 2009/11/9 Mark Thomas :
>> 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
2009/11/9 Mark Thomas :
> 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
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 :
> 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. 6.0.21/5.5.29 re
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
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
Konstantin Kolinko wrote:
> 2009/11/7 Mark Thomas :
>> 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
On 09/11/09 11:34, Konstantin Kolinko wrote:
2009/11/7 Mark Thomas:
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 a
2009/11/7 Mark Thomas :
>
> 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 32/64-bit), rebu
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 (A
On Sat, Nov 7, 2009 at 8:59 AM, 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.
>
> On this basis I
"Mark Thomas" 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
> renegotiation.
>
>
On Sat, Nov 7, 2009 at 8:59 AM, 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.
>
> On this basis I
30 matches
Mail list logo
