RE: Problem specifying cipher suites in tomcat6

2015-05-29 Thread George Stanchev
Chris, thanks for sharing this. I've recently ran across a similar tool:

http://www.bolet.org/TestSSLServer/

That does the same thing as your code but may be a little bit more elaborate. 
It also has a source code on link. Since you has shared your code, I might as 
well share this - the more the better.

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, May 29, 2015 3:32 PM
To: Tomcat Users List
Subject: Re: Problem specifying cipher suites in tomcat6

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ramon,

On 5/29/15 4:42 PM, Ramon Pfeiffer wrote:
> On 29.05.2015 21:12, Christopher Schultz wrote:
>> Ramon,
>> 
>> On 5/29/15 3:32 AM, Ramon Pfeiffer wrote:
>>> Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
> From: Ramon Pfeiffer
> [mailto:ramon.pfeif...@uni-tuebingen.de] Subject: Problem 
> specifying cipher suites in tomcat6
 
> I'm currently trying to specify a list of cipher suites to be used 
> by my connector in Tomcat 6.0.24.
 
> Anybody can shed some light on what I did wrong?
 
 Using a version of Tomcat that's more than five years old is the 
 first thing - there have been many, many security fixes since then, 
 including some related to the ciphers attribute.
 You also need to tell us the JVM version, the platform you're 
 running on, and whether or not APR is in use for this  
 (it's in the logs).
>> 
>>> Sadly, it's a system I inherited last year and now have the pleasure 
>>> to work with. I can't update Tomcat for I don't know what will 
>>> break.
>> 
>> If you can't upgrade it, you are better-off shutting-down the 
>> service, because there are security vulnerabilities in there.
>> 
>> So, ask your boss which is worse: shuttering the project, or getting 
>> a new version of Tomcat into a testing environment?
> 
> Shutting it down is not an option. So I guess next week will be... 
> interesting.
> 
> The important thing is this: Will the connector work in this 
> configuration after I updated Tomcat? Or is the issue completely 
> unrelated? Where are the ciphers shown by ssllabs taken from? Is the 
> cipher attribute ignored?

Lots of things have been fixed/added in more recent versions of Tomcat 6.0.x. 
Please give a quick test against Tomcat 6.0.latest: you don't even need to 
deploy your own web application on it; just configure it for SSL and hit the 
default web application (the Tomcat documentation), or the examples, or 
whatever.

SSLLabs picks the ciphers it wants to check for; usually a group of "good" 
ciphers to make sure that you can support the latest-and-greatest ciphers, plus 
a bunch of them that are known to be broken (like most SSL-only ones).

This tool may help you test, because it's a whole lot faster than SSLLabs' 
tests:
http://markmail.org/message/tz4z44nfjl7sy2lj

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaNqzAAoJEBzwKT+lPKRYyyIP/AxaJNDI8C98lGUGP4bqOFsm
ZSxcfQG44mAFwBAMkW2oxfCCD7MDb8y9jQT5qyEv+eEgLd9kFjG1UOXogDKAm6dI
d8lh10FSI/Wk4o7OMuWl7nCE8APzUAMCojJz3RxvMvJwFpyP6Te7Zl8baNHXUl2U
zir68R9fTjT/UT9Wps6+gg5UWS/v08gzeBarizdk3QHtQrgXJamF9aLgJ+L7g3rX
cJbxVKUBinznnDFZ3Z3r5RAM1dXRrVvUkKHzewBHtZSOzlXFEnj+vmw2XCu1rrph
wdJURfX19KuONjGfkzLw5c3geL9nOwBfBP0D62DsivP2kdcpNCt7N/szFvB6ICUQ
FcCGI57KGCGYGG3EF9SmbFrb0YORO5iR149SEXeoLzWz5O7rlqK5NClPOiyITIv2
n4yrbq7PlXZny3d9IRx801fhpetRKmmtRLHau+SmR4nf79VN/le7uee/Sehx+2bO
WGyQZG+UO8brLozVvtNYutFVOphfO1YKOACKZfBmzCD1zGmEG8O1/9ApeMzlsnjE
Bpg9fXS3YgPEKDSXFtS6wafz+CH+JuSHAhpkUVQ1I7XMHa/SGIVHAeRi4FCUZo6i
8iRnMVbD+4R8F6NupRvFQ7qeOnfI4E7wDfGYjW7sUd2XF/yVFsRALBiHaExCVp0g
dG8GnIcirHHy+w3GwbUj
=YI9Z
-END PGP SIGNATURE-

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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ramon,

On 5/29/15 4:42 PM, Ramon Pfeiffer wrote:
> On 29.05.2015 21:12, Christopher Schultz wrote:
>> Ramon,
>> 
>> On 5/29/15 3:32 AM, Ramon Pfeiffer wrote:
>>> Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
> From: Ramon Pfeiffer
> [mailto:ramon.pfeif...@uni-tuebingen.de] Subject: Problem
> specifying cipher suites in tomcat6
 
> I'm currently trying to specify a list of cipher suites to
> be used by my connector in Tomcat 6.0.24.
 
> Anybody can shed some light on what I did wrong?
 
 Using a version of Tomcat that's more than five years old is
 the first thing - there have been many, many security fixes
 since then, including some related to the ciphers attribute.
 You also need to tell us the JVM version, the platform you're
 running on, and whether or not APR is in use for this
  (it's in the logs).
>> 
>>> Sadly, it's a system I inherited last year and now have the 
>>> pleasure to work with. I can't update Tomcat for I don't know
>>> what will break.
>> 
>> If you can't upgrade it, you are better-off shutting-down the
>> service, because there are security vulnerabilities in there.
>> 
>> So, ask your boss which is worse: shuttering the project, or
>> getting a new version of Tomcat into a testing environment?
> 
> Shutting it down is not an option. So I guess next week will be... 
> interesting.
> 
> The important thing is this: Will the connector work in this 
> configuration after I updated Tomcat? Or is the issue completely 
> unrelated? Where are the ciphers shown by ssllabs taken from? Is
> the cipher attribute ignored?

Lots of things have been fixed/added in more recent versions of Tomcat
6.0.x. Please give a quick test against Tomcat 6.0.latest: you don't
even need to deploy your own web application on it; just configure it
for SSL and hit the default web application (the Tomcat
documentation), or the examples, or whatever.

SSLLabs picks the ciphers it wants to check for; usually a group of
"good" ciphers to make sure that you can support the
latest-and-greatest ciphers, plus a bunch of them that are known to be
broken (like most SSL-only ones).

This tool may help you test, because it's a whole lot faster than
SSLLabs' tests:
http://markmail.org/message/tz4z44nfjl7sy2lj

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaNqzAAoJEBzwKT+lPKRYyyIP/AxaJNDI8C98lGUGP4bqOFsm
ZSxcfQG44mAFwBAMkW2oxfCCD7MDb8y9jQT5qyEv+eEgLd9kFjG1UOXogDKAm6dI
d8lh10FSI/Wk4o7OMuWl7nCE8APzUAMCojJz3RxvMvJwFpyP6Te7Zl8baNHXUl2U
zir68R9fTjT/UT9Wps6+gg5UWS/v08gzeBarizdk3QHtQrgXJamF9aLgJ+L7g3rX
cJbxVKUBinznnDFZ3Z3r5RAM1dXRrVvUkKHzewBHtZSOzlXFEnj+vmw2XCu1rrph
wdJURfX19KuONjGfkzLw5c3geL9nOwBfBP0D62DsivP2kdcpNCt7N/szFvB6ICUQ
FcCGI57KGCGYGG3EF9SmbFrb0YORO5iR149SEXeoLzWz5O7rlqK5NClPOiyITIv2
n4yrbq7PlXZny3d9IRx801fhpetRKmmtRLHau+SmR4nf79VN/le7uee/Sehx+2bO
WGyQZG+UO8brLozVvtNYutFVOphfO1YKOACKZfBmzCD1zGmEG8O1/9ApeMzlsnjE
Bpg9fXS3YgPEKDSXFtS6wafz+CH+JuSHAhpkUVQ1I7XMHa/SGIVHAeRi4FCUZo6i
8iRnMVbD+4R8F6NupRvFQ7qeOnfI4E7wDfGYjW7sUd2XF/yVFsRALBiHaExCVp0g
dG8GnIcirHHy+w3GwbUj
=YI9Z
-END PGP SIGNATURE-

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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Ramon Pfeiffer
On 29.05.2015 21:12, Christopher Schultz wrote:
> Ramon,
> 
> On 5/29/15 3:32 AM, Ramon Pfeiffer wrote:
>> Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
 From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de] 
 Subject: Problem specifying cipher suites in tomcat6
>>>
 I'm currently trying to specify a list of cipher suites to be
 used by my connector in Tomcat 6.0.24.
>>>
 Anybody can shed some light on what I did wrong?
>>>
>>> Using a version of Tomcat that's more than five years old is the
>>> first thing - there have been many, many security fixes since
>>> then, including some related to the ciphers attribute.  You also
>>> need to tell us the JVM version, the platform you're running on,
>>> and whether or not APR is in use for this  (it's in
>>> the logs).
> 
>> Sadly, it's a system I inherited last year and now have the
>> pleasure to work with. I can't update Tomcat for I don't know what
>> will break.
> 
> If you can't upgrade it, you are better-off shutting-down the service,
> because there are security vulnerabilities in there.
> 
> So, ask your boss which is worse: shuttering the project, or getting a
> new version of Tomcat into a testing environment?

Shutting it down is not an option. So I guess next week will be...
interesting.

The important thing is this: Will the connector work in this
configuration after I updated Tomcat? Or is the issue completely
unrelated? Where are the ciphers shown by ssllabs taken from? Is the
cipher attribute ignored?

Thanks so far for all your responses (and corresponding warnings)!

Ramon



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Sean Dawson
On Fri, May 29, 2015 at 3:30 PM, George Stanchev 
wrote:

> I don't see where he blamed the developers for anything. The poster even
> admitted it was their fault. I think it is reasonable to warn the OP that
> any change can result in issue. Even if you're doing everything correctly,
> there is a change of running in a new Tomcat issue or a regression or what
> not.
>
> We as developers know that corner cases that have 1% of happening occur
> 50% of the time ;-)
>
> Any application server upgrade should be tested before deployed...
>
> My 2c
>
> George
>
>
Thanks George.  There was also the change to unpack WAR files by default to
the webapps folder (or something along those lines) and the bug related to
certain cases of not being able to turn that back off... "A known issue
with FastDataInputStream  (57173). See the changelog."

