Re: configuring ciphers for SSL Labs server test

[Mark Thomas]

On 11/05/18 03:35, Baron Fujimoto wrote:
> Yes, the host is behind an F5 load balacer, but AFAIK it should be passing
> all the TLS/SSL directly to the real host to handle.

You don't say which Tomcat version is being used. I assume one of the
8.5.x versions since the 8.5.x docs are referenced.

8.5.x should get an A from SSLLabs with the default configuration:
https://wiki.apache.org/tomcat/Security/Ciphers

I recently updated that page but 8.5.x was getting a A two years ago as
well.

Are you sure Java 8 is being used?

Mark


> 
> On Thu, May 10, 2018 at 11:23:44PM +, Scott Hoenigman wrote:
>> Are you using a load balancer?
>>
>>
>>
>> Sent from my T-Mobile 4G LTE Device
>>
>>
>>  Original message 
>> From: David Wall 
>> Date: 5/10/18 6:15 PM (GMT-06:00)
>> To: users@tomcat.apache.org
>> Subject: Re: configuring ciphers for SSL Labs server test
>>
>> We're doing good with this:
>>
>> > protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true"
>> ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
>> >
>>
>>
>> On 5/10/18 2:45 PM, Baron Fujimoto wrote:
>>> I'm trying to improve our grade on SSL Labs SSL server test[1] for our
>>> Tomcat configuraton. Currently, their report caps our grade at B because,
>>> "This server does not support Authenticated encryption (AEAD) cipher
>>> suites". They report that we support the following cipher suites:
>>>
>>> # TLS 1.2
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>
>>> # TLS 1.1
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>
>>> I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
>>> using Java 1.8.0_162, and I believe we have the Java Cryptography
>>> Extension (JCE) properly installed. I have the following connector
>>> defined (this version explicitly lists ciphers I think should satisfy the
>>> AEAD cipher requirement[2]):
>>>
>>>  >> address="0.0.0.0"
>>> port="8443"
>>> maxThreads="500"
>>> maxPostSize="10"
>>> scheme="https" secure="true"
>>> defaultSSLHostConfigName="foo.example.edu"
>>> SSLEnabled="true" >
>>>  >> protocols="TLSv1.1+TLSv1.2+TLS1.3"
>>> certificateVerification="none"
>>> honorCipherOrder="true"
>>> 
>>> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
>>> :!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA
>>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>>> :!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>>> :!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>>> :!TLS_RSA_WITH_AES_128_CBC_SHA
>>> :!TLS_RSA_WITH_AES_256_CBC_SHA
>>> :!TLS_RSA_WITH_AES_128_CBC_SHA256
>>> :!TLS_RSA_WITH_AES_256_CBC_SHA256
>>> :!TLS_RSA_WITH_AES_128_GCM_SHA256
>>> :!TLS_RSA_WITH_AES_256_GCM_SHA384
>>> :!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>> :!TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>> :TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
>>> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>>> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>>> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>>> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>>> :TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>> :TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>> :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>>> :TLS_ECDHE_RSA_WITH_AES_256_CBC_S

Re: configuring ciphers for SSL Labs server test

[Baron Fujimoto]

Yes, the host is behind an F5 load balacer, but AFAIK it should be passing
all the TLS/SSL directly to the real host to handle.

On Thu, May 10, 2018 at 11:23:44PM +, Scott Hoenigman wrote:
> Are you using a load balancer?
>
>
>
>Sent from my T-Mobile 4G LTE Device
>
>
> Original message 
>From: David Wall 
>Date: 5/10/18 6:15 PM (GMT-06:00)
>To: users@tomcat.apache.org
>Subject: Re: configuring ciphers for SSL Labs server test
>
>We're doing good with this:
>
> protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true"
>ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
>TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
> >
>
>
>On 5/10/18 2:45 PM, Baron Fujimoto wrote:
>> I'm trying to improve our grade on SSL Labs SSL server test[1] for our
>> Tomcat configuraton. Currently, their report caps our grade at B because,
>> "This server does not support Authenticated encryption (AEAD) cipher
>> suites". They report that we support the following cipher suites:
>>
>> # TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>
>> # TLS 1.1
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>
>> I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
>> using Java 1.8.0_162, and I believe we have the Java Cryptography
>> Extension (JCE) properly installed. I have the following connector
>> defined (this version explicitly lists ciphers I think should satisfy the
>> AEAD cipher requirement[2]):
>>
>>  > address="0.0.0.0"
>> port="8443"
>> maxThreads="500"
>> maxPostSize="10"
>> scheme="https" secure="true"
>> defaultSSLHostConfigName="foo.example.edu"
>> SSLEnabled="true" >
>>  > protocols="TLSv1.1+TLSv1.2+TLS1.3"
>> certificateVerification="none"
>> honorCipherOrder="true"
>> 
>> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
>> :!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA
>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> :!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>> :!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>> :!TLS_RSA_WITH_AES_128_CBC_SHA
>> :!TLS_RSA_WITH_AES_256_CBC_SHA
>> :!TLS_RSA_WITH_AES_128_CBC_SHA256
>> :!TLS_RSA_WITH_AES_256_CBC_SHA256
>> :!TLS_RSA_WITH_AES_128_GCM_SHA256
>> :!TLS_RSA_WITH_AES_256_GCM_SHA384
>> :!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>> :!TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>> :TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
>> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
>> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>> :TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>> :TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>> :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>> :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>> :TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>> :TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>> :TLS_DHE_RSA_WITH_AES_128_CBC_SHA
>> :TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> :TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
>> :TLS_DHE_RSA_WITH_AES_256_CBC_SHA256" >
>>  >   
>> certificateKeystoreFile="/home/cas/keystore/

