Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 8/8/13 5:47 PM, David Landis wrote: On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz ch...@christopherschultz.net wrote: ... and the SSLDisableCompression setting (when set to false) is intended to mitigate the CRIME attack against SSL/TLS compression. Feel free to read online all about the CRIME attack. That was what I was hoping it did when I asked the original question :) I haven't really done any analysis of SSL compression (that is, compression as implemented by the TLS/SSL layer) alone versus compression-less-SSL + gzip, but I suspect that any combination of compression and encryption can lead to CRIME-like attacks ... That seems to be true since there is now the BREACH attack: http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ which (I think) is compression-less-SSL + gzip. It is compression + deflate as explained in the article, but gzip basically works the same way (LZ77 + Huffman). It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOWnAAoJEBzwKT+lPKRYuMoP/0cFjaVbiLs+Qw3QQS/z/A0p mq/5QTNhsUqSsRmhnjAThGSBZPCpXB9We9ecTqV1moxR9iG94x/oya/3yToYmJ1r Msat1HB97YRotPxyWCweZ2nllTPshlkyTnhojcD18csnA0pAfn/LzqimRXFelX2f Vnkgoygb6qL5f6fIMpVVWrjzn1BsAGQxjNQwJtteimLC1GE7sYOarQ4MuqMrQzM2 /5tqOpJQnVgZRL+IdqNLHpYWGx8FhonV6KDXlVTAkl6LOgTWpVlWNrHzq8/wFpxO 3XssLKcO2oHm2mGvD8c6ivRwvVjvZlQd1VapamJpIxGl+ezlbyLwPx0USiIUrcNO m6uyO1I9Zq9Vw63VMwbatYqA3nTqNwKhdaMl3H7jj4KJDxVyr/0RUNIuUu4+yECZ XLUpSucIluDL90BrXfvYaSf8yCbkRBhk5fW9IgzDOOgXFlQNsYdb5RGtFxksIb24 irmiv4naxNKqBdyvVPDvib7hXwAAX4K8xhYitv7gakpCS7JPZrWA7hFl5YCdt7H7 pnCGLXTiyMpTRhQ7WNDm7sCFLD1YL67axRHBm1nMSbxOBwR3CiZ5UINOlqyj3Wp7 ZDZQNkdF0NBK9XL5J4fyapXDGYX+N6y0ikK1bR24qncrPuVq6RNkpJ04UlWWENq9 wzgcOoLG/iO4WpuAcoJC =iH73 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 8/8/13 8:20 PM, Martin Gainty wrote: as earlier mentioned chrome is the only browser that supports compression on SSL streams Mozilla Firefox had implemented TLS+compression for SPDY requests, and thus was vulnerable. Since CRIME, both browsers have disabled compression for TLS. Disabling TLS compression whilst enabling gzip compression merely re-enables a similar attack that had been mitigated by disabling SSL compression in the first place. So, it doesn't matter what browser you use, since you can usually bet that the client supports gzip and/or deflate compression for Content-Encoding. (Well, you don't have to bet, since the client advertises that fact via Accept-Encoding). The point is that this is not something most people are safe from due to their browsers' inabilities. On the contrary: swapping TLS compression with regular compression has given this attack much wider applicability. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOeeAAoJEBzwKT+lPKRY4GEQAJb9odexFRiOncyPUJpoW/Cr yhQGyrDD606jcfhtv029BWw8RB2fRK0Efo03+0LJ8auGA9jPdD/u/aZYWBmzUcm6 w7fNR+zk288OjHpfU0PQ0c7ypK1vcEpVw57+f6aqMsdw/MaSlhQLX9ducsUZRzu2 TrHBlJPngu17HK9y5jg9i0YHJ6wMbvfD+8Dk17NoabthxgO3An9CNznp7IYSCyx2 9Y8dVT6d6W538JMgm+Ov+iAYwoZNslnKDo46bqHXbeuLo5VAn8wmisY+tW9QmbdP cVsl6I+E2WGKGt2TvWGYwODKDCyxgDkLXjFRp13vpkpFTmYsvLSbiajJsur/kO1H qcTq0ygdtoMe8waiB/eXbZx0aWVsfG90R7SaiUsznR3lTJfFPrDst3IuOJgafLIw t1KvU3p1AcbFhAXZG3Oo9Ltwm3rxYvNuGi4eD8Khq8JOiMk4P+hhQwN30jCno7X6 0bV/tbIlp1SfU3SNFjUESIG4GIJGNUIOVuW8Ga1s1/8HQhMVnjHDG6eapeW0OS1h srC3RKmPvWo0BEs4XmDanmssGqeOBZmhgO1SDGi/aY9Jl/NQVkBApzfdaJ1eDUB2 PfTzSOUz2SFEJy5nwkWR0y0S4hoN4i8sVgrqtUtmRZIzuqFr+SJlaIxfujzNWaxS 3X77ZRaLZXxUdEEV1HKR =44Ps -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a fuss. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBO5wAAoJEBzwKT+lPKRYxakP/2PXSoCBrzgvVjkKrmvOh2Ag 5IVuP5eoIVpTT/ud6d8/uYDnSVSA/OI64lFZqZDwuiu11XnMC/uxDc/O4cfbCxA4 AYu0BgY/NDPUCAyPIcjujP22oBZibvYVr9RFrTFHdtmAaVT7KiLglCUaJzxuZtt7 6/A1+y4Q5X+g40fukNtIbwW7Of3hA2KNPeWt5s6aivYaUdQDfdYfMYh+kED+JMhS HKpmaEBoj0KwOAv5iKbWaVphe+ZuFuqnLJq82GbJqWsiwQ3uykK0x/gAI9tmWe4D SwpSszi5jwyv8SAoewyNLQr0ojNlzwkftVOrBEFyijfCAhu86xPHGDn1QghFQEpg ALXn0oMQkeP7zVfxv4f2ID/u5iOtkT2O8G/jeq3jA08Ide7qi1+kNsWZyrvGS9r7 qkCoE9GayRgGKIEAS+mJLMhJ28ttJ4wvugSpsaSSNOu6CTWIY5mnlovbpPir18GN uZCKMofeIn/fHAROFiHyFudP00z/uxX8r//gCCo0rcwcXRMUS/lxHZJNjYDL+ACA QFiSWvgAlm8JWEpgF2DjckIND5ZoFvBS5KztkLlbZCeqzw9iSA/FY4r7EqfbQ0Rj Nr9yvDGONDzgUp2BwHJIcYKIB5QQnSD1JfshVn//hv7Cm7v1GoA0b71Kkb2V+3s+ wZQf5DcDObBEck5VG2qE =xEbv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 09/08/2013 15:28, Christopher Schultz wrote: Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a fuss. fuss was a reference to how some folks are reacting to this new attack, BREACH. First it isn't new, second it isn't (in my view) practical. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 11:10 AM, Mark Thomas wrote: On 09/08/2013 15:28, Christopher Schultz wrote: Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a fuss. fuss was a reference to how some folks are reacting to this new attack, BREACH. First it isn't new, second it isn't (in my view) practical. Fair enough. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. I tend to agree: being able to both remotely monitor the victim's traffic *and* remotely-control the browser means that you already have quite a bit of control over the situation. Perhaps decrypting the SSL stream isn't the worst thing an attacker in such a position can accomplish. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Agreed. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRAUAAoJEBzwKT+lPKRYKMsP/3ye2X1m8oZGMxDfjhOxLr+B xRS1SycborjXnEhAXnGAx+U1jFDzKPWQ0AdDMd2o4NKPqS6jWJTQ37CBeXN+25y2 0+FxZKP9FwrY94qY/dCNHK70nuUda6hpcGcpWRc78swh+hUnBzB0ue52WaaWjTJH DfTPcRu1zvIeXj1zylIG4GebqKOH1+5P+NgL37+hnzoIwGmsgJ2FeVpAXELrrtZJ wOcYguKLv0NrqkAx7CvZDmtr6a4ZpZvmyXpVGJlaoi/ejmQzDvtZDOFlsBaYOMwc 4HsweP4mEi7Ms3QYBzn9naVFXr1x+saaoO75F0jnRGE9yLJXbkhGgmpLM/+arnhO /laV3ZMqHLXZYu+cmZvD/JsdL2liAaMPcwEB3c1ebFuTI8ro7+/7qlVx+H2inGew 2DIvWePjAXyKuudL8GqqHTcsbe6nrbpB41fqRyWCBSxtZwLbUfxgfjfXRQOfkX5e 88f2FmL7/BHq7YgO368rreZWx+RVze2SVv7nGm20M7LzEP6Dd2k7etca+K+KdS9L ndNs4yHAtK8328dPsCsIYwcI767Y/5qTV3UIV0Bz8YDfjSYZvDQYVlCQRHs1VA/A xisZptwRA1jZro3WrTlgzjdHfTOcxIYDaL65eZUXcjGgXB2T9YeIAfguf7PFK5wC I6LlkxLa23oMvDL7Z2+c =RJjz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 8/9/2013 8:10 AM, Mark Thomas wrote: On 09/08/2013 15:28, Christopher Schultz wrote: Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a fuss. fuss was a reference to how some folks are reacting to this new attack, BREACH. First it isn't new, second it isn't (in my view) practical. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. I was reading about the pineapple wifi mark iv the other day. It looks to be a particularly powerful piece of pen testing equipment. This tool in a coffee shop would probably be all you need to have a good chance at e). In short, don't do banking (or other sensitive work) at a coffee shop when the pages are a mix of HTTP and HTTPS. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark I'm not a security person, nor do I play one online. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 12:17 PM, Mark Eggers wrote: On 8/9/2013 8:10 AM, Mark Thomas wrote: On 09/08/2013 15:28, Christopher Schultz wrote: Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a fuss. fuss was a reference to how some folks are reacting to this new attack, BREACH. First it isn't new, second it isn't (in my view) practical. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. I was reading about the pineapple wifi mark iv the other day. It looks to be a particularly powerful piece of pen testing equipment. This tool in a coffee shop would probably be all you need to have a good chance at e). In short, don't do banking (or other sensitive work) at a coffee shop when the pages are a mix of HTTP and HTTPS. Lots of people will stupidly connect to any unencrypted WiFi when they are out and about. I'd say this is a fairly plausible attack vector. Note that unencrypted + encrypted traffic is not necessary. You can just look over someone's shoulder to see what bank they're using. These days in the US most people use one of only like 5 banks. (It's kind of sad.) Once you know the site that is being used, just browse there yourself and attempt to login: you can probably see what kind of authentication / session tracking is being used without tricking the target into revealing that kind of information to you via HTTP (i.e. without HTTPS). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRr1AAoJEBzwKT+lPKRYxHwP/2WZmt7P+gtsiZ2Qx/S+idmr xN+k/XHS4kaxWOBdo8sK3lzZYE9mB5ROtsuVYQQZ1WRJaQS0Vb09/VCJ4GnpOSFf SR9aThyAXCxnnxF2vviTZUL93Dwh0LM/HwbRGpjYy5Tns0+qXATwm1IBNK3jzarF Mvx2SOrMAGqiTEet9CqW/7yYQV31kFpLaZGiDsdJT6FM+mBG8OrVcYstBr0b6qXF LC2IILQshvHvcAUmAEDDPO8NRfgxCY+4uzY9M028DromKeliAQ7PO0KD4E3nErZZ xL5ysEgSKSahd+0a1QJRXvLccb4XRLL9GCcSP9/TvUzqbOahWUDrIHgLGJWZYAfS ql4nO2QLtVDfTdtgBUyuNQsn+AlJZHR96g/N7lHuxZU8fap5Auir8xFijWDRWrdn LfykGonHPZ75UDlOFQmMUPM/8H6AFbymw9R8ZhpbCMwEPAU/SqVARbCLAThIVQWN zrroWjVqMLdUTbdqvT3Xi9EnmXkPuszHGjqQRtVgt60MRRZ63bkM8+F2hnJGlSId VpUFi6RrK0wM4TFd2viGlW7SbSbl/vSHAPruAYzwAJvkI+g2QduW8HVV4lESyZ+T C9vVnz59BJwsokc5H3ykNCcnurkaWCBwEm70LTc9MQKlS8ICyOtKX31TugZvzPKv EiJZhuKGsOZR/+lf3ser =98t0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat config question: 'compression' versus 'SSLDisableCompression'
Hi, I was wondering if someone could clarify the difference between the configuration parameters mentioned in the subject of this email or point me to some documentation that explains it? Do they both refer to the same type of compression? Based on the Tomcat docs I know the former controls whether or not the connector uses gzip compression. Regarding the latter, the Tomcat docs say: Disables compression if set to true and OpenSSL supports disabling compression.. Is that referring to a different type of compression? Here is the behavior I'm seeing: --compression=on and SSLDisableCompression=false, the responses are gzip'd --compression=on and SSLDisableCompression=true, the responses are gzip'd --compression=off and SSLDisableCompression=false, the responses are not gzip'd Environment: Tomcat 7.0.40 Java 7 RHEL (Linux) APR/native connector with SSL OpenSSL 1.0.0 APR 1.4.8 server.xml example: ?xml version='1.0' encoding='utf-8'? Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JasperListener / Service name=Catalina Connector port= redirectPort=8443 URIEncoding=UTF-8/ Connector port=8443 scheme=https URIEncoding=UTF-8 secure=true compression=on compressableMimeType=text/html,. SSLEnabled=true SSLCertificateFile=cert.pem SSLCipherSuite=ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW:... SSLDisableCompression=true/ /Service /Server
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 08/08/2013 18:14, David Landis wrote: Hi, I was wondering if someone could clarify the difference between the configuration parameters mentioned in the subject of this email or point me to some documentation that explains it? Do they both refer to the same type of compression? No. Based on the Tomcat docs I know the former controls whether or not the connector uses gzip compression. Regarding the latter, the Tomcat docs say: Disables compression if set to true and OpenSSL supports disabling compression.. Is that referring to a different type of compression? Yes. The Tomcat connector implements compression. The SSL/TLS protocol has a separate compression implementation. I'd guess (no testing to back this up) that you'd be better off with using the connector compression as you can tailor that to the correct mime-types. I'd also guess that if you have one, enabling the other doesn't buy you much. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/8/13 12:45 PM, Mark Thomas wrote: On 08/08/2013 18:14, David Landis wrote: Hi, I was wondering if someone could clarify the difference between the configuration parameters mentioned in the subject of this email or point me to some documentation that explains it? Do they both refer to the same type of compression? No. Based on the Tomcat docs I know the former controls whether or not the connector uses gzip compression. Regarding the latter, the Tomcat docs say: Disables compression if set to true and OpenSSL supports disabling compression.. Is that referring to a different type of compression? Yes. The Tomcat connector implements compression. The SSL/TLS protocol has a separate compression implementation. ... and the SSLDisableCompression setting (when set to false) is intended to mitigate the CRIME attack against SSL/TLS compression. Feel free to read online all about the CRIME attack. I'd guess (no testing to back this up) that you'd be better off with using the connector compression as you can tailor that to the correct mime-types. I tend to agree. You can also disable compression on files that are small enough that compression doesn't really buy you anything. I'd also guess that if you have one, enabling the other doesn't buy you much. +1 I haven't really done any analysis of SSL compression (that is, compression as implemented by the TLS/SSL layer) alone versus compression-less-SSL + gzip, but I suspect that any combination of compression and encryption can lead to CRIME-like attacks ... which by the way requires the attacker to basically have remote-control access to the user's client (to force it to make requests to the server) and also be able to sniff the encrypted packets at the same time (which is of course quite a bit easier to do than client-control). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBAtXAAoJEBzwKT+lPKRYk3UP/jEcRvBxDLvdDT+4YGWVStmY IQ/cjla4La2betDx6pNTXokYD9en8yFJ7hqPk0c/CyCXgzw7mH6FGjAsjKkHhGFg m9XEkclWJ+T+uaGO9S/0wcsZ8iSs3luRhSF3qqsGnyuk2HlSSTw5nkpm22Wv1Rit jb9iLqAzU2K9aKuZJson/xiva/0iOQuJknu9zD3MzvMxfSPB8bpUwkq/T77jFkU+ COZ+pfLYU9NbyURKNW2EREfbRYYTKQQ7WEHwVVPPrSxRlBM0lnnRaqxKoFHVR1rK P0wRPqr4bAFAbTtQ+ylZUsInUcStAyuHkEwFzHRpWkfcEuu+uQKzDimukY7PG4d0 llblQ67KYLad+VahA6JIMZV1evuAgL9PsMaCNvOFZloxwz+1Sxnf2olk6RR6w8Ge q/Y7K9MtTiSAkA+i0DH9Wr43RpjfR2d8LjP4IZXAaiAAEO3AXfHXX/KOJJ/px9k8 mo0eBsPxr1WRYbECxuozKf9kYjQEaw15nGtWCnTWZ4O5oPepppu2hd8GERqUIAln 9HR6NozOnPvrEGEhvjy1GG/pMfUZGKf9a/foZbjl2/ZrlQGaj+EXkDceX6DWXXrC meQT4RmyX4SqHvYaiy2Hu8E/i9/JZM3xdccjWafO4oz6Z7olISVHM3l9PCUrjq6q QHrVkwxu3OJeBBteSyNe =uc9W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz ch...@christopherschultz.net wrote: ... and the SSLDisableCompression setting (when set to false) is intended to mitigate the CRIME attack against SSL/TLS compression. Feel free to read online all about the CRIME attack. That was what I was hoping it did when I asked the original question :) I haven't really done any analysis of SSL compression (that is, compression as implemented by the TLS/SSL layer) alone versus compression-less-SSL + gzip, but I suspect that any combination of compression and encryption can lead to CRIME-like attacks ... That seems to be true since there is now the BREACH attack: http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ which (I think) is compression-less-SSL + gzip.
RE: Tomcat config question: 'compression' versus 'SSLDisableCompression'
as earlier mentioned chrome is the only browser that supports compression on SSL streams Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Date: Thu, 8 Aug 2013 17:47:36 -0400 Subject: Re: Tomcat config question: 'compression' versus 'SSLDisableCompression' From: dlan...@gmail.com To: users@tomcat.apache.org On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz ch...@christopherschultz.net wrote: ... and the SSLDisableCompression setting (when set to false) is intended to mitigate the CRIME attack against SSL/TLS compression. Feel free to read online all about the CRIME attack. That was what I was hoping it did when I asked the original question :) I haven't really done any analysis of SSL compression (that is, compression as implemented by the TLS/SSL layer) alone versus compression-less-SSL + gzip, but I suspect that any combination of compression and encryption can lead to CRIME-like attacks ... That seems to be true since there is now the BREACH attack: http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ which (I think) is compression-less-SSL + gzip.
Re: Tomcat Config Question
On 15/12/2009 04:17, steflik wrote: Chuck, OK, I've read the document several times and still can't figure out what it is you are trying to tell me. I'm not using WARs so /META-INF/? doesn't come into play. If theContext statements don't go in to server.xml where should I put them, context.xml doesn't seem to be the appropriate place? A web app in the form of a directory is just an exploded/uncompressed WAR. Putting a META-INF directory inside the app dir still applies. Try it and see. (The manager host-manager apps preinstalled in Tomcat also use a META-INF directory.) p Dick Steflik Binghamton University Caldarale, Charles R wrote: From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move thecontext statements out of server.xml and into context.xml? It'sContext notcontext - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
Chuck, I'm a little bit hesitant as a number of the students are still struggleing to get their JSP project done. Right now the server is running and the Context statements that define where the apps are are right at the end of server.xml. This is an example of a Context ststement as they are currently in server.xml: Context docBase=/home/alti/public_html/alti path=/alti debug=0 reloadable=true crossContext=true/Context If this is moved out of server.xml and into /home/alti/public_html/alti/META_INF/ how will Tomcat know where the alti app is; I always thought that Tomcat followed the paths it found in server.xml to figure out where all of the apps were.? If this is where it goes what name does the file get context.xml or alti.xml? Dick Steflik Binghamton University Pid Ster wrote: On 15/12/2009 04:17, steflik wrote: Chuck, OK, I've read the document several times and still can't figure out what it is you are trying to tell me. I'm not using WARs so /META-INF/? doesn't come into play. If theContext statements don't go in to server.xml where should I put them, context.xml doesn't seem to be the appropriate place? A web app in the form of a directory is just an exploded/uncompressed WAR. Putting a META-INF directory inside the app dir still applies. Try it and see. (The manager host-manager apps preinstalled in Tomcat also use a META-INF directory.) p Dick Steflik Binghamton University Caldarale, Charles R wrote: From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move thecontext statements out of server.xml and into context.xml? It'sContext notcontext - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Tomcat-Config-Question-tp26711131p26794592.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
I'm assuming your docBase for this app is not inside tomcat's webapps folder and in that case, you're right to wonder how tomcat finds the context.xml file. The Context ... .../Context element can also be in it's own file named after the path attribute - i.e. alti.xml in conf/Catalina/localhost. Replace 'Catalina' with your tomcat's Service name from server.xml and 'localhost' with your Host name, again from server.xml. Tomcat looks there as well for the webapp's Context .../Context element and you can remove the path attribute. --David steflik wrote: Chuck, I'm a little bit hesitant as a number of the students are still struggleing to get their JSP project done. Right now the server is running and the Context statements that define where the apps are are right at the end of server.xml. This is an example of a Context ststement as they are currently in server.xml: Context docBase=/home/alti/public_html/alti path=/alti debug=0 reloadable=true crossContext=true/Context If this is moved out of server.xml and into /home/alti/public_html/alti/META_INF/ how will Tomcat know where the alti app is; I always thought that Tomcat followed the paths it found in server.xml to figure out where all of the apps were.? If this is where it goes what name does the file get context.xml or alti.xml? Dick Steflik Binghamton University Pid Ster wrote: On 15/12/2009 04:17, steflik wrote: Chuck, OK, I've read the document several times and still can't figure out what it is you are trying to tell me. I'm not using WARs so /META-INF/? doesn't come into play. If theContext statements don't go in to server.xml where should I put them, context.xml doesn't seem to be the appropriate place? A web app in the form of a directory is just an exploded/uncompressed WAR. Putting a META-INF directory inside the app dir still applies. Try it and see. (The manager host-manager apps preinstalled in Tomcat also use a META-INF directory.) p Dick Steflik Binghamton University Caldarale, Charles R wrote: From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move thecontext statements out of server.xml and into context.xml? It'sContext notcontext - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
On 15/12/2009 13:15, steflik wrote: Chuck, I'm a little bit hesitant as a number of the students are still struggleing to get their JSP project done. Right now the server is running and the Context statements that define where the apps are are right at the end of server.xml. This is an example of aContext ststement as they are currently in server.xml: Context docBase=/home/alti/public_html/alti path=/alti debug=0 reloadable=true crossContext=true/Context If this is moved out of server.xml and into /home/alti/public_html/alti/META_INF/ how will Tomcat know where the alti app is; I always thought that Tomcat followed the paths it found in server.xml to figure out where all of the apps were.? If this is where it goes what name does the file get context.xml or alti.xml? Maybe this would be useful: look at User Web Applications http://tomcat.apache.org/tomcat-6.0-doc/config/host.html p Dick Steflik Binghamton University Pid Ster wrote: On 15/12/2009 04:17, steflik wrote: Chuck, OK, I've read the document several times and still can't figure out what it is you are trying to tell me. I'm not using WARs so /META-INF/? doesn't come into play. If theContext statements don't go in to server.xml where should I put them, context.xml doesn't seem to be the appropriate place? A web app in the form of a directory is just an exploded/uncompressed WAR. Putting a META-INF directory inside the app dir still applies. Try it and see. (The manager host-manager apps preinstalled in Tomcat also use a META-INF directory.) p Dick Steflik Binghamton University Caldarale, Charles R wrote: From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move thecontext statements out of server.xml and into context.xml? It'sContext notcontext - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dick, On 12/15/2009 8:15 AM, steflik wrote: I'm a little bit hesitant as a number of the students are still struggling to get their JSP project done. Right now the server is running and the Context statements that define where the apps are are right at the end of server.xml. My recommendations: 1. Have your students submit a WAR file that you install under the auto-deploy webapps. You can call it 'cschultz.war' for me, for example. The students (and you) can access it via http://host/cschultz/ 2. No META-INF/context.xml is required if there's nothing special to add. I see you have: Context docBase=/home/alti/public_html/alti path=/alti debug=0 reloadable=true crossContext=true/Context If the Context is in META-INF/context.xml, then the docBase and path attributes are forbidden. debug is meaningless (you must be looking at old documentation if you've read anything about a debug attribute), relodable=true is the default, and crossContext=true is probably unnecessary (feel free to convince me). This constitutes a Context with nothing special. As such, the webapp /does not need to have a META-INF/context.xml file/. So, let's say I'm you and I want to configure my server to support this. Here's what I do: 1. Remove all Context elements from Tomcat's conf/server.xml file. 2. Make sure that there is a Host with autoDeploy=true and appBase=somewhere (webapps is not a bad choice). 3. When a student submits a webapp WAR file (see below), drop it into the webapps directory and it will auto-deploy. If you are a student, you do this: $ ls index.jsp my-great-example.jsp easter-egg.jsp $ jar cvf cschultz.war *.jsp $ echo Professor, Please find attached my submission for assignment 1.1. Thanks, - -chris | mutt -a cschultz.war stef...@binghamton.edu Now, to answer your other questions: If this is moved out of server.xml and into /home/alti/public_html/alti/META_INF/ how will Tomcat know where the alti app is; I always thought that Tomcat followed the paths it found in server.xml to figure out where all of the apps were.? Yes, but you can also use auto-deploy. The auto-deployer looks for changes in the webapps directory (new directories or WAR files) and deploys them. Any previously-deployed webapp is checked for changes (.class or .jar file changes) and re-deployed if necessary. Another option is to put the file into Tomcat's configuration directory instead of within the WAR file (or exploded webapp deployment directory). In that case, you put the file into conf/[service]/[host]/[appname].xml That file will have a docBase that points either to a WAR file or an exploded WAR structure on the disk. The name of the .xml file dictates the deployment path, so the path attribute is forbidden. If you need to have the students copy their own WAR files (or exploded WAR structures) somewhere specific, you could set up a webapps directory that allowed them to do that using standard UNIX file permissions (though you might have to sacrifice some security, or set up something overly complicated to make it work). Another option would be to set up a Host for each student, with it's own auto-deploy webapps directory to which only that student has access. Then they are responsible for their own WAR deployment. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksnuyAACgkQ9CaO5/Lv0PDn+ACgju7+0lr9idqtcnJjhxP6hxzV Py0AoLKFb8gCWXQvUT9uhcfhYr7cVxxh =Uo7j -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
Markus, Do I just move the context statements out of server.xml and into context.xml? or is there something else I have to do. If thats all I have to do do I place them before or after the watched element tag that is already in the context.xml file? Dick Steflik Markus Schönhaber-10 wrote: 09.12.2009 15:31, steflik: I'm teaching a Web Programming course and am using Tomcat 6 for the servlet/jsp portion of the course. I have created a context for each student in the server.xml file and it seems to work pretty good but if a student modifies the web.xml file in their application I have to restart the sever before it takes effect. Is there a way to configure Tomcat so that changes in a users web.xml file will be automatically sensed by the server and take effect immediately? Adding Contexts to server.xml is strongly discouraged nowadays. Among the reasons for this discouragement is exactly the problem you're facing now. See http://tomcat.apache.org/tomcat-6.0-doc/config/context.html -- Regards mks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/Tomcat-Config-Question-tp26711131p26779949.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
On 14/12/2009 18:46, steflik wrote: Markus, Do I just move thecontext statements out of server.xml and into context.xml? or is there something else I have to do. If thats all I have to do do I place them before or after the watched element tag that is already in the context.xml file? There should be multiple context.xml, one for each webapp, in it's META-INF folder. The global conf/context.xml should contain only general settings you wish to apply to all webapps. p Dick Steflik Markus Schönhaber-10 wrote: 09.12.2009 15:31, steflik: I'm teaching a Web Programming course and am using Tomcat 6 for the servlet/jsp portion of the course. I have created a context for each student in the server.xml file and it seems to work pretty good but if a student modifies the web.xml file in their application I have to restart the sever before it takes effect. Is there a way to configure Tomcat so that changes in a users web.xml file will be automatically sensed by the server and take effect immediately? AddingContexts to server.xml is strongly discouraged nowadays. Among the reasons for this discouragement is exactly the problem you're facing now. See http://tomcat.apache.org/tomcat-6.0-doc/config/context.html -- Regards mks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Config Question
From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move the context statements out of server.xml and into context.xml? It's Context not context - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: Tomcat Config Question
Chuck, OK, I've read the document several times and still can't figure out what it is you are trying to tell me. I'm not using WARs so /META-INF/? doesn't come into play. If the Context statements don't go in to server.xml where should I put them, context.xml doesn't seem to be the appropriate place? Dick Steflik Binghamton University Caldarale, Charles R wrote: From: steflik [mailto:stef...@binghamton.edu] Subject: Re: Tomcat Config Question Do I just move the context statements out of server.xml and into context.xml? It's Context not context - case matters. or is there something else I have to do. Reading the doc would be a good first step: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -- View this message in context: http://old.nabble.com/Tomcat-Config-Question-tp26711131p26789182.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Config Question
I'm teaching a Web Programming course and am using Tomcat 6 for the servlet/jsp portion of the course. I have created a context for each student in the server.xml file and it seems to work pretty good but if a student modifies the web.xml file in their application I have to restart the sever before it takes effect. Is there a way to configure Tomcat so that changes in a users web.xml file will be automatically sensed by the server and take effect immediately? Dick Steflik Binghamton University Binghamton, NY -- View this message in context: http://old.nabble.com/Tomcat-Config-Question-tp26711131p26711131.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
09.12.2009 15:31, steflik: I'm teaching a Web Programming course and am using Tomcat 6 for the servlet/jsp portion of the course. I have created a context for each student in the server.xml file and it seems to work pretty good but if a student modifies the web.xml file in their application I have to restart the sever before it takes effect. Is there a way to configure Tomcat so that changes in a users web.xml file will be automatically sensed by the server and take effect immediately? Adding Contexts to server.xml is strongly discouraged nowadays. Among the reasons for this discouragement is exactly the problem you're facing now. See http://tomcat.apache.org/tomcat-6.0-doc/config/context.html -- Regards mks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Config Question
From: steflik [mailto:stef...@binghamton.edu] Subject: Tomcat Config Question I have created a context for each student in the server.xml file Don't do that - very strongly discouraged to have any webapp-specific information in server.xml. The Context elements should be in conf/Catalina/[host]/[appName].xml, since you likely don't want them in each webapp's META-INF/context.xml file. but if a student modifies the web.xml file in their application I have to restart the sever before it takes effect. The global conf/context.xml file should have a WatchedResource element for WEB-INF/web.xml; Tomcat should automatically restart the webapp unless you've removed that or disabled deployOnStartup in the Host element. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Config Question
The global conf/context.xml file should have a WatchedResource element for WEB-INF/web.xml; Tomcat should automatically restart the webapp unless you've removed that or disabled deployOnStartup in the Host element. In my experience, Tomcat has problems reloading webapps on occasion. This may work 80% of the time, but you are still going to have to restart Tomcat fairly often. Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net Host your tomcat app on a CentOS VPS for only $25/month! Unmetered bandwidth, 7 day free trial, Google Checkout - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
On 09/12/2009 14:52, Neil Aggarwal wrote: The global conf/context.xml file should have a WatchedResource element for WEB-INF/web.xml; Tomcat should automatically restart the webapp unless you've removed that or disabled deployOnStartup in theHost element. In my experience, Tomcat has problems reloading webapps on occasion. This may work 80% of the time, but you are still going to have to restart Tomcat fairly often. Maybe that's a side effect of your app's architecture. p Neil -- Neil Aggarwal, (281)846-8957, http://UnmeteredVPS.net Host your tomcat app on a CentOS VPS for only $25/month! Unmetered bandwidth, 7 day free trial, Google Checkout - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Config Question
2009/12/9 steflik stef...@binghamton.edu
I'm teaching a Web Programming course and am using Tomcat 6 for the
servlet/jsp portion of the course. I have created a context for each
student
in the server.xml file and it seems to work pretty good but if a student
modifies the web.xml file in their application I have to restart the sever
before it takes effect. Is there a way to configure Tomcat so that changes
in a users web.xml file will be automatically sensed by the server and take
effect immediately?
Dick, I think others have commented on creating separate context files and
adding watched resources. I'll just add the point that if I know student
code, it's going to be buggy. This could be a bigger problem than in many
web development environments. All the webapps in a servlet container run in
the same JVM, and they're not defended from each other. If someone runs the
JVM out of heap, it's gone for everyone; if a request runs forever, that
thread's locked until the server restarts; if someone puts if
(errorCondition) { System.out.println(Oops, I can't carry on from here);
System.exit(1); } then the server will suddenly stop. Yes, you can fix the
last one of these with a security manager, but there really isn't any way of
defending against buggy student code.
If you're comfortable that you can survive under those circumstances, go for
it!
- Peter
multiple Tomcat config question
Hi, I'm very new to Tomcat and web server stuff but have been asked to set up multiple instances of Tomcat on one server to talk to some database servers. I've found the existing documentation a little confusing (sorry) and was wondering if anyone would be able either to give me step-by-step advice or point me to some documentation that uses very simple language - I'm basically looking for the hand puppet version of things. My scenario is as follows: I have one web server and several database servers (possibly more to come) all on different machines in different parts of my building. I have a different web front end for each database - this is something I can't change as it's a requirement. I need to set up multiple instances of Tomcat, one for each web front end so that each front end can talk to its respective database. I also need to have this run as a service so that if the web server needs to be rebooted then all my Tomcat instances will automatically restart. My OS is Windows (XP I believe) and I'm using Tomcat 5.0 - I can't alter these because of dependencies on our current software. I was also under the impression that I had to use a connector (mod_jk?) but this wasn't hugely clear to me. My current understanding is that I need to create folders for each Tomcat instance and copy certain files from the main Tomcat into them. I also believe that I need to change the port listings within one of the files. However, I'm not much clearer on things other than that. I'm sure this is probably very simple but any assistance would be greatly appreciated. Thanks very much for your time. Chris. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Tomcat config question
Hi Cristopher, I was also under the impression that I had to use a connector (mod_jk?) but this wasn't hugely clear to me. You only need mod_jk if you want to connect Apache to Tomcat. If you are using Tomcat as standalone server, only configure Tomcat. The most important configuration file is server.xml. You will find it under c:\Path To Tomcat\conf\server.xml or /Path To Tomcat/conf/server.xml if you are using Linux. The second important file is the log file under c:\Path To Tomcat\logs. Everytime something goes wrong take a look at it. My current understanding is that I need to create folders for each Tomcat instance and copy certain files from the main Tomcat into them. You need only *one* Tomcat instance, but for each web application one context. I also believe that I need to change the port listings within one of the files. However, I'm not much clearer on things other than that. You need an connector who is listen to Port 80 or Port 8080. Open the main configuration file server.xml and add following entry: Connector port = 80 maxHttpHeaderSize= 8192 maxThreads = 150 minSpareThreads = 25 maxSpareThreads = 75 enableLookups= false redirectPort = 8443 acceptCount = 100 connectionTimeout= 2 disableUploadTimeout = true / This must be placed in the block Service/. Be shure that you run only one Tomcat and no web server, who listen to Port 80. This will cause problems. You can add other ports like 443 or 8443 to secure your connection, but try this only after you get some meanfull results :-). -- Franck -- Dipl.-Hyd. Franck Borel Universitaetsbibliothek Freiburg EMail: [EMAIL PROTECTED] EDV-Dezernat Tel. : +49-761 / 203-3908 Werthmannplatz 2 | Postfach 1629 Fax : +49-761 / 203-3987 79098 Freiburg | 79016 Freiburg - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: multiple Tomcat config question
Chris (Garwood), I need to set up multiple instances of Tomcat, one for each web front end so that each front end can talk to its respective database. As someone else on the the list mentioned, you can probably run a single instance of Tomcat with multiple contexts (webapps) defined. It's not entirely clear based upon your original message if multiple Tomcats is a requirement, but here's how to do it. I'll quote myself from a message I wrote yesterday to this same list: 1. Create a directory structure for each webapp (outside of Tomcat's installation directory) like this: struts-dev-1/ struts-dev-1/conf struts-dev-1/conf/server.xml struts-dev-1/conf/web.xml struts-dev-1/webapps struts-dev-1/logs struts-dev-1/temp ** Make sure to set your port numbers for your shutdown and connector ports to something unique among your webapps. I usually use 8x85 for the ajp13 connector port and 8x86 for the shutdown port. 2. Install your webapp to the directory struts-dev-1/webapps/struts-dev-1 3. Configure Tomcat to use struts-dev-1 as your root webapp (usually by specifying that the path is instead of /struts-dev-1). 4. Start each Tomcat instance like this: $ export JAVA_HOME=... $ export CATALINA_HOME=/path/to/full/tomcat/install $ export CATALINA_BASE=/path/to/struts-dev-1 $ export CATALINA_TMPDIR=/path/th/struts-dev-1/temp $ /path/to/full/tomcat/install/bin/startup.sh This setup allows you to have separate root webapps (or any other kind of setup). You also have the benefit (I choose to see it as a benefit) of separate JVMs and Tomcat instances. You can take one down without bothering the others. Hope that helps. I also need to have this run as a service so that if the web server needs to be rebooted then all my Tomcat instances will automatically restart. I'm not an expert on running Tomcat as a service on Windows. My understanding is that there is a utility out there that can turn any program or script into a service. Someone else on the list will have to help with that; sorry. -chris (Schultz) signature.asc Description: OpenPGP digital signature
RE: How use the archives and a TomCat config question
From: Carl T. Dreher [mailto:[EMAIL PROTECTED] Subject: How use the archives and a TomCat config question I found the archives for this list, but it consists of about 14K messages and no search mechanism. Try this one: http://marc.theaimsgroup.com/?l=tomcat-userr=1w=2 The search mechanism seems quite effective. But how do I selectively ENABLE directory listing for certain applications? Turn off listings in the global web.xml, and add servlet and servlet-mapping tags to the web.xml files of each app for which you want listings. For example: servlet servlet-nameMyAppDefault/servlet-name servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-clas s init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-namelistings/param-name param-valuetrue/param-value /init-param load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameMyAppDefault/servlet-name url-pattern//url-pattern /servlet-mapping - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How use the archives and a TomCat config question
Carl T. Dreher wrote: snip I'm sure this has been answered before, but as I said, the archives aren't much use. (By the way, it took me TWO DAYS to successfully subscribe to this list. The TomCat site has links to pages that list a variety of mailings lists. Every one I tried before this one came back as a mail failure, including, ironically, the help with this mailing list address. Also, there are zero, and I do mean ZERO, instructions on just how to subscribe. snip http://tomcat.apache.org/lists.html seems clear to me. With the mailto: links as well all you have to do is click on a link. What changes would you suggest are required to improve the clarity? This page also lists MARC as an archive which has a pretty good search interface (search was disabled for a short while recently after a system crash but this was the first time I remeber it being down). Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How use the archives and a TomCat config question
I did notice that http://tomcat.apache.org/faq/tomcatuser.html could use some cleaning. I'll try fix that soon. (Unless someone beats me too it) -Tim Mark Thomas wrote: Carl T. Dreher wrote: snip I'm sure this has been answered before, but as I said, the archives aren't much use. (By the way, it took me TWO DAYS to successfully subscribe to this list. The TomCat site has links to pages that list a variety of mailings lists. Every one I tried before this one came back as a mail failure, including, ironically, the help with this mailing list address. Also, there are zero, and I do mean ZERO, instructions on just how to subscribe. snip http://tomcat.apache.org/lists.html seems clear to me. With the mailto: links as well all you have to do is click on a link. What changes would you suggest are required to improve the clarity? This page also lists MARC as an archive which has a pretty good search interface (search was disabled for a short while recently after a system crash but this was the first time I remeber it being down). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