Not intending to be antagonistic - just trying to give fair warning to OP.

-Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Friday, May 29, 2015 12:12 PM
> To: Tomcat Users List
> Subject: Re: Problem specifying cipher suites in tomcat6
>
> Sean Dawson wrote:
> > I had significant problems trying to uncover a change in tomcat7 that
> > broke our app when upgrading from 42 to 57, for a couple weeks over
> > Christmas holidays.
> >
> > Turns out it was something we shouldn't have been doing -
>
> you mean, apart from top-posting here ?
>
> but it was
> > definitely a change in tomcat (51 or so) that resulted in the issue(s).
> >
> > Just something to keep in mind.
> >
>
> Well yes, but in all truth, if you were doing something which you should
> not have been doing - and bonus points for admitting it - then you cannot
> really blame the tomcat developers for making a change which broke it, even
> over Christmas, can you ?
>
> At the contrary, you should be grateful : the fact that the change pointed
> out the bad thing in your code, may have prevented the later advent of a
> nuclear war.  That would have been even less fun over Christmas.
>
> As a concession, maybe George's post below could have been prefixed with
> "If your code is well-behaved, .."
>
>
> >
> > On Fri, May 29, 2015 at 11:43 AM, George Sexton 
> > wrote:
> >
> >>
> >> On 5/29/2015 5:16 AM, David kerber wrote:
> >>
> >>> On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:
> >>>
>  Sadly, it's a system I inherited last year and now have the pleasure
> to
>  work with. I can't update Tomcat for I don't know what will break.
> 
> >>> There's a fair chance that you can update to the latest version of TC 6
> >>> without anything breaking, but of course that's not guaranteed.
> >>>
> >> I can think of very few instances where a change in Tomcat broke my app.
> >> The only one I can really remember was a change that I initiated :)
> >>
> >>
> >> --
> >> George Sexton
> >> *MH Software, Inc.*
> >> Voice: 303 438 9585
> >> http://www.mhsoftware.com
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