Re: configuring ciphers for SSL Labs server test

[Scott Hoenigman]

 Are you using a load balancer?



Sent from my T-Mobile 4G LTE Device


 Original message 
From: David Wall 
Date: 5/10/18 6:15 PM (GMT-06:00)
To: users@tomcat.apache.org
Subject: Re: configuring ciphers for SSL Labs server test

We're doing good with this:

 


On 5/10/18 2:45 PM, Baron Fujimoto wrote:
> I'm trying to improve our grade on SSL Labs SSL server test[1] for our
> Tomcat configuraton. Currently, their report caps our grade at B because,
> "This server does not support Authenticated encryption (AEAD) cipher
> suites". They report that we support the following cipher suites:
>
> # TLS 1.2
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>
> # TLS 1.1
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>
> I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
> using Java 1.8.0_162, and I believe we have the Java Cryptography
> Extension (JCE) properly installed. I have the following connector
> defined (this version explicitly lists ciphers I think should satisfy the
> AEAD cipher requirement[2]):
>
>   address="0.0.0.0"
> port="8443"
> maxThreads="500"
> maxPostSize="10"
> scheme="https" secure="true"
> defaultSSLHostConfigName="foo.example.edu"
> SSLEnabled="true" >
>   protocols="TLSv1.1+TLSv1.2+TLS1.3"
> certificateVerification="none"
> honorCipherOrder="true"
> 
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
> :!TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> :!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> :!TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> :!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> :!TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> :!TLS_RSA_WITH_AES_128_CBC_SHA
> :!TLS_RSA_WITH_AES_256_CBC_SHA
> :!TLS_RSA_WITH_AES_128_CBC_SHA256
> :!TLS_RSA_WITH_AES_256_CBC_SHA256
> :!TLS_RSA_WITH_AES_128_GCM_SHA256
> :!TLS_RSA_WITH_AES_256_GCM_SHA384
> :!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> :!TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> :TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> :TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> :TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> :TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> :TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> :TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> :TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> :TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> :TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> :TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> :TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> :TLS_DHE_RSA_WITH_AES_256_CBC_SHA256" >
> 
> certificateKeystoreFile="/home/cas/keystore/foo.pkcs12.keystore" >
>  
>  
>  
>
> I've mapped the cipher suite names using the OpenSSL cipher suite name
> list[3]. I originally started with
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK", but had the same
> result, so subsequently tried adding the specific ciphers shown above. The
> tomcat SSLHostConfig docs state that either the OpenSSL or JSSE cipher
> names may be used[4].
>
> Any suggestions on what I may be doing wrong or for further troubleshooting?
>
> References:
> [1] 
> [2] 
> 
> [3] 
> 
> [4] 
> 

Re: configuring ciphers for SSL Labs server test

[David Wall]

We're doing good with this:

    protocols="TLSv1.1, TLSv1.2" honorCipherOrder="true"

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
    >


On 5/10/18 2:45 PM, Baron Fujimoto wrote:

I'm trying to improve our grade on SSL Labs SSL server test[1] for our
Tomcat configuraton. Currently, their report caps our grade at B because,
"This server does not support Authenticated encryption (AEAD) cipher
suites". They report that we support the following cipher suites:

# TLS 1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

# TLS 1.1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
using Java 1.8.0_162, and I believe we have the Java Cryptography
Extension (JCE) properly installed. I have the following connector
defined (this version explicitly lists ciphers I think should satisfy the
AEAD cipher requirement[2]):

 
 
 
 
 
 

