You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Landis <dl...@gmail.com> on 2013/08/08 18:14:05 UTC
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'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Mark Eggers <it...@yahoo.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat config question: 'compression' versus
'SSLDisableCompression'
Posted by Martin Gainty <mg...@hotmail.com>.
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: dlandis@gmail.com
> To: users@tomcat.apache.org
>
> On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz <
> chris@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'
Posted by David Landis <dl...@gmail.com>.
On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz <
chris@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'
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org