RE: Problem specifying cipher suites in tomcat6

2015-05-29 Thread George Stanchev
I don't see where he blamed the developers for anything. The poster even 
admitted it was their fault. I think it is reasonable to warn the OP that any 
change can result in issue. Even if you're doing everything correctly, there is 
a change of running in a new Tomcat issue or a regression or what not.

We as developers know that corner cases that have 1% of happening occur 50% of 
the time ;-)

Any application server upgrade should be tested before deployed...

My 2c

George

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Friday, May 29, 2015 12:12 PM
To: Tomcat Users List
Subject: Re: Problem specifying cipher suites in tomcat6

Sean Dawson wrote:
> I had significant problems trying to uncover a change in tomcat7 that 
> broke our app when upgrading from 42 to 57, for a couple weeks over 
> Christmas holidays.
> 
> Turns out it was something we shouldn't have been doing -

you mean, apart from top-posting here ?

but it was
> definitely a change in tomcat (51 or so) that resulted in the issue(s).
> 
> Just something to keep in mind.
> 

Well yes, but in all truth, if you were doing something which you should not 
have been doing - and bonus points for admitting it - then you cannot really 
blame the tomcat developers for making a change which broke it, even over 
Christmas, can you ?

At the contrary, you should be grateful : the fact that the change pointed out 
the bad thing in your code, may have prevented the later advent of a nuclear 
war.  That would have been even less fun over Christmas.