I've mapped the cipher suite names using the OpenSSL cipher suite name
list[3]. I originally started with
ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK", but had the same
result, so subsequently tried adding the specific ciphers shown above. The
tomcat SSLHostConfig docs state that either the OpenSSL or JSSE cipher
names may be used[4].

Any suggestions on what I may be doing wrong or for further troubleshooting?

References:
[1] 
[2] 

[3] 

[4] 





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

configuring ciphers for SSL Labs server test

[Baron Fujimoto]

I'm trying to improve our grade on SSL Labs SSL server test[1] for our
Tomcat configuraton. Currently, their report caps our grade at B because,
"This server does not support Authenticated encryption (AEAD) cipher
suites". They report that we support the following cipher suites:

# TLS 1.2
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

# TLS 1.1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

I'm not sure why SSL Labs is seeing such a limited set of ciphers. We are
using Java 1.8.0_162, and I believe we have the Java Cryptography
Extension (JCE) properly installed. I have the following connector
defined (this version explicitly lists ciphers I think should satisfy the
AEAD cipher requirement[2]):








I've mapped the cipher suite names using the OpenSSL cipher suite name
list[3]. I originally started with
ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK", but had the same
result, so subsequently tried adding the specific ciphers shown above. The
tomcat SSLHostConfig docs state that either the OpenSSL or JSSE cipher
names may be used[4].

Any suggestions on what I may be doing wrong or for further troubleshooting?

References:
[1] 
[2] 

[3] 

[4] 


-- 
Baron Fujimoto  :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Updating a working installation

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Olaf,

On 5/9/18 8:39 PM, Olaf Kock wrote:
> 
> On 09.05.2018 17:09, James H. H. Lampert wrote:
>> Question:
>> 
>> Is there an easy way to bump a working Tomcat installation from
>> one release to another, without benefit of Linux "apt-get" or
>> "yum," or WinDoze "cab" (this is an OS/400 installation), without
>> having to rebuild the whole configuration (webapps, keystore,
>> server.xml, web.xml, &c.) from scratch?
>> 
> 
> Depending on the changes in your configuration and changes
> introduced between your "come from" version versus the "go to"
> version.
> 
> IMHO the easiest way to figure out is to download your source and
> target version of vanilla tomcat and compare them with a diff
> tool.

Also this tool, if you are upgrading within major releases:

https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_f
ile_differences

I never modify conf/web.xml or conf/context.xml. It makes things much
easier.

For major releases, I usually start with the stock conf/server.xml and
re-add all of the necessary configuration, using Olaf's "diff"
technique above. Sometimes, you have to add less than you had added
before. Sometimes, more. :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr0ieMACgkQHPApP6U8
pFg3JQ//VuKbwWp7Y89ARHkukTPl3DtDQdqsMDBOYcWKFIMfcB6JYTZcYhE3uubm
fKijFS97FpTMUk4Z4dHh7DXE2teRPjHl6F9yBNY7QNXInht5oVMzl6haIHAF7ZjE
S1zhCcsVGLyiU8q6MKaM1gEQr0+zQRnnbusME7KublRgzjtfwhV3BRn219rUI4VL
DPhFhK6BjVZ/3bUd/pqdMfMKR2wlw3mv5AqHtpKf2ZgEIDM4tQSCmC6uK5s86u4J
4y7Ux74qNjDCgp5JJ+bUn552Y4CkWeNQvRmL3IHEhUC+78hkCaw9ibcN8jZOQwIP
Faa0XhvYii/y/bZ2Q3YJk/f0EihpYQnaPHPg0v76bBJEEvPH1JFqlCbzLbH2wG3O
brqOwfECtpDWNkSZwaBrff/G3w1dFqUFhqGzI+rsK6aST8cGHAAAgZAxjEkad0gP
55HtZeS/njiEp7EZ6Ug+SBq8IoKS1jKVVkJaKVxO/HKGorOqV4fS+qNZwovk6LoM
kcj7VV5UqwTxvbdWUdoEK4pC+Tba0rIIWmsF400aoqZo0vc/dd4bG3IXWVfp2SLk
2bjE9PnD35mC/ZSj6WfdHq+lG2mHZzjSR/EnAc2acCvi9u8ZRbvPmb1ad+HMNIxO
lc+F5xcx7uqhUMRYQZl0+mBUWrgbgQW0K+dmxxMzNqlC8rlpVs4=
=aLYV
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[Mark Thomas]

On 10/05/18 17:10, Violeta Georgieva wrote:
> 2018-05-10 19:04 GMT+03:00 Violeta Georgieva :
>>
>> Hi,
>>
>> 2018-05-10 19:00 GMT+03:00 Mark Thomas :
>>>
>>> On 10/05/18 16:27, John Palmer wrote:
>>>
>>> 
>>>
 or am I missing (or just ignorant of ) something?
