RE: Tomcat Clustering Support

2018-10-10 Thread Caldarale, Charles R
> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: Tomcat Clustering Support

> Thread A is in the middle of processing a request. It is evaluating some
> EL which requires access to the view map which in turn causes the
> ViewMap to update the session.
> com.sun.faces.application.view.ViewScopeManager.processEvent locks the
> ViewMap object. It then tries to update the session. To do this it
> requires the session lock. Thread A is waiting for this lock.

Assuming the ViewMap is used by multiple sessions, this locking order goes
against the usual protocol of more local before more global.  Might be
possible to file a bug report with Mojarra, but given that the code appears
to be in a com.sun class, that might not get anywhere.

> Thread B is at the end of a request. The session has been updated and it
> is attempting to write the updated session attributes to the cluster.
> The session lock has been obtained. The individual attributes are being
> written. The code has reached the ViewMap object. In order to write this
> object, the ViewMap object must be locked. Thread B is waiting for this
> lock.

This is the generally the more desirable order.

> Has anyone on the users list come across this problem before? If so, how
> have you solved it? Suggestions for alternative solutions also welcome.

Can the thread doing the session synchronization lock the session, get a
shallow copy of the attributes, unlock the session, then process the
attributes?  Not sure if that would maintain sufficient coherency.

  - 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.



smime.p7s
Description: S/MIME cryptographic signature


Re: Request for a technical review

2018-10-10 Thread Mark Thomas
On 10/10/18 17:44, Mallory Mooney wrote:
> Hi all,
> 
> I work for Datadog and am writing a guide about monitoring Tomcat (with or
> without Datadog). I'd love to get some feedback on the technical content.
> The project maintainers we reached out to recommended we post a request
> here.
> 
> Would anyone be up for that? I can send the post link to someone directly.
> 
> Appreciate your help and time!

Why not post the link here so the community can review the document?

Mark


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



Re: Security Alerts Email Subscription

2018-10-10 Thread Igal Sapir

Pradeep,

On 10/10/2018 11:03 AM, Goutam, Pradeep wrote:

Hello Team

Is there a mailing list for subscription to just the security alerts for Apache 
HTTP and Tomcat Server, If there is one can you please send it to me.


You should subscribe to the Announce mailing list:
http://tomcat.apache.org/lists.html#tomcat-announce

Igal


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



Security Alerts Email Subscription

2018-10-10 Thread Goutam, Pradeep
Hello Team

Is there a mailing list for subscription to just the security alerts for Apache 
HTTP and Tomcat Server, If there is one can you please send it to me.

Thanks
Pradeep

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies


Re: Request for a technical review

2018-10-10 Thread Deepak Behera
Hi Mallory,

I can have a look. Please let me know further details.


Thanks,
Deepak Behera


Request for a technical review

2018-10-10 Thread Mallory Mooney
Hi all,

I work for Datadog and am writing a guide about monitoring Tomcat (with or
without Datadog). I'd love to get some feedback on the technical content.
The project maintainers we reached out to recommended we post a request
here.

Would anyone be up for that? I can send the post link to someone directly.

Appreciate your help and time!

-- 
Mallory Mooney
Technical Content Writer


Re: TLS1.3 support for tomcat 7 with APR/tomcat-native

2018-10-10 Thread Усманов Азат Анварович
Thanks Cristopher, I already did. All that´s left is to get the latest patch 
backported to tomcat 7


От: Christopher Schultz 
Отправлено: 10 октября 2018 г. 17:47:47
Кому: users@tomcat.apache.org
Тема: Re: TLS1.3 support for tomcat 7 with APR/tomcat-native

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Усманов,

On 10/6/18 17:27, Усманов Азат Анварович wrote:
> I've been searching the web for any idea why Chrome can do throw
> empty response error with tls1.3 and found this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1619389 at fedora , it
> looks like the same sort of a problem,Interestingly enough it does
> have a fix. My knowledge of C  is quite  limited, so could anyone
> please  look at the patch provided by these guys and see if it  is
> of any use in case of tomcat-native ?
Have a look at the recent bug comments, especially Rainer's comment
about Chrome/ff versions.

- -chris