As a concession, maybe George's post below could have been prefixed with "If 
your code is well-behaved, .."


> 
> On Fri, May 29, 2015 at 11:43 AM, George Sexton 
> wrote:
> 
>>
>> On 5/29/2015 5:16 AM, David kerber wrote:
>>
>>> On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:
>>>
 Sadly, it's a system I inherited last year and now have the pleasure to
 work with. I can't update Tomcat for I don't know what will break.

>>> There's a fair chance that you can update to the latest version of TC 6
>>> without anything breaking, but of course that's not guaranteed.
>>>
>> I can think of very few instances where a change in Tomcat broke my app.
>> The only one I can really remember was a change that I initiated :)
>>
>>
>> --
>> George Sexton
>> *MH Software, Inc.*
>> Voice: 303 438 9585
>> http://www.mhsoftware.com
>>
> 


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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ramon,

On 5/29/15 3:32 AM, Ramon Pfeiffer wrote:
> Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
>>> From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de] 
>>> Subject: Problem specifying cipher suites in tomcat6
>> 
>>> I'm currently trying to specify a list of cipher suites to be
>>> used by my connector in Tomcat 6.0.24.
>> 
>>> Anybody can shed some light on what I did wrong?
>> 
>> Using a version of Tomcat that's more than five years old is the
>> first thing - there have been many, many security fixes since
>> then, including some related to the ciphers attribute.  You also
>> need to tell us the JVM version, the platform you're running on,
>> and whether or not APR is in use for this  (it's in
>> the logs).
> 
> Sadly, it's a system I inherited last year and now have the
> pleasure to work with. I can't update Tomcat for I don't know what
> will break.

If you can't upgrade it, you are better-off shutting-down the service,
because there are security vulnerabilities in there.

So, ask your boss which is worse: shuttering the project, or getting a
new version of Tomcat into a testing environment?

> Anyway, I'm working on a RHEL6 system. A java -version yields #
> java -version java version "1.7.0_79" OpenJDK Runtime Environment
> (rhel-2.5.5.3.el6_6-x86_64 u79-b14) OpenJDK 64-Bit Server VM (build
> 24.79-b02, mixed mode)

So, no problem keeping the JVM up-to-date. You must have a testing
process for that, right? Just use the same testing process after
upgrading Tomcat. Once you're up-to-date on Tomcat 6.0.x, go ahead and
try again with Tomcat 8.0.x.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaLoeAAoJEBzwKT+lPKRYOq4P/RiGBu4V/2MXWkfSTzTaE9t7
rEDNibD6hMyWIGhuqlbAaZJ/jnUB8Hnnnu6TPttkhDCXxasKybC6htK4GlzHj8J8
vH4a0DfMR4NM3JQs4M38XYpl78mTMgv5079cHMasJsOfNpiGpJLIqyOTFB/LQV+i
h8W1PLLBPQrbRITgAJNfAMUrvCQoRGx61Z8yptRA6TMN/jLEERGIJf20xBMqvBdW
08btc/o2LLVtsXctw7tlx/4FRyV9VxOEWwf9vYp4q4tGc1Rhiu4uB6YvC9PvVZQI
FmElHOpwSq+GeauBlaRb2Y3EUEdPC1hZsmvHsy68X87Ni2gUT+7og7CygspWHmiV
Hq9C4z/mo4lQWnHQfFmEx0hJ8tmiRyumtfZD01D8cnYWdW9eBH6J7bGeQVh81jx8
JYbqbIWkDEKpNhUIN7czlX1T/SNcA6+VGynajILx1+qHf6FbFyVJLbpElSKVV1UX
YmXS6qIX7DlKvn80nZ81NB+WcmnfxZR7cn2ppKLGZyMSvVvY1AOXXF3vrFXfB2SG
2WZz4RbCulSY+s8qxzwhfhSagGWyn9ua5WrmDzeJ9tBplguIdvdHoXpwWOPbd3cW
vlcgk9EYP2ooWawrQY+ltGNffuqtYzxjwrfo63PYAMuZDXpksSp5YJtDv4L+gsec
s4wSnVMBakZ4lm70I/4/
=mSi+
-END PGP SIGNATURE-

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



Re: [OT] FormAuthenticator, Tomcat restart

2015-05-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 5/29/15 2:47 AM, André Warnier wrote:
> Leonid Rozenblyum wrote:
>> Hello, Christopher! I indeed meant this "The Tomcat restart
>> between showing and submitting the login page is the source of
>> the problem."
>> 
>> Your explanation clarifies the core of the issue well!
>> 
>> I'll dig into the Tomcat documentation deeper to find out how to 
>> inject that custom login handler.
>> 
>> Thanks!
>> 
>> On Thu, May 28, 2015 at 6:49 PM, Christopher Schultz 
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Mark,
>>> 
>>> On 5/28/15 5:29 AM, Mark Thomas wrote:
 On 28/05/2015 10:22, Leonid Rozenblyum wrote:
> Hello experts.
> 
> We are using FormAuthenticator and face a following issue:
> 
> 1) Session persistence is disabled 2) User is on login page
> 3) Restart Tomcat 4) User tries authentication
> 
> He receives error 400 or 408.
> 
> While digging deeper we discovered that in this case
> Tomcat validates session id and if it's old/invalid -
> prevents logging-in even though valid credentials are
> passed.
> 
> We tried landingPage solution - it looks better than error 
> 400/408 but anyway it forces user to enter credentials
> twice (or we don't know how to pass credentials to
> landingPage implicitly).
> 
> We think that an improvement of user experience would be :
> 
> FormAuthenticator: 255 if (session == null) { session = 
> request.getSessionInternal(false); }
> 
> ==> if (session == null) { session = 
> request.getSessionInternal(true); }
> 
> So if session is invalid or missing - simply create it.
> 
> Does this idea make sense?
 No. It makes no sense at all.
 
> Can we achieve the goal of not forcing user entering
> credentials twice without changes in Tomcat ?
 No. The credentials are stored in the session. If you
 restart Tomcat with session persistence disabled those
 credentials are lost and the user is going to have to
 re-enter them.
>>> I think the OP is saying that the credentials are only entered
>>> a single time. The Tomcat restart between showing and
>>> submitting the login page is the source of the problem.
>>> 
>>> Leonid, the servlet spec is very clear about the workflow for 
>>> authentication: the client must request a protected resource,
>>> then the container challenges the client for authentication
>>> (shows the login page), and then the client must submit valid
>>> credentials (send a request to j_security_check). After that,
>>> the container must re-process the client's original request
>>> with the newly-authenticated principal.
>>> 
>>> Tomcat stores the original request in the session. If you lose
>>> your session between presenting the login page and submitting
>>> the credentials, Tomcat has no way to re-process the original
>>> request.
>>> 
>>> IMO, this is a hole in the spec, because it doesn't allow
>>> people to login simply because they want to; instead, they must
>>> first attempt to reach a protected resource.
>>> 
>>> If you want your users to be able to login without requesting
>>> a protected resource, you may write your own login-handler and
>>> call ServletRequest.login(). That way, you won't require a
>>> session to exist during that whole workflow.
>>> 
>>> - -chris
> 
> It all begs the question, by pure curiosity if nothing else, of
> how often the OP restarts his Tomcat, that this issue seems to
> bother him so. Last time I looked, my 20-odd Tomcats had been
> running for some 240 days or so.

... then they are overdue for an upgrade ;)

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaLlQAAoJEBzwKT+lPKRYOewP/3lqUehWgT5s6SjDVRw/sxtS
SbCUGEL5UrRjUnTZ9v9emsUFsq6ZO/agXJ6c2sgcJQW/MIC4rprvndvh7r+aSTs6
68H25F037Lg9GyNe9qZVCg49MMPF4BBfuIOfSRkP2uEZ0lIxge0tE54+rqlcZgvK
jx5A1A71aEg58tbJeaeCUiRrXdlznlajwcUEl6n5KR6YKNntVax/TeJ68Y9/RA6l
yT2E+9EarNeTaQ8MdkihUb9g7t9z7x4IzkA3RCa5ZQ7FicAzX3A0AC3Rd4Wi/eI2
I7CmPcV7CHtPuuVfAyeqEtOU2QRzPZb4GDt8rGDvwT8H7tsXBf+YpyIK+vEYcC/u
U0dRq0/9dtUCJhxYIIyub8wrLB5XIVIAVN1KvI+Vis27oXMPp+OwLVsVCy4p6WEP
HK/I3faqIspw5lRBB3TIMA7s7jWliai/G1vC/koIuNBNL5wbOcmsDKDKd1sfkbpq
ZfT5uRdfBdKdRYTkpoupOScgLBuhb6LW7U75nvmaN5T0Uk5eEwU1+OC2LCwK42bJ
CCtY59qUz/5G+mvgDIODipQuOZxmk2mz67lvRheASskD58zUrk0F7OAeVB9KBIUR
ahD6fANtAmR5TINj+ZZI7yvjxl1jqwE3fzl4QwfLOx9ZbBCH9Ic8y3iqRk4mUgEq
ZR2bLVBn3SIePIT5HLar
=xXzw
-END PGP SIGNATURE-

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



Re: Tomcat Valve doing Request.getParameter() consumes the stream

