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.
On 10.11.2009 05:36, Costin Manolache wrote:
> The request will not be executed - how can he continue the attack ?
I don't get that as well. As far as I understand the attack, there is no
information disclosure. The only thing an attacker can do is mixing his
request with a user supplied one, ther
https://issues.apache.org/bugzilla/show_bug.cgi?id=48166
Summary: connectionTimeout property of sever.xml doesnt work as
expected
Product: Tomcat 5
Version: 5.5.23
Platform: PC
OS/Version: Windows XP
Status: NEW
https://issues.apache.org/bugzilla/show_bug.cgi?id=48166
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Author: markt
Date: Tue Nov 10 13:40:08 2009
New Revision: 834461
URL: http://svn.apache.org/viewvc?rev=834461&view=rev
Log:
Fix some minor Eclipse warnings
Modified:
tomcat/trunk/java/org/apache/catalina/startup/WebXml.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/WebXml.java
Author: markt
Date: Tue Nov 10 14:26:01 2009
New Revision: 834477
URL: http://svn.apache.org/viewvc?rev=834477&view=rev
Log:
Use a connector attribute rather than a system property to control renegotiation
Fix some trivial Eclispe warnings in the test
Don't try and invalidate the session in the cl
On 10.11.2009 15:26, ma...@apache.org wrote:
> @@ -105,6 +102,7 @@
> protected String clientAuth = "false";
> protected SSLServerSocketFactory sslProxy = null;
> protected String[] enabledCiphers;
> +protected boolean enableMitmVulnerability = false;
>
> /**
> * Flag
Rainer Jung wrote:
>> +enableMitmVulnerability =
>> +"true".equals(attributes.get("enableMitmVulnerability"));
>> +
>> // Check the SSL config is OK
>> checkConfig();
>
> Isn't the naming a bit harsh? OpenSSl names it legacy renegot
Author: markt
Date: Tue Nov 10 15:33:50 2009
New Revision: 834504
URL: http://svn.apache.org/viewvc?rev=834504&view=rev
Log:
Prevent stack traces when closing ssl sockets after unwanted renegotiation
attempt.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Modif
Isn't the naming a bit harsh? OpenSSl names it legacy renegotiation (to
make it differ from the future renegotiation with TLS extension). So
maybe enableLegacyRenegotiation would be better? Of course it wouldn't
keep people from activating as much as the proposed name does, but on
the other han
Author: markt
Date: Tue Nov 10 15:38:37 2009
New Revision: 834506
URL: http://svn.apache.org/viewvc?rev=834506&view=rev
Log:
Rename attribute
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESo
Author: markt
Date: Tue Nov 10 15:43:17 2009
New Revision: 834510
URL: http://svn.apache.org/viewvc?rev=834510&view=rev
Log:
Document allowUnsafeLegacyRenegotiation
Modified:
tomcat/trunk/webapps/docs/config/http.xml
Modified: tomcat/trunk/webapps/docs/config/http.xml
URL:
http://svn.apache
On 10.11.2009 16:32, Ian Darwin wrote:
>
>>
>> Isn't the naming a bit harsh? OpenSSl names it legacy renegotiation (to
>> make it differ from the future renegotiation with TLS extension). So
>> maybe enableLegacyRenegotiation would be better? Of course it wouldn't
>> keep people from activating as
Rainer Jung wrote:
> On 10.11.2009 16:32, Ian Darwin wrote:
>>> Isn't the naming a bit harsh? OpenSSl names it legacy renegotiation (to
>>> make it differ from the future renegotiation with TLS extension). So
>>> maybe enableLegacyRenegotiation would be better? Of course it wouldn't
>>> keep people
Author: markt
Date: Tue Nov 10 16:46:52 2009
New Revision: 834541
URL: http://svn.apache.org/viewvc?rev=834541&view=rev
Log:
Use new attribute name
Modified:
tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java
Modified: tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL
Author: markt
Date: Tue Nov 10 16:57:29 2009
New Revision: 834544
URL: http://svn.apache.org/viewvc?rev=834544&view=rev
Log:
Proposal for cve-2009-3555 work-around
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc
Author: markt
Date: Tue Nov 10 17:20:41 2009
New Revision: 834555
URL: http://svn.apache.org/viewvc?rev=834555&view=rev
Log:
Proposal for cve-2009-3555 work-around
Modified:
tomcat/tc5.5.x/trunk/STATUS.txt
Modified: tomcat/tc5.5.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc
Author: markt
Date: Tue Nov 10 20:41:18 2009
New Revision: 834658
URL: http://svn.apache.org/viewvc?rev=834658&view=rev
Log:
Proposal
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=834
Just bumped into it now, and it's probably too late :(
All the years I spend trying to write meaningful SVN
logs when doing commits are come to a single entry:
"Move jk and jni/native out to their new locations"
Are there any changes to bring old logs back in,
or are they lost for good?
Too bad
Mladen Turk wrote:
> Just bumped into it now, and it's probably too late :(
>
> All the years I spend trying to write meaningful SVN
> logs when doing commits are come to a single entry:
> "Move jk and jni/native out to their new locations"
>
> Are there any changes to bring old logs back in,
> o
On 10/11/09 22:11, Mark Thomas wrote:
Are there any changes to bring old logs back in,
or are they lost for good?
They are still there. Tell your client not to stop on copy/move.
https://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_ajp13.c?view=log
... or just pick any one
Too
Mladen Turk wrote:
> On 10/11/09 22:11, Mark Thomas wrote:
>>>
>>> Are there any changes to bring old logs back in,
>>> or are they lost for good?
>>
>> They are still there. Tell your client not to stop on copy/move.
>>
>
> https://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_ajp13.c?vi
On 10.11.2009 22:36, Mladen Turk wrote:
> On 10/11/09 22:11, Mark Thomas wrote:
>>>
>>> Are there any changes to bring old logs back in,
>>> or are they lost for good?
>>
>> They are still there. Tell your client not to stop on copy/move.
>>
>
> https://svn.apache.org/viewvc/tomcat/jk/trunk/native
Rainer Jung wrote:
> On 10.11.2009 22:36, Mladen Turk wrote:
>> On 10/11/09 22:11, Mark Thomas wrote:
Are there any changes to bring old logs back in,
or are they lost for good?
>>> They are still there. Tell your client not to stop on copy/move.
>>>
>> https://svn.apache.org/viewvc/tomca
On 10/11/09 22:43, Rainer Jung wrote:
That's a viewvc annoyance. Since the page shows it's revision 802231,
type "802230" into the "Sticky Revision" field and click "Set". That
will move you to the previous place. Again that one was a short lived
copy, but doing the same once more moves you to t
https://issues.apache.org/bugzilla/show_bug.cgi?id=48169
Summary: two second delay for cgi scripts mixed with mod_jk
Product: Tomcat Connectors
Version: 1.2.28
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
On 10.11.2009 22:53, Mladen Turk wrote:
> On 10/11/09 22:43, Rainer Jung wrote:
>>
>> That's a viewvc annoyance. Since the page shows it's revision 802231,
>> type "802230" into the "Sticky Revision" field and click "Set". That
>> will move you to the previous place. Again that one was a short live
https://issues.apache.org/bugzilla/show_bug.cgi?id=48169
--- Comment #1 from Rainer Jung 2009-11-10 16:10:35
UTC ---
Which Linux do you exactly use?
The cgi process closes the existing backend connections after start (likely
because of CLOEXEC). Since we set SO_LINGER this is done by trying to
https://issues.apache.org/bugzilla/show_bug.cgi?id=48170
Summary: Unnecessary synchronization by
JspFactory.getDefaultFactory contributes to stability
problems
Product: Tomcat 6
Version: 6.0.16
Platform: Sun
"Costin Manolache" wrote in message
news:96e4b5230911092036j4d9c51a1j480dbce4e6968...@mail.gmail.com...
> Right, need to invalidate as well.
>
> The request will not be executed - how can he continue the attack ?
>
I've seen references where the attacker caches the original request and
replays
Author: billbarker
Date: Wed Nov 11 02:54:04 2009
New Revision: 834745
URL: http://svn.apache.org/viewvc?rev=834745&view=rev
Log:
vote
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=83
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
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
Author: pero
Date: Wed Nov 11 07:38:48 2009
New Revision: 834790
URL: http://svn.apache.org/viewvc?rev=834790&view=rev
Log:
Fix CrossContext replication support
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
tomcat/
Author: kkolinko
Date: Wed Nov 11 07:56:01 2009
New Revision: 834794
URL: http://svn.apache.org/viewvc?rev=834794&view=rev
Log:
code formatting
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport
35 matches
Mail list logo