>  От: Усманов Азат Анварович
>  Отправлено: 25 сентября 2018 г. 11:39 Кому:
> Tomcat Users List Тема: Re: TLS1.3 support for tomcat 7 with
> APR/tomcat-native
>
> Do I need to file a separate feature request for Tomcat itself? The
> one I already
> filed(https://bz.apache.org/bugzilla/show_bug.cgi?id=62748) is for
> tomcat-native component. I looked through Tomcat changelog, I've
> found that previously TLS1.2 support was added  via enhancement
> request to tomcat native .
> (https://bz.apache.org/bugzilla/show_bug.cgi?id=53952)
>  От: Усманов Азат Анварович
>  Отправлено: 20 сентября 2018 г. 12:05:07 Кому:
> users@tomcat.apache.org Тема: Re: TLS1.3 support for tomcat 7 with
> APR/tomcat-native
>
> I did file  a feature -enhancement  in bugzilla
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62748
>
>  От: Christopher Schultz
>  Отправлено: 19 сентября 2018 г.
> 23:31:28 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for
> tomcat 7 with APR/tomcat-native
>
> Усманов,
>
> On 9/19/18 05:56, Усманов Азат Анварович wrote:
>> Hi Christopher! I did remove supportedProtocols attribute
>> entirely (SSL Labs server test confirms it ).
> You mean that SSL Labs then tells you that other protocols are
> available (e.g. TLSv1.0, etc.)? SSL Labs should tell you if TLSv1.3
> is available, so testing with e.g. Chrome shouldn't be necessary.
>
>> > maxPostSize="10485760 "  maxHttpHeaderSize="1048576"
>> protocol="org.apache.coyote.http11.Http11AprProtocol"
>> connectionTimeout="2" redirectPort="8443"
>> SSLHonorCipherOrder="true"
>> SSLCertificateFile="/home/idis/STAR_ieml_ru.crt"
>> SSLCertificateKeyFile="/home/idis/server.key"
>> SSLCertificateChainFile="/home/idis/authorities.crt"
>
>> maxThreads="350"  minSpareThreads="25" SSLEnabled="true"
>> enableLookups="false" disableUploadTimeout="true"
>> acceptCount="100" scheme="https" secure="true"
>> compression="force"
>> SSLCipherSuite="TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,T
L
>
>>
S_AES_128_GCM_SHA256,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GC
> M-SHA384,ECDHE-ECDSA-AES256-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECD
HE
>
>
- -RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES128-GCM-SHA256,
>> ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-SHA384,ECDHE-RSA-AES25
6
>
>>
- -SHA384,ECDHE-ECDSA-AES128-SHA256,ECDHE-RSA-AES128-SHA256,
>
>
> ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA"/>
>
>> I did put
>> TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,TLS_AES_128_GCM_S
H
>
>>
A256
>> as tls 1.3 ciphers for tls 1.3 ,  so my guess is that  more work
>> is required for tls.1.3  to work in my case
>
> Yes, you will definitely have to mention the TLSv1.3 ciphers in
> order to allow a TLSv1.3 handshake to succeed.
>
> But yes, it does indeed look like Tomcat requires some work.
>
> Can you please file an enhancement request in Bugzilla?
>
> Thanks, -chris
>
>>  От: Christopher Schultz
>>  Отправлено: 18 сентября 2018 г.
>> 23:27 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for
>> tomcat 7 with APR/tomcat-native
>
>> Усманов,
>
>> On 9/18/18 6:43 AM, Усманов Азат Анварович wrote:
>>> I have a java7 web application that runs on tomcat 7.0.70 I'm
>>> using Apr/tomcat-native w OpenSSL for TLS connections
>>> .(Tomcat-native 1.2.17  APR 1.6,OpenSSL 1.1.1 RHEL 6  ) Latest
>>> stable OpenSSL release (1.1.1) has TLS 1.3 support ,I have
>>> upgraded to it  successfully. My question is  if and when
>>> tomcat 7 will be upgraded to support TLS1.3  through w
>>> APR/tomcat-native/OpenSSL? do such plans even exist?
>
>> Try not specifying any "supported protocol" (e.g. allow all
>> protocol flavors), and OpenSSL should allow TLSv1.3 to be
>> negotiated.
>
>>> I'm guessing it will not happen at least untill both Chrome
>>> and firefox release theirbrowser updates for RFC8446
>>> support (which are  both scheduled for Mid october Crome 70 and
>>> firefox 63) but would like to know more about it
>
>> I for 

Re: log4j: Logging to same file from multiple contexts?

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 10/8/18 14:27, David Filip wrote:
> Dear Tomcat Users,
> 
> Apologies if this is more of a log4j question, but I thought that
> I'd start here, in case Tomcat has any easy remedies.
> 
> I have a common webapp that I deploy to multiple, different
> contexts.
> 
> In log4j.properties, I have a few different log files defined,
> e.g., for logins:
> 
> log4j.appender.logins=org.apache.log4j.DailyRollingFileAppender 
> log4j.appender.logins.file=${catalina.home}/logs/logins.log 
> log4j.appender.logins.datePattern='.'-MM-dd 
> log4j.appender.logins.append=true 
> log4j.appender.logins.layout=org.apache.log4j.PatternLayout 
> log4j.appender.logins.layout.ConversionPattern=[%d{MM/dd/
> HH:mm:ss}] [%p] [%C{1}]: %m%n
> 
> log4j.logger.com.colornet.CAP.Actions.LoginAction=info, logins 
> log4j.logger.com.colornet.CAP.Util.LoginTokenTag=info, logins
> 
> However, as you may have guessed, if I have the same log4j
> configuration file for each context, the contexts tend to
> over-write each other.
> 
> Is there any way to have the SAME log4j.properties deployed too
> multiple contexts play nicely and not overwrite each other, but
> merely append each other?
> 
> Extra credit question (although sounds even more like a log4j
> question, so apologies): If not, is there any way to define the
> file path, e.g.:
> 
> log4j.appender.logins.file=${catalina.home}/logs/logins.log
> 
> to include the specific context?  I have found a few references on
> the 'Net, e.g., ${contextPath}, ${servletName}, etc., which don't
> seem to work.
> 
> My goal (desire?) is to have the same webapp and configuration and
> web.xml and log4j.properties, etc., deployed to every web context,
> but not have one context overwrite another content's entries.
> 
> Of course, as the Mick once said, "You can't always have what you
> want".
> 
> Please let me know if this is possible.

I'm not sure it's really a great idea to have all these separate
context logging to the same log file(s), but here is a way to do this:

1. Move (*move!*) your log4j.jar file from WEB-INF/lib to Tomcat's
lib/ directory

2. Move (*move!) your log4j.properties file from WEB-INF/classes to
Tomcat's lib/ directory. You may have to wrap it in a JAR file.

This ought to allow log4j to initialize a single time, and each
application will use that singly-initialized log4j instance.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+EwQACgkQHPApP6U8
pFjKIA//UL0KHt11kczm28Yv9Ab9WbdHXxnG3dqC25q+HTA1Eq5wu/pTfCGPoa03
R4Sc5r3HpapyeMtZR1XFCPVFPAgbiHQeCD7Bkduw0bCKV8ZOvRJJOgqiXHYiW0cF
RuThsq/txShzRZ1KLqGOuZvfA6MsjIEXdWNdnbSH5g5lDT1mRsabzEpdqbkWXc8W
wru1VWZBNHQwU1k1wZ7ts1jVKZQzJhcO1scs/RWXIHNs8R+dADNsWcsqWzYyeuAm
nWYfhsN03/ilQwBjpAqDBsSnt7a3TvLW4Zh9XrcJylHenOdewj53MdL4AnjS7zUS
+TL3xHB+y8GEIUEsxuuAZy0sKVoPfApEHVovp6cTXzSUi+4fn+gBG2E0zL2o87GD
dfoBsgN3gpMw3oGqB2C67El/ECLIVdo6gU/kw1Pq/asMJPwFMK9OPWk06ScXec7n
ff52KuNt9Oedsm12J7d/GkfMb/8KtvTvzRI30FVf5phCvdkZrOPA0Nsuy40z+jcI
vOwIVcqONUDuG1rkD6Qnm5KwoBDJfkkNTy7BxJS5qtQmCV3dUDm3vvcm5cNzFXlK
b5yvp7UvAPyg13AdjGQd6C0rtG8p+RtTmwJvEZU4bQ16ZYWyQUDhVdLAnvgjb9Iv
jJxF2gAvcLxoqMnEh2AdWCSJjfrQkrZi/4vAYaFYK60EMnElh4w=
=5bwl
-END PGP SIGNATURE-

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



Re: Redirecting to https URL when https port is accessed with http scheme

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martynas,

On 10/6/18 06:31, Martynas Jusevičius wrote:
> see also this thread: 
> https://mail-archives.apache.org/mod_mbox/tomcat-users/201808.mbox/%3C
cae35vmwcm9dkxmvabofgjb5d_oa07a6mrjxwcgknksbzgjh...@mail.gmail.com%3E
>
>  I did this with front nginx eventually.

In this case, Ettra is wanting to make an HTTP request to an HTTPS
service, which usually just fails to establish a TLS handshake.

Instead of failing, Ettra would prefer to have Tomcat respond with an
HTTP response with no encryption. This is how Apache httpd currently
behaves:

=== CUT ===

$ telnet localhost 443
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /
Host: localhost
HTTP/1.1 400 Bad Request
Date: Wed, 10 Oct 2018 14:52:08 GMT
Server: Apache/2
Content-Length: 432
Connection: close
Content-Type: text/html; charset=iso-8859-1



400 Bad Request

Bad Request
Your browser sent a request that this server could not
understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
 Instead use the HTTPS scheme to access this URL, please.


Apache/2 Server at phobos.chadis.com Port 443

Connection closed by foreign host.

=== CUT ===

Tomcat will simply close the connection in its current implementation.

- -chris

> On Sat, Oct 6, 2018 at 7:29 AM ettra lancelot 
> wrote:
>> 
>> Thank you for the detailed answer, Chris.
>> 
>> On Sat, Oct 6, 2018 at 2:41 AM Christopher Schultz < 
>> ch...@christopherschultz.net> wrote:
>> 
> Etcy,
> 
> On 10/5/18 14:57, ettra lancelot wrote:
> I would like to know whether it's possible to configure
> tomcat to automatically redirect to the https URL when
> https port is access using http scheme instead of https*.*
> 
> There is no way to get Tomcat to do this for you right now.
> 
> There is, however, the possibility of adding such a feature to
> Tomcat.
> 
> If you make an HTTP request to Apache httpd on a TLS-enabled port, 
> you'll get a response that says "Looks like you made a mistake".
> 
> In the past, that would have been a huge pain in the neck for
> Tomcat, since the TLS handshake was handled *entirely* by the
> underlying crypto system (e.g. JSSE or APR/OpenSSL). AIUI, that
> code has been re-written and Tomcat is buffering everything
> internally and probing the handshake, etc.
> 
> It should therefore be possible to respond in the way you
> describe, but I'm not sure how much appetite there is for issuing a
> redirect rather than just an informational page such as the one
> httpd returns.
> 
> Unfortunately, Bill is incorrect when he says that you can write a 
> Filter for this. No application code will ever see a connection
> over a connection which failed a TLS handshake.
> 
> -chris
>>> 
>>> 
- -
>>>
>>> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+El4ACgkQHPApP6U8
pFh7BA//WfMVYmUI97gCsgHuNIVwUbDnFYYJaiefGkexhW+ujQTqP+WeqPO4YJYW
FqZ2d2ZJ+e6VWfb9poB9c/couTh9shyIefPGE6CBXLD0AaWXdbT6s9fzQEq9803f
G3w9AnK20r4tCcE4bZkz5NWGcnvII8LVr78PR/QEuCkKMlabSMZ1hY12XrPXUO/3
IjGBdiuEqedLAOxrqp65ZXbZ5hKA5UXYSxIxrT+PN52TpncmIpVecJO29yjrTIAo
cBFOoOqYP0I1ylvSTRTPMsk+1pNE9V+KxIyqwxGC24gJvE/x0U+xvvehj5NUlsFz
IwHRolJ1iQYtE1OONEQ1jDtqGUjllme3JJ79cZFRDbhUgMum+4V91bK9Oou6Lrwq
85oIudC2kFc9CMoq7QocOaTJTMNVwLj2/xHZIO4tPXw7S1Tw3eHEyqe6vReWDlKf
B7qQTqgA2EKFp3BZOLV94IazMxK/Gf5lBFyL9f9j4OVKunEiJ9NSNjmwB23vhsNT
Kmz/RyvRHd0EF4127YwUqjVQqOeWfhnNivZRf4GQGX1AbrcrJBfVOgp60z+VI9lD
iO/5u+zeFflocbvDHxEfDfWZZYdB1XXdH16ug6n6BaoERs/gRRNFAuEqP4Qk5joI
CfDz3SDdaqI+Ve0PXMOINxm3EqtdgpCo5l6tl3U2h/ITxijYr4Q=
=ULFh
-END PGP SIGNATURE-

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



Re: TLS1.3 support for tomcat 7 with APR/tomcat-native

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Усманов,

On 10/6/18 17:27, Усманов Азат Анварович wrote:
> I've been searching the web for any idea why Chrome can do throw 
> empty response error with tls1.3 and found this bug 
> https://bugzilla.redhat.com/show_bug.cgi?id=1619389 at fedora , it 
> looks like the same sort of a problem,Interestingly enough it does 
> have a fix. My knowledge of C  is quite  limited, so could anyone 
> please  look at the patch provided by these guys and see if it  is 
> of any use in case of tomcat-native ?
Have a look at the recent bug comments, especially Rainer's comment
about Chrome/ff versions.

- -chris

>  От: Усманов Азат Анварович
>  Отправлено: 25 сентября 2018 г. 11:39 Кому:
> Tomcat Users List Тема: Re: TLS1.3 support for tomcat 7 with
> APR/tomcat-native
> 
> Do I need to file a separate feature request for Tomcat itself? The
> one I already
> filed(https://bz.apache.org/bugzilla/show_bug.cgi?id=62748) is for
> tomcat-native component. I looked through Tomcat changelog, I've
> found that previously TLS1.2 support was added  via enhancement
> request to tomcat native .
> (https://bz.apache.org/bugzilla/show_bug.cgi?id=53952) 
>  От: Усманов Азат Анварович
>  Отправлено: 20 сентября 2018 г. 12:05:07 Кому:
> users@tomcat.apache.org Тема: Re: TLS1.3 support for tomcat 7 with
> APR/tomcat-native
> 
> I did file  a feature -enhancement  in bugzilla
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62748
> 
>  От: Christopher Schultz
>  Отправлено: 19 сентября 2018 г.
> 23:31:28 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for
> tomcat 7 with APR/tomcat-native
> 
> Усманов,
> 
> On 9/19/18 05:56, Усманов Азат Анварович wrote:
>> Hi Christopher! I did remove supportedProtocols attribute
>> entirely (SSL Labs server test confirms it ).
> You mean that SSL Labs then tells you that other protocols are 
> available (e.g. TLSv1.0, etc.)? SSL Labs should tell you if TLSv1.3
> is available, so testing with e.g. Chrome shouldn't be necessary.
> 
>> > maxPostSize="10485760 "  maxHttpHeaderSize="1048576" 
>> protocol="org.apache.coyote.http11.Http11AprProtocol" 
>> connectionTimeout="2" redirectPort="8443" 
>> SSLHonorCipherOrder="true" 
>> SSLCertificateFile="/home/idis/STAR_ieml_ru.crt" 
>> SSLCertificateKeyFile="/home/idis/server.key" 
>> SSLCertificateChainFile="/home/idis/authorities.crt"
> 
>> maxThreads="350"  minSpareThreads="25" SSLEnabled="true" 
>> enableLookups="false" disableUploadTimeout="true"
>> acceptCount="100" scheme="https" secure="true"
>> compression="force" 
>> SSLCipherSuite="TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,T
L
>
>> 
S_AES_128_GCM_SHA256,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES256-GC
> M-SHA384,ECDHE-ECDSA-AES256-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECD
HE
>
> 
- -RSA-CHACHA20-POLY1305,ECDHE-ECDSA-AES128-GCM-SHA256,
>> ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-SHA384,ECDHE-RSA-AES25
6
>
>> 
- -SHA384,ECDHE-ECDSA-AES128-SHA256,ECDHE-RSA-AES128-SHA256,
> 
> 
> ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA"/>
> 
>> I did put 
>> TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA384,TLS_AES_128_GCM_S
H
>
>> 
A256
>> as tls 1.3 ciphers for tls 1.3 ,  so my guess is that  more work 
>> is required for tls.1.3  to work in my case
> 
> Yes, you will definitely have to mention the TLSv1.3 ciphers in
> order to allow a TLSv1.3 handshake to succeed.
> 
> But yes, it does indeed look like Tomcat requires some work.
> 
> Can you please file an enhancement request in Bugzilla?
> 
> Thanks, -chris
> 
>>  От: Christopher Schultz 
>>  Отправлено: 18 сентября 2018 г. 
>> 23:27 Кому: users@tomcat.apache.org Тема: Re: TLS1.3 support for 
>> tomcat 7 with APR/tomcat-native
> 
>> Усманов,
> 
>> On 9/18/18 6:43 AM, Усманов Азат Анварович wrote:
>>> I have a java7 web application that runs on tomcat 7.0.70 I'm 
>>> using Apr/tomcat-native w OpenSSL for TLS connections 
>>> .(Tomcat-native 1.2.17  APR 1.6,OpenSSL 1.1.1 RHEL 6  ) Latest 
>>> stable OpenSSL release (1.1.1) has TLS 1.3 support ,I have 
>>> upgraded to it  successfully. My question is  if and when 
>>> tomcat 7 will be upgraded to support TLS1.3  through w 
>>> APR/tomcat-native/OpenSSL? do such plans even exist?
> 
>> Try not specifying any "supported protocol" (e.g. allow all 
>> protocol flavors), and OpenSSL should allow TLSv1.3 to be 
>> negotiated.
> 
>>> I'm guessing it will not happen at least untill both Chrome
>>> and firefox release theirbrowser updates for RFC8446
>>> support (which are  both scheduled for Mid october Crome 70 and
>>> firefox 63) but would like to know more about it
> 
>> I for one would like to see TLSv1.3 supported as quickly as 
>> possible.
> 
>> The OpenSSL project states that 1.1.1 is a drop-in API- and 
>> ABI-compatible replacement for 1.1.0 and therefore TLSv1.3
>> should "just work" under certain 

Re: Tomcat JNDI Authentication - No Login

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lee,

On 10/9/18 08:11, Lee Broom wrote:
> Hello My aim is to introduce a domain level
> authentication/authorisation security layer when accessing the
> http://localhost:8080/sample/ application. I don't want this web
> application to be openly accessible and without challenging an
> operator.

You should be using HTTPS. This won't cause an erorr, but it is not a
secure configuration.

> After a frustrating and fruitless week I now reach out to the
> apache community for assistance because I have been unsuccessful
> enabling this function. The current behaviour is that
> http://localhost:8080/sample does not throw a login prompt.
> 
> I can only assume it is caused by my Apache Tomcat code snippet
> configuration is all wrong. I am running version Apache
> Tomcat/7.0.91 on Redhat 7 in an ec2 AWS instance. I have installed
> and integrated Winbind on the OS and is happily talking to my AD
> domain example.com. Confirmation of this is realm connecting
> successful, I can see groups and users and I have masked the domain
> format 'example/user1' so it appears as 'user1'. Other factors; 1)
> I have found similar issues posted by others but none of the
> solutions worked for me 2)There are no errors found within
> /usr/local/tomcat7/logs/.

If you have the option, I'd use a more recent version of Tomcat. It
sounds like you are starting from scratch, so using e.g. Tomcat 9
should not represent too much of a burden.

> I had downloaded and installed sample.war from
> https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/ into my
> tomcat installation /usr/local.tomcat7/webapps/ directory.
> 
> I would appreciate any assistance or a hefty kick in the right
> direction.
> 
> There are 3 files in total that I have attempted to configure;
> /conf/server.xml, /webapps/sample/WEB-INF/web.xml &
> /conf/tomcat-users.xml
> 
> My JNDI Realm entry in /usr/local/tomcat7/conf/server.xml
> configuration looks like this: 
> --
- 
>
> 
 debug="99"

What's the "debug for?

> connectionURL="ldap://example.com:389;

You should be using LDAPS. This won't cause an error, but it is not a
secure configuration.

> authentication="simple" referrals="follow" 
> connectionName="ou=users,ou=lab,dc=example,dc=com" 
> userSearch="(sAMAccountName={0})" userBase="dc=example,dc=com" 
> userSubtree="true" roleSearch="(member={0})" roleName="cn" 
> roleSubtree="true" roleBase="ou=users,ou=lab,dc=example,dc=com" />

This all looks okay to me at first glance, but I haven't set up Tomcat
LDAP authentication before.

Where is your  defined in conf/server.xml? Within the 
or  where your application will live? If not, it needs to be in
one of those places. If you just replaced the existing  from
the stock conf/server.xml file, then you should be good.

> --
- 
>
>  Also, I have commented the following: 
> --
- 
>
> 
 
> --
- 
>
>  My /usr/local/tomcat7/webapps/sample/WEB-INF/web.xml file looks
> like this: 
> --
- 
>
> 

> http://java.sun.com/xml/ns/j2ee; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version="2.4">
> 
> Hello, World Application 
>  This is a simple web application with a source code
> organization based on the recommendations of the Application
> Developer's Guide. 
> 
>  HelloServlet 
> mypackage.Hello 
> 
>  HelloServlet 
> /hello 
> 
>   
> Entire Application 
> /*  
> 

You have a security-constraint which covers the entire URL space and
does not require any user roles. As explained in [1]:

"
An authorization constraint establishes a requirement for
authentication and names the roles authorized to access the URL
patterns and HTTP methods declared by this security constraint. If
there is no authorization constraint, the container must accept the
request without requiring user authentication.
"

I believe this is the core of your problem.

>
> 
>  All Users 
>  All
> Users /* 
>   
> User  
> 

You have mapped a second security-constraint to the same URL space.

>  Admin Users 
>  Admin
> Users /* 
>   
> Admin  
> 

You have mapped a third security-constraint to the same URL space.

In case of a conflict, I believe the "let everyone in" constraint,
specified first above, will win.

>  Webapp Admins 
> Admin domain
> admins 
> 
>  Webapp Users 
> User domain users 
> 
> 
>  BASIC 
> /sample/login.html 
> /sample/error_login.jsp 
> 
> 
>  
> --
- 
>
>  The only change 

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark and Michael,

On 10/10/18 05:15, Mark Thomas wrote:
> On 08/10/18 21:55, Michael Yoder wrote:
>> On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas 
>> wrote:
>>> CVE-2018-11784 Apache Tomcat - Open Redirect
>> 
>> Is it possible to get more information on the "specially crafted
>> URL"? I'd like more information so that I can test if some of our
>> apps are vulnerable.
> 
> Generally, there is a balance to strike here between making it easy
> for the less technically competent attackers to construct an attack
> and making it easy for end users to figure out if they are
> vulnerable. The way we typically do this is by describing the
> conditions necessary for an attack to be possible as completely as
> possible but not providing details of how to perform an attack.
> 
> We also provide references to the commit that fixed the issue. For 
> someone with the right skills, there is usually enough information
> in the description and the commit for a successful attack to be
> reverse engineered.

It doesn't look like Sergey has posted anything (that I can find) that
might be called a full disclosure. If he had, I'd point it out.

If I were you, I'd just make sure that you either (a) upgrade or (b)
use the existing settings to mitigate the potential problem, as
described in the announcement.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+C0QACgkQHPApP6U8
pFhCJQ/9Gw/G8dw46y4ItHFCsPTDiTxGenxMmVAlxt7kisblb8H3o9vK8PU96+PD
Nb44/Vf5hp5XKN5Xuu3czyNjQ2l0QFb/WxZyqSnlWPEWOQs7a6ZFez9MQZ1W1H13
t6qRCSgcOWcrHvXBKjshspHzY6XeQq2Q5kzHntbVZKjQMQif/Cd73XYX0/GIukcF
4tKhQIXRNh99/NOsw6Ot+DgVjksVhVgg62sOuAe7gUh/UNginc07JvYBa9rKgAz+
JP3Z+PvUyCJFzGSoT1cYAniU+ZNiayquEmMxVeJ4VX6ZK2PMhPjEt58yD3NTOCaN
fAE7ct9UICZ8g9WP22OcTAfaYgUSBGSCOxd7DkqM/o06Lv2bTsiWYtOr8bhHNnrO
S7hJJ5a6Tm7TbN4Insm+BQhvts5FeDAsKM92TWGTrAZ52LEhdS2twsRcmCQDE69z
+mmjRTl+W9UTxl6JTmDHj10d/aWYaA3f2SpZ4A18rRP4JSXQm7Ls/st8hR/TwdKC
LsQ9RnmrDLgtSyql9keWhwaD28iQix5KgfFXOLrByCByzORnbP3z9VEu1knO1r1f
Voe8wq8lDf56vRsr5VjjqSgmkeabtz8uxymOSbt8b3spQ6Q2J7y86MDA3/I7ZjTx
cqgS2JyYAgtlD6vyiNeYRG14XBly3vFZeoCmw6CKFSTFSdK8r3I=
=2IHD
-END PGP SIGNATURE-

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



Re: To Support at Tomcat, Got an issue Finding Maths.

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ian,

On 10/10/18 06:19, Ian Burton wrote:
> I have spent many hours searching for a organised way to ask for a
> 
> Public void setter(double value){
> 
> Value = Maths.sin(param1);
> 
> }
> 
> Here is an example of files used from Java to JSP.
> 
> [Calculus Beanjava – Measures.jsp]
> 
> Nothing has been compatible, is there a licence restriction?

It's unclear what you're asking, here.

Can you explain a little more what you are trying to do?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+Ci0ACgkQHPApP6U8
pFi2og//VUVPW1xIV7mRbuYhLZOc3Um8YdsBYhH+ynQ14a77XyZPlhF6wslsIXmD
7eF3Ese1Sqvj2rYjuWch7+Wh/AVPKMST1MOossMtpP+br5txC22795/D86ypv0xU
qRUQ0n3INYsLRCuzlZfU97ibhLCQQgv05bFOlydBoKrUyjha5mHCkicpxm365//Y
iS/39vvTg0M2oaLGii5g0lD8LPUZy+trj7XTOmxcsmqNZpTFwHWZkFsFtv0VA7TM
nbxmuvYthPwFgPeL/y7e82A+VwT7Un6K9XplycqWwjpd8bBM2Cmpa1nIObK4uBoK
GnLbbWag4BNswEdE9VjT+3MeLdRI6dVT4C683emhCclzZqVKUge97inXtr04X6lh
qIr/YPDrlk/+0yzEbltgBnjVUurzstL/Atx9I2edgAmPxPusUuzXLiRoPxuNG68A
rIenPoDGtzrGBbN093fYXSgqnkMoDxGAvVNTdUsmgJ1I5+5FVimnDOelv0DYjvcM
j3HtfoPIn2/gBWRGeYsrgMowQ0E4CgSMv6EocCt4fWtfSQGfT4hIaXNer0qDQgJo
qyQI96jfhB7J1m34+Ux6ZSCZeRAxndehclWqp26tSs34VeTtVt8nm8o62t1ehtOs
G3KkwxKKEfWwtMR4/+p/BKJCNnSkZ1HxSu7rIpP2fL/PCeMrRh4=
=TJbJ
-END PGP SIGNATURE-

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



Re: TC 8.5 cachingAllowed=false ramifications?

2018-10-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 10/9/18 11:59, Berneburg, Cris J. - US wrote:
> Thanks Chris
> 
> cjb> of TC 8.5.32 on Java 8u181, report output Excel cjb> files
> won't load (immediately).  An error is cjb> displayed to the user.
> [...] cjb> 1. What are the ramifications of disabling the cache? 
> cjb> IOW, what are the potential side-effects? [...] cjb> 2. Is
> there a "better" way to specify the setting? [...] cjb> 3. Is there
> a "better" way to solve the problem? [...]
> 
> cs> Long ago, we added something similar to what you cs> are
> talking about.  Basically, it was a file- cs> upload capability for
> images. We waffled about cs> whether to just map the
> /uploaded-images/ URL cs> space directly to the disk and have
> DefaultServlet cs> serve the bytes or to write our own servlet
> [...]
> 
> cs> Re-reading the documentation for  cs> (specifically,
> ), it seems that: cs> cs> 
> cachingAllowed="false" cs>   base="/base/path/to/image/files/" cs>
> className="org.apache.catalina.webresources.DirResourceSet" cs>
> webAppMount="/uploaded-images/" /> cs> cs> ... might do the trick,
> and it would only disable caching for that portion of the disk. 
> cs> cs> Perhaps this would be a better solution, because cs> it
> only disabled caching for a *portion* of the cs> requests you'll be
> handling.
> 
> Yes, exactly!  I might experiment with something like that "next".
> 
> cjb> Is it possible to declare only the Excel reports cjb> output
> folder as non-cache-able but leave the cjb> (default) context cache
> setting as-is so everything cjb> else can be cached in the default
> way?  That is, cjb> set up the Excel report output folder as a
> separate cjb> "resource" with an independent cache setting? cjb>
> Right now the Excel folder is embedded in the app cjb> file system:
> TC/webapps/app/excel.
> 
> Although I wonder if having the Excel folder embedded in the app
> content folder and specifying it in a "PostResources" clause at the
> same time would somehow conflict with the default servlet already
> serving it.

Good thought: the DefaultServlet will use the "resources" as set-up by
the context, so "post resources" will fall at the end of the list of
things to check. If the "excel documents" folder is actually rooted in
the web root of the context, then yes, you'll achieve nothing.

On the other hand, you shouldn't put your excel files into a directory
rooted in the web root of the context because they will be deleted if
you undeploy the web application. (oops)

Also, using PreResources is a potential security hazard, as "pre
resources" are checked for *classes* before the regular
WEB-INF/classes and WEB-INF/lib/*.jar files and so it's easy to inject
a rogue class into your application if an attacker can arrange for
that kind of things to happen. In your use-case, you are building the
document internally (so the user isn't uploading files), but it's
worth pointing-out that in an upload-situation, use of "pre resources"
to serve uploaded files can get you compromised in a hurry.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+CeUACgkQHPApP6U8
pFi8aA//YhQ5C+aevSfPoYYyooN+M2Kw9PWWhVDkVJs2esOPkSrwNFG7TCHnLn52
cBcgqOSKX6nvlanwyk+3aFlk2OdRrZL2IRqszXuugQr2fZpC18qvHru9xi6JpCDJ
kFr+qhp0xQ6WNlG/+DnaOXLg8/x3m0N+iihjNOgxbtvwcag1AksADpRpYnscnen1
bimNvvBatyiSyBUZ3m5FQjF3E3iuB63MXygT3emwWsOrGya7PafoeG9Wbr+nD6dc
z4nEp6UOqVk0FSyYgaFDoUYAZIa7PNVaHWs+SCFwm749pSjvg9vgnMBoYsBPN0XH
t0jHvSMu5ye5H+sACxgjaY0S/2l78ps1dg9ULlHDJM3zIdqM8TQIMObmUUAk7tUJ
LDXf0KJEZa8sLYm9o6PEaUHReLrM8I2WylwW6puTSTvRDDjkcoKUj4Nc8xEsDppb
yu79aHG5EiiCJfJ6rdo5OdGRKKHaFa27upxdy4yzr9whzCLG8vqpPUmKGiKHPw9O
9lQ6RVhaGO3NYromew614BaujgJbkIHNYtLNkIzVvAK5EuyiRewLSrIKUaC+R5JO
wY41Z37ai6bN4mR2chiqFIyPX871OUYFUWMzIbmKZB8xXugKhhdl3syq4vp+uiIr
kgStOuxlaUeMUXWW6q5Tvdq5rUc7mzkkVsixyeqHKqw6zjhtfY0=
=TguN
-END PGP SIGNATURE-

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



To Support at Tomcat, Got an issue Finding Maths.

2018-10-10 Thread Ian Burton

I have spent many hours searching for a organised way to ask for a 
Public void setter(double value){
Value = Maths.sin(param1);
}
Here is an example of files used from Java to JSP.
[Calculus Beanjava – Measures.jsp]

Nothing has been compatible, is there a licence restriction?

Ian burton.




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

Re: [SECURITY] CVE-2018-11784 Apache Tomcat - Open Redirect

2018-10-10 Thread Mark Thomas
On 08/10/18 21:55, Michael Yoder wrote:
> On Wed, Oct 3, 2018 at 12:50 PM Mark Thomas  wrote:
>> CVE-2018-11784 Apache Tomcat - Open Redirect
> 
> Is it possible to get more information on the "specially crafted URL"?
>  I'd like more information so that I can test if some of our apps are
> vulnerable.

Generally, there is a balance to strike here between making it easy for
the less technically competent attackers to construct an attack and
making it easy for end users to figure out if they are vulnerable. The
way we typically do this is by describing the conditions necessary for
an attack to be possible as completely as possible but not providing
details of how to perform an attack.

We also provide references to the commit that fixed the issue. For
someone with the right skills, there is usually enough information in
the description and the commit for a successful attack to be reverse
engineered.

> In addition, I'd like to verify that the value of
> mapperContextRootRedirectEnabled defaults to "true",

For the latest release of each supported Tomcat version, that is
correct. Historically, that is version dependent. Check the docs for the
version you are using.

> so if we don't
> alter that value we aren't susceptible?

Incorrect. As per the announcement both mapperDirectoryRedirectEnabled
and mapperContextRootRedirectEnabled need to be true to avoid this
vulnerability if you are not using a fixed version.

The default for mapperDirectoryRedirectEnabled is false.

Mark

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



Re: Tomcat Clustering Support

2018-10-10 Thread Mark Thomas
On 15/08/18 20:52, Mark Thomas wrote:
> On 15/08/18 20:43, Scott Evans wrote:
>> Hi,
>>
>> Our system is on Apache Tomcat Version 8.0.47.
>> OS is Windows Server 2012 R2 Datacenter.
>>
>> We are looking for someone that may be interested in paid contract work to
>> assist with troubleshooting and resolving a Tomcat clustering issue in our
>> system.
>>
>> The system is composed of multiple Java PrimeFaces applications running in
>> a clustered Tomcat environment which is experiencing occasional
>> deadlocking issues from an unknown source requiring the Nodes to be cycled
>> in order to resolve.  The issue is only occurring in our Production
>> environment and we've determined that the issues are occurring at random
>> with the replication threads.
>>
>> We would need someone to help investigate our configuration and determine
>> if there are any further changes that can be made to our system to catch
>> these deadlock issues before they occur (requiring a Node cycle).
>>
>> Please let me know if you or someone you know may be interested or if you
>> have further questions I can help answer.
> 
> If you can provide a thread dump of the deadlock when it occurs we can
> probably help you here for free.

Scott provided me with a sanitised copy of the thread-dump off-line. I'm
sharing my analysis with the list (with Scott's permission) as I think
the root cause is likely to be of wider interest.

There was, indeed, a deadlock.

The issues was follows.

The application is using JSF. Specifically, the Mojarra implementation
from Oracle.

There are multiple concurrent requests for the same session.

Each request is processed by a dedicated thread (this is mandated by the
Servlet spec although it may not be expressed that way).

The threads in question are:

A. ajp-apr-8009-exec-9005
B. ajp-apr-8009-exec-9000

Thread A is in the middle of processing a request. It is evaluating some
EL which requires access to the view map which in turn causes the
ViewMap to update the session.
com.sun.faces.application.view.ViewScopeManager.processEvent locks the
ViewMap object. It then tries to update the session. To do this it
requires the session lock. Thread A is waiting for this lock.

Thread B is at the end of a request. The session has been updated and it
is attempting to write the updated session attributes to the cluster.
The session lock has been obtained. The individual attributes are being
written. The code has reached the ViewMap object. In order to write this
object, the ViewMap object must be locked. Thread B is waiting for this
lock.

So, thread A holds the lock that thread B wants and is waiting for the
lock thread B is holding. Thread B holds the lock the thread A wants and
is waiting for the lock thread A is holding. Deadlock.

This is, in essence, cause by a combination of how Tomcat's clustering
is designed and Mojarra is implemented.

The application is using the BackupManager. I assume with sticky
sessions. Therefore, I would expect session failover between nodes to be
a rare event.

My recommendation is to investigate excluding the ViewMap from the
replication via sessionAttributeNameFilter. You'd need a regular
expression that matched anything except
"com.sun.faces.application.view.activeViewMaps"
I don't know how integral this object is to Mojarra. Mojarra may simply
recreate this object if required. If not, you may need to trigger
recreation after failover. I don't know how feasible this solution is.
This will require some testing and possibly code changes.

Has anyone on the users list come across this problem before? If so, how
have you solved it? Suggestions for alternative solutions also welcome.

Mark

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