2015-05-29 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter,

On 5/28/15 3:44 PM, Teunissen,Peter wrote:
> (Tomcat 7)
> 
> I am writing a Valve that does a getParameter on the Request. At
> the end of the Valve/Filter chain is a servlet that calls
> HttpServletRequest.getReader() returning an empty buffer (because
> the Valve consumed it).
> 
> I tried hacking a wrapper for the Request together and pass that
> into the getNext().invoke , but not much luck yet (seems to be some
> state in the underlying coyoteStream/Request/Inputbuffer)
> 
> I can't imagine I'm the first to encounter this and yet I can't
> find a good wrapper example on the internet.
> 
> Anybody better suggestions?

You might be able to adapt this Filter I wrote to do the same thing:

http://markmail.org/thread/fumpfuspt7a3nesz

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVaLkcAAoJEBzwKT+lPKRYZegP/RJ3bJe2aZh2LGkXYjSCb1wn
KUdkscj0PrpT4uRMNDsoLkBMhzzJc33EjUNvlz60eNjUh0hL/PZ2aIV0suxJ+g83
KeziNOah6goaiJ77PgyyV9MFx76T24EvTgQPRAgKUrN84cbk8uGQ/iY2rBrM4A+7
CDUUEOHTb5oLq/s/oEEEDdC06XXCY/O03p+5WMPb5StEvYr2f8Iipa6AX7sYxlDT
D7i5z4kJnR4iYWmz7tU0FP7c0R0n5Mxz/alpoiydv2Gnfxb9wNY6wdge4td5fwIO
/QXqDGb/nDA7dpvzTYMQq8Fozi6sjxV7z6Au7P19TFQxbKBjYq5LEyh7B4FD88nO
QKuW8uyTcz0A028XWuy2Vu61LE5uGuHllXOrQjycZsTeH3FIyxJ5gRsKtlhxSrNw
2MVS2FxAG7J3mvM+RDMsethJsfAmF3p3CM3UeOB70vOghBnkPl5fHThJ2uwle6YT
yoy8n91Ls+ErWo+JFhHM5KTrX29MrT7l8berUSIhsMS5p1rw8Qu3WlIF4UT406yo
4LVPYSBfnem5aJa1Zfcc/fWVoWzNOeOUgpgsV2B2bPPSm2yBBtyAli2q+BGRBwSb
vtddKILo+RkujAId5OIFAfluw+nuiBqAGTBQRKc4pKFB7yIOmmuUH/a3E689jaCj
vtFSyy0acGimDfmQyXAE
=QES6
-END PGP SIGNATURE-

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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread André Warnier

Sean Dawson wrote:

I had significant problems trying to uncover a change in tomcat7 that broke
our app when upgrading from 42 to 57, for a couple weeks over Christmas
holidays.

Turns out it was something we shouldn't have been doing - 


you mean, apart from top-posting here ?

but it was

definitely a change in tomcat (51 or so) that resulted in the issue(s).

Just something to keep in mind.



Well yes, but in all truth, if you were doing something which you should not have been 
doing - and bonus points for admitting it - then you cannot really blame the tomcat 
developers for making a change which broke it, even over Christmas, can you ?


At the contrary, you should be grateful : the fact that the change pointed out the bad 
thing in your code, may have prevented the later advent of a nuclear war.  That would have 
been even less fun over Christmas.


As a concession, maybe George's post below could have been prefixed with "If your code is 
well-behaved, .."





On Fri, May 29, 2015 at 11:43 AM, George Sexton 
wrote:



On 5/29/2015 5:16 AM, David kerber wrote:


On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:


Sadly, it's a system I inherited last year and now have the pleasure to
work with. I can't update Tomcat for I don't know what will break.


There's a fair chance that you can update to the latest version of TC 6
without anything breaking, but of course that's not guaranteed.


I can think of very few instances where a change in Tomcat broke my app.
The only one I can really remember was a change that I initiated :)


--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com






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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Sean Dawson
I had significant problems trying to uncover a change in tomcat7 that broke
our app when upgrading from 42 to 57, for a couple weeks over Christmas
holidays.

Turns out it was something we shouldn't have been doing - but it was
definitely a change in tomcat (51 or so) that resulted in the issue(s).

Just something to keep in mind.


On Fri, May 29, 2015 at 11:43 AM, George Sexton 
wrote:

>
>
> On 5/29/2015 5:16 AM, David kerber wrote:
>
>> On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:
>>
>>>
>>> Sadly, it's a system I inherited last year and now have the pleasure to
>>> work with. I can't update Tomcat for I don't know what will break.
>>>
>>
>> There's a fair chance that you can update to the latest version of TC 6
>> without anything breaking, but of course that's not guaranteed.
>>
>
> I can think of very few instances where a change in Tomcat broke my app.
> The only one I can really remember was a change that I initiated :)
>
>
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.mhsoftware.com
>