>>>
>>> Seems reasonable to me looking at the code. Give me a few minutes to
>>> test it and - assuming all is well - I'll make the change.
>>
>> Isn't it intentional to not have a css?
>> We do not want to expose the Tomcat version, right?
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56383

Putting to one side the argument over whether revealing the version is a
 a security vulnerability or not...

Exposing the CSS doesn't reveal the version.

9.0.x and 8.5.x include the CSS as a result of BZ 60490.

I've back-ported that fix to 8.0.x and 7.0.x

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[Violeta Georgieva]

2018-05-10 19:04 GMT+03:00 Violeta Georgieva :
>
> Hi,
>
> 2018-05-10 19:00 GMT+03:00 Mark Thomas :
> >
> > On 10/05/18 16:27, John Palmer wrote:
> >
> > 
> >
> > > or am I missing (or just ignorant of ) something?
> >
> > Seems reasonable to me looking at the code. Give me a few minutes to
> > test it and - assuming all is well - I'll make the change.
>
> Isn't it intentional to not have a css?
> We do not want to expose the Tomcat version, right?

https://bz.apache.org/bugzilla/show_bug.cgi?id=56383

> Regards,
> Violeta
>
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>

Re: ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[Violeta Georgieva]

Hi,

2018-05-10 19:00 GMT+03:00 Mark Thomas :
>
> On 10/05/18 16:27, John Palmer wrote:
>
> 
>
> > or am I missing (or just ignorant of ) something?
>
> Seems reasonable to me looking at the code. Give me a few minutes to
> test it and - assuming all is well - I'll make the change.

Isn't it intentional to not have a css?
We do not want to expose the Tomcat version, right?

Regards,
Violeta

> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[Mark Thomas]

On 10/05/18 16:27, John Palmer wrote:



> or am I missing (or just ignorant of ) something?

Seems reasonable to me looking at the code. Give me a few minutes to
test it and - assuming all is well - I'll make the change.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: relaxedPathChars / relaxedQueryChars XML

[Mark Thomas]

On 10/05/18 16:21, i...@flyingfischer.ch wrote:
> Thanks for the two new configurable options relaxedPathChars and
> relaxedQueryChars.
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
> 
> However, since these two elements will be nested in server.xml, adding
> 
> "<>"
> 
> will result in an invalid XML and a failing reboot of tomcat.
> 
> The instructions quote: "Any other characters present in the value will
> be ignored".
> 
> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
> 
> So, I am not sure if adding < and > actually do work?

Yes they will.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

ErrorReportValve styling (CSS) not included when both showReport and showServerInfo set to false

[John Palmer]

while it's documented that the styling will be lost when both settings for
ServerReport/ServerInfo are set to false... eg by adding this to server.xml:



(and I confirmed this recently)

from looking at the source for ErrorReportValve   for tomcat 7.0.78 it
LOOKS like this would be easy to fix:
(however, I'm neither a tomcat/java/HTML or CSS expert, so there may be
very good reasons this is done this way):

currently:

StringBuilder sb = new StringBuilder();

sb.append("");
if(showServerInfo || showReport){
sb.append("");
if(showServerInfo) {
sb.append(ServerInfo.getServerInfo()).append(" - ");
}
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
sb.append(" ");
} else {
sb.append("");
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
}
sb.append("");

 it looks to me like simply moving the three lines for style/css/style
outside the If statement would fix this, like so:

StringBuilder sb = new StringBuilder();

sb.append("");
if(showServerInfo || showReport){
sb.append("");
if(showServerInfo) {
sb.append(ServerInfo.getServerInfo()).append(" - ");
}
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
} else {
sb.append("");
sb.append(smClient.getString("errorReportValve.errorReport"));
sb.append("");
}
// move style lines outside of if(showServerInfo || showReport){
section... above
sb.append(" ");
sb.append("");
...

or am I missing (or just ignorant of ) something?

John Palmer

relaxedPathChars / relaxedQueryChars XML

[i...@flyingfischer.ch]

Thanks for the two new configurable options relaxedPathChars and
relaxedQueryChars.

https://bz.apache.org/bugzilla/show_bug.cgi?id=62273

However, since these two elements will be nested in server.xml, adding

"<>"

will result in an invalid XML and a failing reboot of tomcat.

The instructions quote: "Any other characters present in the value will
be ignored".

https://tomcat.apache.org/tomcat-8.5-doc/config/http.html

So, I am not sure if adding < and > actually do work?

Markus

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org