Re: SSL & Tomcat
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 good. Any chance it could be a connector property rather than a > system property? If you don't have a chance to do this I can always make > that change (and do some testing) tomorrow. > >> Also got the test case to work - please let me know if it's acceptable to >> commit it, it depends >> on having a .keystore with a 'localhost' cert, didn't find any other SSL >> tests in the suite. > > Add the keystore to svn as well. That way, the test should always work. > >> Forgot that you need to read() after startHandshake() - just cut&pasted the >> code from >> JsseSupport and it worked. +1 to everything - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834289 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
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, thereby leveraging user credentials to execute his own request. Neither can he see the user request, not the response. The user client will do a renegaotiation and only provide his request inside the newly negotiated encryption, which is not transparent for the MITM. the server buffers the partial attacker request send directly before initiating the renegotiation and if it is an incomplete request, it will buffered at the server, combined with what the user is sending after renegotiation and executed in the security context of the user. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48166] New: connectionTimeout property of sever.xml doesnt work as expected
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 Severity: critical Priority: P2 Component: Connector:HTTP AssignedTo: dev@tomcat.apache.org ReportedBy: vichi...@gmail.com connectionTimeout property of sever.xml doesnt work as expected:- connection dosent close even after the time limit(2 milli-secomnds) expired. to test this i deployed a servlet, in tomcat sever, servlet has Thread.sleep(7) in code. i am expecting "connection closed error" but still after 7 milli-seconds i got response back. Ideally tomcat should close the connection after 2 miliseconds if response doesnt come. please not servlet is deployed in stand alone tomcat sever thanks, -vichitra -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48166] connectionTimeout property of sever.xml doesnt work as expected
https://issues.apache.org/bugzilla/show_bug.cgi?id=48166 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2009-11-10 05:29:36 GMT --- That isn't what the timeout is intended for. Please ask on the users list if you need a more detailed explanation. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834461 - /tomcat/trunk/java/org/apache/catalina/startup/WebXml.java
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
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/WebXml.java?rev=834461&r1=834460&r2=834461&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/WebXml.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/WebXml.java Tue Nov 10
13:40:08 2009
@@ -69,11 +69,11 @@
// web.xml only elements
// Absolute Ordering
private Set absoluteOrdering = null;
-public void addAbsoluteOrdering(String name) {
+public void addAbsoluteOrdering(String fragmentName) {
if (absoluteOrdering == null) {
absoluteOrdering = new LinkedHashSet();
}
-absoluteOrdering.add(name);
+absoluteOrdering.add(fragmentName);
}
public void addAbsoluteOrderingOthers() {
if (absoluteOrdering == null) {
@@ -88,8 +88,8 @@
// web-fragment.xml only elements
// Relative ordering
private Set after = new LinkedHashSet();
-public void addAfterOrdering(String name) {
-after.add(name);
+public void addAfterOrdering(String fragmentName) {
+after.add(fragmentName);
}
public void addAfterOrderingOthers() {
if (before.contains(ORDER_OTHERS)) {
@@ -99,8 +99,8 @@
after.add(ORDER_OTHERS);
}
private Set before = new LinkedHashSet();
-public void addBeforeOrdering(String name) {
-before.add(name);
+public void addBeforeOrdering(String fragmentName) {
+before.add(fragmentName);
}
public void addBeforeOrderingOthers() {
if (after.contains(ORDER_OTHERS)) {
@@ -162,8 +162,8 @@
// context-param
// TODO: description (multiple with language) is ignored
private Map contextParams = new HashMap();
-public void addContextParam(String name, String value) {
-contextParams.put(name, value);
+public void addContextParam(String param, String value) {
+contextParams.put(param, value);
}
public Map getContextParams() { return contextParams; }
@@ -708,10 +708,11 @@
if (getLoginConfig() == null) {
LoginConfig tempLoginConfig = null;
for (WebXml fragment : fragments) {
-LoginConfig loginConfig = fragment.loginConfig;
-if (loginConfig != null) {
-if (tempLoginConfig == null ||
loginConfig.equals(tempLoginConfig)) {
-tempLoginConfig = loginConfig;
+LoginConfig fragmentLoginConfig = fragment.loginConfig;
+if (fragmentLoginConfig != null) {
+if (tempLoginConfig == null ||
+fragmentLoginConfig.equals(tempLoginConfig)) {
+tempLoginConfig = fragmentLoginConfig;
} else {
log.error(sm.getString(
"webXml.mergeConflictLoginConfig",
@@ -860,36 +861,35 @@
Map tempResources,
Map mergeInjectionFlags, WebXml fragment) {
for (T resource : fragmentResources.values()) {
-String name = resource.getName();
+String resourceName = resource.getName();
boolean mergeInjectionFlag = false;
-if (mainResources.containsKey(name)) {
-if (mergeInjectionFlags.containsKey(name)) {
+if (mainResources.containsKey(resourceName)) {
+if (mergeInjectionFlags.containsKey(resourceName)) {
mergeInjectionFlag =
-mergeInjectionFlags.get(name).booleanValue();
+mergeInjectionFlags.get(resourceName).booleanValue();
} else {
if (mainResources.get(
-name).getInjectionTargets().size() == 0) {
+resourceName).getInjectionTargets().size() == 0) {
mergeInjectionFlag = true;
}
-mergeInjectionFlags.put(name,
+mergeInjectionFlags.put(resourceName,
Boolean.valueOf(mergeInjectionFlag));
}
if (mergeInjectionFlag) {
-mainResources.get(name).getInjectionTargets().addAll(
+
mainResources.get(resourceName).getInjectionTargets().addAll(
resource.getInjectionTargets());
}
} else {
// Not defined in main web.xml
-if (tempResources.containsKey(name)) {
+if (tempResources.containsKey(resourceName)) {
svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.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 client - an attacker probably won't
do this
Add a test that checks the connector attribute can be used to enable
renegotiation
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=834477&r1=834476&r2=834477&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Tue Nov 10 14:26:01 2009
@@ -95,9 +95,6 @@
private static final int defaultSessionCacheSize = 0;
private static final int defaultSessionTimeout = 86400;
-private static final boolean midmMode =
-"true".equals(System.getProperty("enable_ssl_mitm_vulnerability"));
-
static org.apache.juli.logging.Log log =
org.apache.juli.logging.LogFactory.getLog(JSSESocketFactory.class);
@@ -105,6 +102,7 @@
protected String clientAuth = "false";
protected SSLServerSocketFactory sslProxy = null;
protected String[] enabledCiphers;
+protected boolean enableMitmVulnerability = false;
/**
* Flag to state that we require client authentication.
@@ -159,7 +157,7 @@
SSLSocket asock = null;
try {
asock = (SSLSocket)socket.accept();
- if (!midmMode) {
+ if (!enableMitmVulnerability) {
asock.addHandshakeCompletedListener(
new DisableSslRenegotiation());
}
@@ -492,6 +490,9 @@
getEnabledCiphers(requestedCiphers,
sslProxy.getSupportedCipherSuites());
+enableMitmVulnerability =
+"true".equals(attributes.get("enableMitmVulnerability"));
+
// Check the SSL config is OK
checkConfig();
Modified: tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java?rev=834477&r1=834476&r2=834477&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java (original)
+++ tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java Tue Nov 10
14:26:01 2009
@@ -20,11 +20,11 @@
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
+import java.security.cert.X509Certificate;
import javax.net.ssl.HandshakeCompletedEvent;
import javax.net.ssl.HandshakeCompletedListener;
import javax.net.ssl.SSLContext;
-import javax.net.ssl.SSLSession;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManager;
@@ -41,12 +41,16 @@
public class TestTomcatSSL extends TomcatBaseTest {
static TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
-public java.security.cert.X509Certificate[] getAcceptedIssuers() {
+public X509Certificate[] getAcceptedIssuers() {
return null;
}
-public void
checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType)
{
-}
-public void
checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType)
{
+public void checkClientTrusted(X509Certificate[] certs,
+String authType) {
+// NOOP - Trust everything
+}
+public void checkServerTrusted(X509Certificate[] certs,
+String authType) {
+// NOOP - Trust everything
}
}
};
@@ -63,10 +67,9 @@
public void testSimpleSsl() throws Exception {
-// Install the all-trusting trust manager so https:// works
+// Install the all-trusting trust manager so https:// works
// with unsigned certs.
-// TODO: cleanup ?
try {
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
@@ -91,7 +94,7 @@
boolean handshakeDone = false;
-public void testReHandshake() throws Exception {
+public void testRenegotiateFail() throws Exception {
Tomcat tomcat = getTomcatInstance();
File appDir =
@@ -100,6 +103,7 @@
tom
Re: svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.java
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 to state that we require client authentication.
> @@ -492,6 +490,9 @@
> getEnabledCiphers(requestedCiphers,
> sslProxy.getSupportedCipherSuites());
>
> +enableMitmVulnerability =
> +"true".equals(attributes.get("enableMitmVulnerability"));
> +
> // Check the SSL config is OK
> checkConfig();
>
>
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 hand (unfortunately) there are valid use cases to activate it.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.java
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 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 hand (unfortunately) there are valid use cases to activate it.
I'm happy with changing the name to be consistent with OpenSSL. More
consistency == less confusion which I think is a good thing.
I'm still doing testing but so far it looks good. If any one is able to
do their own testing please do so. The more eyes on this the better.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834504 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
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
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java?rev=834504&r1=834503&r2=834504&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java Tue Nov
10 15:33:50 2009
@@ -171,7 +171,10 @@
break;
}
}
-ssl.setSoTimeout(oldTimeout);
+// If legacy re-negotiation is disabled, socked could be closed here
+if (!ssl.isClosed()) {
+ssl.setSoTimeout(oldTimeout);
+}
if (listener.completed == false) {
throw new SocketException("SSL Cert handshake timeout");
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.java
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 hand (unfortunately) there are valid use cases to activate it. FWIW, the OpenBSD people have committed their change to their OpenSSL library, and they used the name SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION Ian - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834506 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
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/JSSESocketFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=834506&r1=834505&r2=834506&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Tue Nov 10 15:38:37 2009
@@ -102,7 +102,7 @@
protected String clientAuth = "false";
protected SSLServerSocketFactory sslProxy = null;
protected String[] enabledCiphers;
-protected boolean enableMitmVulnerability = false;
+protected boolean allowUnsafeLegacyRenegotiation = false;
/**
* Flag to state that we require client authentication.
@@ -157,7 +157,7 @@
SSLSocket asock = null;
try {
asock = (SSLSocket)socket.accept();
- if (!enableMitmVulnerability) {
+ if (!allowUnsafeLegacyRenegotiation) {
asock.addHandshakeCompletedListener(
new DisableSslRenegotiation());
}
@@ -490,8 +490,8 @@
getEnabledCiphers(requestedCiphers,
sslProxy.getSupportedCipherSuites());
-enableMitmVulnerability =
-"true".equals(attributes.get("enableMitmVulnerability"));
+allowUnsafeLegacyRenegotiation =
+
"true".equals(attributes.get("allowUnsafeLegacyRenegotiation"));
// Check the SSL config is OK
checkConfig();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834510 - /tomcat/trunk/webapps/docs/config/http.xml
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.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=834510&r1=834509&r2=834510&view=diff == --- tomcat/trunk/webapps/docs/config/http.xml (original) +++ tomcat/trunk/webapps/docs/config/http.xml Tue Nov 10 15:43:17 2009 @@ -789,6 +789,13 @@ certificates. + + Is unsafe legacy TLS renegotiation allowed which is likely to expose + users to CVE-2009-3555, a man-in-the-middle vulnerability in the TLS + protocol that allows an attacker to inject arbitrary data into the user's + request. If not specified, a default of false is used. + + For more information, see the - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.java
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 much as the proposed name does, but on >> the other hand (unfortunately) there are valid use cases to activate it. >> > FWIW, the OpenBSD people have committed their change to their > OpenSSL library, and they used the name > > SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION Yes, you are right. Omitting the "Unsafe" part of it isn't good, so I would say either allowUnsafeLegacyRenegotiation or enableUnsafeLegacyRenegotiation. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834477 - in /tomcat/trunk: java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java test/org/apache/catalina/startup/TestTomcatSSL.java
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 from activating as much as the proposed name does, but on >>> the other hand (unfortunately) there are valid use cases to activate it. >>> >> FWIW, the OpenBSD people have committed their change to their >> OpenSSL library, and they used the name >> >> SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION > > Yes, you are right. Omitting the "Unsafe" part of it isn't good, so I > would say either allowUnsafeLegacyRenegotiation or > enableUnsafeLegacyRenegotiation. I've already committed the first one :) My tests all went well. I am in the process of creating patches for 6.0.x and 5.5.x. Remy - are you able to roll a release? I'm guessing either later today or early tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834541 - /tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java
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.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java?rev=834541&r1=834540&r2=834541&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java (original)
+++ tomcat/trunk/test/org/apache/catalina/startup/TestTomcatSSL.java Tue Nov 10
16:46:52 2009
@@ -162,7 +162,7 @@
initSsl(tomcat);
// Enable MITM attack
-tomcat.getConnector().setAttribute("enableMitmVulnerability", "true");
+tomcat.getConnector().setAttribute("allowUnsafeLegacyRenegotiation",
"true");
tomcat.start();
SSLContext sslCtx = SSLContext.getInstance("TLS");
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834544 - /tomcat/tc6.0.x/trunk/STATUS.txt
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/tc6.0.x/trunk/STATUS.txt?rev=834544&r1=834543&r2=834544&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Nov 10 16:57:29 2009 @@ -390,3 +390,9 @@ http://people.apache.org/~markt/patches/2009-11-09-tc6-cookies.patch +1: markt -1: + +* Disable TLS renegotiation be default with an option to re-enable it + Based on Costin's patch for trunk with Mark's modifications + http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834555 - /tomcat/tc5.5.x/trunk/STATUS.txt
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/tc5.5.x/trunk/STATUS.txt?rev=834555&r1=834554&r2=834555&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Tue Nov 10 17:20:41 2009 @@ -197,4 +197,10 @@ - Auto switch on use of comment http://people.apache.org/~markt/patches/2009-11-09-tc5-cookies.patch +1: markt + -1: + +* Disable TLS renegotiation be default with an option to re-enable it + Based on Costin's patch for trunk with Mark's modifications + http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc5.patch + +1: markt -1: \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834658 - /tomcat/tc6.0.x/trunk/STATUS.txt
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=834658&r1=834657&r2=834658&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Nov 10 20:41:18 2009 @@ -396,3 +396,8 @@ http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch +1: markt -1: + +* Improvements to memory leak prevention + http://people.apache.org/~markt/patches/2009-11-10-leak-prevention.patch + +1: markt + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
SVN logs lost
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 I didn't check that earlier cause Mark would be paying brekfast lunch and dinner trough the entire ApacheCon :) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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, > or are they lost for good? They are still there. Tell your client not to stop on copy/move. > Too bad I didn't check that earlier cause Mark would > be paying brekfast lunch and dinner trough the entire > ApacheCon :) Nice try, but I don't pay out for 'user error' :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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 bad I didn't check that earlier cause Mark would be paying brekfast lunch and dinner trough the entire ApacheCon :) Nice try, but I don't pay out for 'user error' :) We shall see! Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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?view=log > > > ... or just pick any one The web client doesn't show the history prior to the move/copy. You need to manually follow the changes. (Click on the revision number to see where is was copied from). I use TortoiseSVN which has no problems following the history. Mark >>> Too bad I didn't check that earlier cause Mark would >>> be paying brekfast lunch and dinner trough the entire >>> ApacheCon :) >> >> Nice try, but I don't pay out for 'user error' :) >> > > We shall see! > > Regards - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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/common/jk_ajp13.c?view=log > > > ... or just pick any one 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 the original place and shows all old logs. >>> Too bad I didn't check that earlier cause Mark would >>> be paying brekfast lunch and dinner trough the entire >>> ApacheCon :) >> >> Nice try, but I don't pay out for 'user error' :) >> > > We shall see! Maybe I can get half a breakfast from you and half from Mark ... Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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/tomcat/jk/trunk/native/common/jk_ajp13.c?view=log >> >> >> ... or just pick any one > > 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 the original place and > shows all old logs. > Too bad I didn't check that earlier cause Mark would be paying brekfast lunch and dinner trough the entire ApacheCon :) >>> Nice try, but I don't pay out for 'user error' :) >>> >> We shall see! > > Maybe I can get half a breakfast from you and half from Mark ... Neat trick. Didn't know viewvc could do that. That'll be worth a beer or two next time I see you. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SVN logs lost
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 the original place and shows all old logs. What a mess. I'd loved that page where I could track the changes. Oh well... Maybe I can get half a breakfast from you and half from Mark ... Like me, you are too late as well. But by the next ApacheCon it might be that you will be paying breakfasts :) Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48169] New: two second delay for cgi scripts mixed with mod_jk
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
Priority: P2
Component: mod_jk
AssignedTo: dev@tomcat.apache.org
ReportedBy: t...@dublan.net
I'm running gentoo linux, kernel 2.6.30.
This may be related to bug 37469 and bug 37470, but I'm running mod_jk 1.2.28
(apache 2.2.11) which is supposed to have the fix for that and I still seem to
have a related symptom: a two-second delay on a cgi script when tomcat isn't
going to handle it. Static files are fine, it's just cgi scripts that seem to
be affected.
The symptoms are much like the previously mentioned bugs. If I hit a
tomcat-handled uri first, then subsequent requests to any (simple) cgi-script
(perl, ruby, etc) which don't use mod_jk takes exactly two seconds seemingly
waiting for mod_jk to finish its pre-processing. If I turn off mod_jk, the cgi
script runs in milliseconds. If I don't hit the tomcat-handled uri first, the
cgi-script is also run in milliseconds.
I ran an strace on the fork of apache that was doing this; I've marked the
place where the 2-second delay happened with "==>":
<... epoll_wait resumed> {{EPOLLHUP, {u32=136451400, u64=136451400}}}, 2,
30) = 1 <0.000745>
read(19, ""..., 8000) = 0 <0.05>
read(21, 0xbfc7c420, 1) = -1 EAGAIN (Resource temporarily
unavailable) <0.06>
poll([{fd=21, events=POLLIN}], 1, 30) = 1 ([{fd=21, revents=POLLHUP}])
<0.12>
read(21, ""..., 1) = 0 <0.05>
close(21) = 0 <0.09>
read(14, 0x8222188, 8000) = -1 EAGAIN (Resource temporarily
unavailable) <0.06>
write(9, "10.49.220.36 - - [10/Nov/2009:10:"..., 71) = 71 <0.24>
close(16) = 0 <0.07>
close(17) = 0 <0.08>
close(19) = 0 <0.07>
waitpid(9331, 0xbfc825f0, WNOHANG|WSTOPPED) = 0 <0.06>
kill(9331, SIGTERM) = -1 EPERM (Operation not permitted)
<0.06>
kill(9331, SIGKILL) = -1 EPERM (Operation not permitted)
<0.05>
waitpid(9331, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WSTOPPED) = 9331
<0.21>
--- SIGCHLD (Child exited) @ 0 (0) ---
poll([{fd=14, events=POLLIN}], 1, 15000) = 1 ([{fd=14, revents=POLLIN}])
<0.008233>
read(14, "GET /styles/screen.css HTTP/1.1\r\n"..., 8000) = 659 <0.07>
gettimeofday({1257875417, 523164}, NULL) = 0 <0.05>
stat64("/var/lib/tomcat-*/webapps//styles", 0xbfc824b0) = -1 ENOENT (No such
file or directory) <0.09>
stat64("/home/troy/public_html/styles/screen.css", {st_mode=S_IFREG|0644,
st_size=2400, ...}) = 0 <0.10>
open("/home/troy/public_html/.htaccess", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1
ENOENT (No such file or directory) <0.09>
open("/home/troy/public_html/styles/.htaccess", O_RDONLY|O_LARGEFILE|O_CLOEXEC)
= -1 ENOENT (No such file or directory) <0.08>
open("/home/troy/public_html/styles/screen.css/.htaccess",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOTDIR (Not a directory) <0.08>
open("/home/troy/public_html/styles/screen.css",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 16 <0.10>
fcntl64(16, F_GETFD)= 0x1 (flags FD_CLOEXEC) <0.05>
fcntl64(16, F_SETFD, FD_CLOEXEC)= 0 <0.05>
close(16) = 0 <0.06>
writev(14, [{"HTTP/1.1 304 Not Modified\r\nDate: "..., 172}], 1) = 172
<0.18>
read(14, 0x821c170, 8000) = -1 EAGAIN (Resource temporarily
unavailable) <0.06>
write(9, "10.49.220.36 - - [10/Nov/2009:10:"..., 86) = 86 <0.12>
poll([{fd=14, events=POLLIN}], 1, 15000) = 1 ([{fd=14, revents=POLLIN}])
<3.503299>
read(14, "GET /styles/print.css HTTP/1.1\r\nH"..., 8000) = 658 <0.08>
gettimeofday({1257875421, 27117}, NULL) = 0 <0.05>
stat64("/var/lib/tomcat-*/webapps//styles", 0xbfc824b0) = -1 ENOENT (No such
file or directory) <0.11>
stat64("/home/troy/public_html/styles/print.css", {st_mode=S_IFREG|0644,
st_size=2340, ...}) = 0 <0.10>
open("/home/troy/public_html/.htaccess", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1
ENOENT (No such file or directory) <0.10>
open("/home/troy/public_html/styles/.htaccess", O_RDONLY|O_LARGEFILE|O_CLOEXEC)
= -1 ENOENT (No such file or directory) <0.08>
open("/home/troy/public_html/styles/print.css/.htaccess",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOTDIR (Not a directory) <0.09>
open("/home/troy/public_html/styles/print.css", O_RDONLY|O_LARGEFILE|O_CLOEXEC)
= 16 <0.10>
fcntl64(16, F_GETFD)= 0x1 (flags FD_CLOEXEC) <0.06>
fcntl64(16, F_SETFD, FD_CLOEXEC)= 0 <0.05>
close(16) = 0 <0.07>
writev(14, [{"HTTP/1.1 304 Not Modified\r\nDate: "..., 172}], 1)
Re: SVN logs lost
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 lived >> copy, but doing the same once more moves you to the original place and >> shows all old logs. It seems viewvc has a config switch "cross_copies" that despite its misleading description comment seems to track revisions across copy/move. The switch defaults to "0" but will default to "1" with the next release 1.1.3. So maybe one can consider switching it in 1.1.2 or at least check, whether the old configuration should be adjusted once the next release is done and gets instaled at the ASF. Soft Drink++ Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48169] two second delay for cgi scripts mixed with mod_jk
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 drain the connection in the tcp layer, which blocks. We need to investigate a better way. I expect we don't set SO_LINGER to prevent the OS from blocking during forked cgi processes and try to handle lingering behaviour during normal worker process shutdown on our own. Additional note: strace/truss also reveals, that the cgi process and also rotatelogs try to close the shm file and its lock. But that's not the cause of the hang here. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48170] New: Unnecessary synchronization by JspFactory.getDefaultFactory contributes to stability problems
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 OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: earl.no...@nfl.com I have a soak test at constant load that is initially stable. Within the hour, an ever increasing number of blocked threads develops. The vast majority of threads are in JSP rendering, blocked on JspFactory.getDefaultFactory(). The server eventually crashes. We are running Java 6. Upon code inspection, there appears to be no real reason for synchronizing the getDefaultFactory() and setDefaultFactory() as the setter is called only once upon startup when the sub-class loads. Patching the jar, I tried three other experiments: 1) Removing the synchronized keyword entirely. 2) Locking on an inner static class instead of the JspFactory.class. 3) Using volatile for the static member variable. Both experiments #1 and #3 showed vastly better stability. I was able to double the throughput of the server without seeing increasing number of blocked threads. Experiment #2 yielded the same behavior as the original code. Thus, no other code is synchronizing on JspFactory.class. Rather, there seem to be some sort of contention in the java.lang.Class monitor. Using volatile would preserve the multi-threading semantics while avoiding contributing to the instability issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r834289 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
"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 it on a different connection. But I admit that I haven't tried to
write a program that simulates the attack.
> On Mon, Nov 9, 2009 at 7:49 PM, Bill Barker
> wrote:
>
>>
>> wrote in message
>> news:20091110010244.4f8382388...@eris.apache.org...
>> > Author: costin
>> > Date: Tue Nov 10 01:02:43 2009
>> > New Revision: 834289
>> >
>> > URL: http://svn.apache.org/viewvc?rev=834289&view=rev
>> > Log:
>> > Fix for the SSL midm - disable client re-negotiation, connection will
>> > be
>> > closed.
>> >
>> >
>> > Modified:
>> >
>> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
>> >
>> > Modified:
>> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=834289&r1=834288&r2=834289&view=diff
>> >
>> ==
>> > ---
>> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
>> > (original)
>> > +++
>> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
>> > Tue Nov 10 01:02:43 2009
>> > @@ -42,6 +42,8 @@
>> > import java.util.Vector;
>> >
>> > import javax.net.ssl.CertPathTrustManagerParameters;
>> > +import javax.net.ssl.HandshakeCompletedEvent;
>> > +import javax.net.ssl.HandshakeCompletedListener;
>> > import javax.net.ssl.KeyManager;
>> > import javax.net.ssl.KeyManagerFactory;
>> > import javax.net.ssl.ManagerFactoryParameters;
>> > @@ -93,6 +95,9 @@
>> > private static final int defaultSessionCacheSize = 0;
>> > private static final int defaultSessionTimeout = 86400;
>> >
>> > +private static final boolean midmMode =
>> > +
>> > "true".equals(System.getProperty("enable_ssl_mitm_vulnerability"));
>> > +
>> > static org.apache.juli.logging.Log log =
>> >
>> > org.apache.juli.logging.LogFactory.getLog(JSSESocketFactory.class);
>> >
>> > @@ -154,12 +159,34 @@
>> > SSLSocket asock = null;
>> > try {
>> > asock = (SSLSocket)socket.accept();
>> > + if (!midmMode) {
>> > + asock.addHandshakeCompletedListener(
>> > + new DisableSslRenegotiation());
>> > + }
>> > configureClientAuth(asock);
>> > } catch (SSLException e){
>> > throw new SocketException("SSL handshake error" +
>> e.toString());
>> > }
>> > return asock;
>> > }
>> > +
>> > +private static class DisableSslRenegotiation
>> > +implements HandshakeCompletedListener {
>> > +private volatile boolean completed = false;
>> > +
>> > +public void handshakeCompleted(HandshakeCompletedEvent event)
>> > {
>> > +if (completed) {
>> > +try {
>> > +log.warn("SSL renegotiation is disabled, closing
>> > connection");
>> > +event.getSocket().close();
>>
>> This is just a nuisance. The black-hat can simply reconnect and request
>> to
>> resume the session. At the very least, the session would need to be
>> invalidated as well. But from what I've read, even this isn't a very
>> effective mitigation tactic. Since we are notified after the handshake
>> is
>> done, the black-hat already has all the information she needs to continue
>> the attack.
>>
>> > +} catch (IOException e) {
>> > +// ignore
>> > +}
>> > +}
>> > +completed = true;
>> > +}
>> > +}
>> > +
>> >
>> > @Override
>> > public void handshake(Socket sock) throws IOException {
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834745 - /tomcat/tc6.0.x/trunk/STATUS.txt
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=834745&r1=834744&r2=834745&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Nov 11 02:54:04 2009 @@ -394,7 +394,7 @@ * Disable TLS renegotiation be default with an option to re-enable it Based on Costin's patch for trunk with Mark's modifications http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch - +1: markt + +1: markt, billbarker -1: * Improvements to memory leak prevention - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL & Tomcat
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 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 and NIO connectors) - Don't use SSL configs that require renegotiation. i.e. SSL config should be the same for the entire host. Sites that require SSL in some places and SSL + CLIENT-CERT in others will require reconfiguration. Sites that require SSL for some parts should be OK. - Keep watch for a Sun update to the JDK that may help address the issue SSL using tc Native - tcnative does not support renegotiation (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now users of tc native with SSL should be OK We also need to think about what to do with tc native. Maybe something like: - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is disabled) - keep an eye on httpd and if they find a work-around, copy it and release 1.1.18 with renegotiation enabled For now, I'm not proposing any changes to the docs although we may want to put a summary of the advice - once agreed - on the security pages. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL & Tomcat
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 > 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 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 and NIO connectors) >> - Don't use SSL configs that require renegotiation. i.e. SSL config >> should be the same for the entire host. Sites that require SSL in some >> places and SSL + CLIENT-CERT in others will require reconfiguration. >> Sites that require SSL for some parts should be OK. >> - Keep watch for a Sun update to the JDK that may help address the issue >> >> SSL using tc Native >> - tcnative does not support renegotiation >> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now >> users of tc native with SSL should be OK >> >> >> We also need to think about what to do with tc native. Maybe something >> like: >> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is >> disabled) >> - keep an eye on httpd and if they find a work-around, copy it and >> release 1.1.18 with renegotiation enabled >> >> For now, I'm not proposing any changes to the docs although we may want >> to put a summary of the advice - once agreed - on the security pages. >> >> Thoughts? >> >> Mark >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
svn commit: r834790 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/ha/session/DeltaSession.java webapps/docs/changelog.xml
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/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=834790&r1=834789&r2=834790&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Nov 11 07:38:48 2009
@@ -190,11 +190,6 @@
+1: fhanik, kkolinko, rjung
-1:
-* Fix ReplicationValve CrossContext support
- http://svn.apache.org/viewvc?rev=831718&view=rev
- +1: pero, rjung, funkman
- -1:
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48097
Alternative patch that adds a new PrivilegedAction. The test case provided
passes with this patch
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=834790&r1=834789&r2=834790&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Wed Nov 11 07:38:48 2009
@@ -370,6 +370,17 @@
return (this.isValid);
}
+/**
+ * End the access and register to ReplicationValve (crossContext support)
+ */
+public void endAccess() {
+ super.endAccess() ;
+ if(manager instanceof DeltaManager) {
+((DeltaManager)manager).registerSessionAtReplicationValve(this);
+ }
+}
+
+
// - Session Public Methods
/**
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=834790&r1=834789&r2=834790&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Wed Nov 11 07:38:48 2009
@@ -367,6 +367,9 @@
+DeltaSession needs endAccess that CrossContext replication work. (pero)
+
+
DeltaManager needs to replicate changed attributes even if session
gets invalidated. Otherwise session listeners will not see the right
data on the secondary nodes. (rjung)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r834794 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
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.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java?rev=834794&r1=834793&r2=834794&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESupport.java Wed Nov
11 07:56:01 2009
@@ -157,8 +157,8 @@
ssl.startHandshake();
int maxTries = 60; // 60 * 1000 = example 1 minute time out
for (int i = 0; i < maxTries; i++) {
-if(log.isTraceEnabled())
-log.trace("Reading for try #" +i);
+if (log.isTraceEnabled())
+log.trace("Reading for try #" + i);
try {
in.read(b);
} catch(SSLException sslex) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