RE: native API - to make Apache/Tomcat faster

2015-05-29 Thread Jeffrey Janner
> -Original Message-
> From: Christoph P.U. Kukulies [mailto:k...@kukulies.org]
> Sent: Tuesday, May 26, 2015 9:37 AM
> To: Tomcat Users List
> Subject: Re: native API - to make Apache/Tomcat faster
> 
> Am 26.05.2015 um 15:36 schrieb Christopher Schultz:
> >
> > So you are using either mod_proxy_ajp or mod_proxy?
> 
> mod_proxy
> 
> 
> >
> > Are you using TLS anywhere in the mix? (I should hope so, since you
> > are deploying a CMS). Does httpd terminate TLS? Do you encrypt the
> > connection(s) between httpd and Tomcat using TLS?
> 
> No, not using TSL between Apache and tomcat. Using secure http (https)
> is
> planned to be used soon.
> 
> >> We are observing that the server sometimes delivers pages
> >> incompletely.
> > Have you been able to determine if Tomcat is not sending the whole
> > page, or if httpd is not proxying the whole page?
> 
> I have not yet found the time to debug the connection and to locate the
> actual
> missing pieces. It just seems that some js or css is not being loaded
> since the source
> code of the page itself is there.
> 
> >
> >> Portions of the page do not show and trying to restart the service
> >> results in a time out.
> > A time out where? The service-restart times out, or after a service
> > restart, requests time out?
> 
> When I type NET STOP tomcat7 on the server to stop the service, it
> hangs. Normally
> the service should be shut down smoothly.
> 
From my experience, this is a symptom that indicates that the JVM has died but 
the service wrapper didn't catch it and is still running. Or perhaps just an 
important thread died in the JVM.  Check your Tomcat and application logs for 
errors (OOM errors particularly exhibit this symptom).

> >
> > I'm unaware of any problems when up-to-date versions of all components
> > are being used.
> >
> >> The rebooting the server is a cure.
> > That seems to be a popular cure with Microsoft Windows servers ;)
> >
> >
> --
> Christoph
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread George Sexton



On 5/29/2015 5:16 AM, David kerber wrote:

On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:


Sadly, it's a system I inherited last year and now have the pleasure to
work with. I can't update Tomcat for I don't know what will break.


There's a fair chance that you can update to the latest version of TC 
6 without anything breaking, but of course that's not guaranteed.


I can think of very few instances where a change in Tomcat broke my app. 
The only one I can really remember was a change that I initiated :)



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com


RE: can we pass OS username while connection Database from Tomcat

2015-05-29 Thread Jeffrey Janner
Please see response below post:

> -Original Message-
> From: Vijay Kumar [mailto:vijy.gan...@gmail.com]
> Sent: Thursday, May 28, 2015 7:22 AM
> To: Tomcat Users List
> Subject: Re: can we pass OS username while connection Database from
> Tomcat
> 
> Hi ,
> 
> I am referring User_Id as Linux User_id where we installed Tomcat.
> 
> My Oracle Database don't know about this user_id.
> 
> 
> Thanks,
> Vijay G
> 
Vijay -
As another tomcat->oracle integrator, I do have to ask, exactly what is it your 
client is trying to monitor and what tool is he going to use?
But first let's clarify the question:
1) Tomcat is running as the O/S user "apps" and your client wants to 
see the connections from O/S user apps?  And why?  This may already be 
available in the database structures.
or
2) Tomcat is connecting to the database using the schema name "apps" 
and the client want to see these connections?  That's already available on the 
Oracle side.  This depends on what tool the client is using.
Or
3) the client wants to see the user names of the application users in 
the monitoring tool?  Depending on this answer and the tool used, you are 
really getting into Oracle programming territory, as there are several ways to 
do this. 

As for answering the straight-forward question, a quick Google search found 
several replies, all requiring changes to the application code that connects to 
the database. Actually from what I understand, the Oracle drivers already 
provide this, at least the latest versions.

Jeff


> On Thu, May 28, 2015 at 3:20 PM, André Warnier  wrote:
> 
> > Vijay Kumar wrote:
> >
> >> Hi Mark,
> >>
> >> Please find below my exact requirement.
> >>
> >> I have Oracle Database where my objects are installed and I have also
> a
> >> Linux instance where i installed Tomcat.
> >> I am currently creating connection to the Oracle database from Tomcat
> >> using
> >> 'apps' user as this schema is having all permissions.
> >>
> >> One of my client want to monitor the connections that are created
> from my
> >> application. For this i want to pass my Linux user information
> (userid)
> >> while creating the connection from my application or in context.xml
> file.
> >>
> >> Please suggest the approaches? If SPENGO can you redirect me any
> doc/post
> >> how to achieve this?
> >>
> >>  Vijay,
> > you are repeating yourself (and still top-posting), but you are not
> > providing the crucial information which would enable someone to really
> help
> > you.
> > For example, what "Linux user information (userid)" are you talking
> about ?
> >
> > Is it the Linux user-id under which Tomcat is running ?
> > That would probably be "tomcat", so that is probably not going to help
> you
> > fulfill your customer's wishes.
> >
> > Is it the user-id of the /user/ of your Tomcat application ?
> > In that case, how does Tomcat know this user-id ? Do the users login
> into
> > your application ? How ? What is the user authentication mechanism
> being
> > used, now, at the Tomcat level ?
> >
> > Does the Oracle database also know this user-id ? How ?
> >
> > What does "One of my client want to monitor the connections" mean,
> exactly
> > ? what does the customer want to know, and when ? Is this customer the
> only
> > user/manager of the Oracle database, or are there multiple
> users/managers
> > of the Oracle database ?
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

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



RE: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Jeffrey Janner
> -Original Message-
> From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
> Sent: Friday, May 29, 2015 2:33 AM
> To: users@tomcat.apache.org
> Subject: Re: Problem specifying cipher suites in tomcat6
> 
> Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:
> >> From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
> >> Subject: Problem specifying cipher suites in tomcat6
> >
> >> I'm currently trying to specify a list of cipher suites to be used by
> my
> >> connector in Tomcat 6.0.24.
> >
> >> Anybody can shed some light on what I did wrong?
> >
> > Using a version of Tomcat that's more than five years old is the first
> thing - there have been many, many security fixes since then, including
> some related to the ciphers attribute.  You also need to tell us the JVM
> version, the platform you're running on, and whether or not APR is in
> use for this  (it's in the logs).
> 
> Sadly, it's a system I inherited last year and now have the pleasure to
> work with. I can't update Tomcat for I don't know what will break.
> 
> Anyway, I'm working on a RHEL6 system. A java -version yields
> # java -version
> java version "1.7.0_79"
> OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> 
> APR is not installed.
> 
> Thanks,
> Ramon
You should be able to upgrade to the latest version of Tomcat 7 with little to 
no problem. 
Get the latest release from the tomcat website, not the Red Hat RPM and you can 
install it in parallel with your existing Tomcat, so you can switch back 
quickly if you do experience a problem related to the upgrade.
You will need to migrate your server.xml file and possibly you context.xml 
files as well, though unlikely in the latter case.
I know that a lot depends on how tightly integrated your app is with tomcat, 
but I made the migration with almost no difficulty years ago.
Jeff 

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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread David kerber

On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:

Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:

From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
Subject: Problem specifying cipher suites in tomcat6



I'm currently trying to specify a list of cipher suites to be used by my
connector in Tomcat 6.0.24.



Anybody can shed some light on what I did wrong?


Using a version of Tomcat that's more than five years old is the first
thing - there have been many, many security fixes since then,
including some related to the ciphers attribute.  You also need to
tell us the JVM version, the platform you're running on, and whether
or not APR is in use for this  (it's in the logs).


Sadly, it's a system I inherited last year and now have the pleasure to
work with. I can't update Tomcat for I don't know what will break.


There's a fair chance that you can update to the latest version of TC 6 
without anything breaking, but of course that's not guaranteed.





Anyway, I'm working on a RHEL6 system. A java -version yields
# java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)


The fact that you're on a recent Java version will help a lot.




APR is not installed.

Thanks,
Ramon




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



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Ramon Pfeiffer

Am 28.05.2015 um 18:56 schrieb Caldarale, Charles R:

From: Ramon Pfeiffer [mailto:ramon.pfeif...@uni-tuebingen.de]
Subject: Problem specifying cipher suites in tomcat6



I'm currently trying to specify a list of cipher suites to be used by my
connector in Tomcat 6.0.24.



Anybody can shed some light on what I did wrong?


Using a version of Tomcat that's more than five years old is the first thing - there 
have been many, many security fixes since then, including some related to the ciphers 
attribute.  You also need to tell us the JVM version, the platform you're running on, 
and whether or not APR is in use for this  (it's in the logs).


Sadly, it's a system I inherited last year and now have the pleasure to 
work with. I can't update Tomcat for I don't know what will break.


Anyway, I'm working on a RHEL6 system. A java -version yields
# java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)

APR is not installed.

Thanks,
Ramon



smime.p7s
Description: S/MIME Cryptographic Signature