Re: Bizarre getParameterMap() failure

2014-04-09 Thread André Warnier 

Jess Holle wrote:
FYI, it would appear that this is a case of someone passing a 
ServletRequest object to another thread and invoking methods on it at 
just the wrong point in time so as to utterly corrupt a later request.  
Changing the code to make an appropriate copy of the ServletRequest 
object and pass that instead has resolved our issue.


At a more general level, I certainly understand that the ServletRequest 
interface makes no guarantees about thread safety -- and performance 
reasons for not making the implementation thread-safe.  That said, it's 
certainly quite surprising to see this impact later requests due to 
recyling behavior!




In any case, thanks for reporting the resolution of the issue, and the way in which it was 
resolved.
Some people never do that and it is annoying, because it leaves an inconclusive trace in 
the archives, possibly causing someone else in the future to be misled and waste time 
chasing dead-ends.



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

Re: Bizarre getParameterMap() failure

2014-04-09 Thread Jess Holle 
FYI, it would appear that this is a case of someone passing a 
ServletRequest object to another thread and invoking methods on it at 
just the wrong point in time so as to utterly corrupt a later request.  
Changing the code to make an appropriate copy of the ServletRequest 
object and pass that instead has resolved our issue.


At a more general level, I certainly understand that the ServletRequest 
interface makes no guarantees about thread safety -- and performance 
reasons for not making the implementation thread-safe.  That said, it's 
certainly quite surprising to see this impact later requests due to 
recyling behavior!


--
Jess Holle

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

Temporary mitigation of Heartbleed?

2014-04-09 Thread Jeffrey Janner 
Much as I loathe downgrading, would it be possible/advisable to downgrade the 
native libraries to 1.1.23 with Tomcat 7.0.50?
That version is the last to use a pre-1.0.1  version of OpenSSL (1.0.0g).
This could help us at least until we get a blessed version from the APR team?

Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.com
PolyDyne Software Inc.
Main:   512.343.9100
Direct:  512.583.8930

 [cid:image002.png@01CC0FB7.4FF43CE0]

Speed, Intelligence & Savings in Sourcing

RE: How can I tell which version of OpenSSL is being used with tomcat?

2014-04-09 Thread Jeffrey Janner 
> -Original Message-
> From: Andrew Russell [mailto:andrew.russ...@gmail.com]
> Sent: Wednesday, April 09, 2014 12:02 PM
> To: users@tomcat.apache.org
> Subject: How can I tell which version of OpenSSL is being used with
> tomcat?
> 
> If I installed tomcat on windows using the service installer, how can I
> know which version of openssl was used?
[Jeff Janner] 

Did you select the Native Libraries when you ran the installer?
If so, you are most likely to be using OpenSSL for SSL services.
How can you be sure?
Do you have any  set up to use SSL?  Did you specify the protocol 
parameter when you created the connector?  If not, then the default is to use 
the APR library if the Native Libraries are available and the APR Lifecycle 
Listener is in your server.xml and the SSLEngine is set to "on".
In other words, you'll need to review your server.xml and the tomcat 
documentation on configuring Tomcat to see if you are vulnerable.

However, a perhaps easier way is to check your latest catalina.log file.  If it 
contains this line:
INFO: OpenSSL successfully initialized (OpenSSL 1.0.1e 11 Feb 2013)
Then you are susceptible (any version 1.0.1 < 1.0.1g).

Also, if you do have the native libraries in the bin directory, you can check 
its version by hovering over the tcnative-1.dll file and checking the value of 
File Version.  The latest is 1.1.29, which has the bug.  I'm not sure at which 
release the bug was introduced.
Anyone?


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

Re: How can I tell which version of OpenSSL is being used with tomcat?

2014-04-09 Thread James H. H. Lampert 

On 4/9/14 10:17 AM, Andrew Russell wrote:


Thank you for the quick response!

It's a mixed bag, some are java keystores and some are pfx files.

So I'm only using OpenSSL if it's marked as such in the configuration file?


All I know is JSSE, myself.

From our own server.xml, running with security by JSSE, on an IBM 
Midrange system (the names have been changed to protect the innocent):








--
JHHL

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

Re: How can I tell which version of OpenSSL is being used with tomcat?

2014-04-09 Thread Andrew Russell 
On Wed, Apr 9, 2014 at 12:13 PM, James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

> On 4/9/14 10:01 AM, Andrew Russell wrote:
>
>> If I installed tomcat on windows using the service installer, how can I
>> know which version of openssl was used?
>>
>
> All I know is that if you're using a Java keystore and Keytool (or
> KeyStore Explorer) to set it up and maintain it, you're most likely not
> using ANY version of OpenSSL; you're using JSSE (which isn't affected by
> HeartBleed) instead.
>
> Given that I've never set up security for Tomcat on any platform other
> than an IBM Midrange system (on which JSSE seems to be the only viable
> choce for SSL in Tomcat), I was actually rather astonished when I first
> learned that other platforms usually used OpenSSL.
>
> --
> JHHL
>
>
Thank you for the quick response!

It's a mixed bag, some are java keystores and some are pfx files.

So I'm only using OpenSSL if it's marked as such in the configuration file?

Re: How can I tell which version of OpenSSL is being used with tomcat?

2014-04-09 Thread James H. H. Lampert 

On 4/9/14 10:01 AM, Andrew Russell wrote:

If I installed tomcat on windows using the service installer, how can I
know which version of openssl was used?


All I know is that if you're using a Java keystore and Keytool (or 
KeyStore Explorer) to set it up and maintain it, you're most likely not 
using ANY version of OpenSSL; you're using JSSE (which isn't affected by 
HeartBleed) instead.


Given that I've never set up security for Tomcat on any platform other 
than an IBM Midrange system (on which JSSE seems to be the only viable 
choce for SSL in Tomcat), I was actually rather astonished when I first 
learned that other platforms usually used OpenSSL.


--
JHHL


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

How can I tell which version of OpenSSL is being used with tomcat?

2014-04-09 Thread Andrew Russell 
If I installed tomcat on windows using the service installer, how can I
know which version of openssl was used?

RE: Windows tcnative openssl ciphers question

2014-04-09 Thread Jeffrey Janner 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, April 08, 2014 6:27 PM
> To: Tomcat Users List
> Subject: Re: Windows tcnative openssl ciphers question
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 4/7/14, 4:07 PM, Jeffrey Janner wrote:
> > Ok, this is a question for the native libs builders (or whoever knows
> > the answer). Environment:  Windows Server 2008 R2, Tomcat
> > 7.0.50 w/APR 1.1.29, Java 1.7.0_51  (all 64-bit) I'm trying to set up
> > a ciphers list that will get me an "A" rating on Qualys' SSL testing
> > tool.
> 
> Did you read their guide? Certain factors limit your rating to B no
> matter what else happens. Lots of those factors are quite common in
> real-world deployments.
> 
I actually managed to earn an A- rating, since I was only missing the ECDHE 
support to get Forward Secrecy to work on the IE browser family.
At least I had one until the Heartbleed bug raised its ugly head.  Now I'm back 
to "F".

> > I'm using the latest list suggested by MozillaWiki:
> > ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-
> AE
> > S256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-
> SHA25
> > 6:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-
> SHA256:ECDHE-
> > ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-
> SHA:ECDHE-
> > RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-
> SHA:ECDHE
> > -ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-
> AES
> > 128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-
> SHA
> > :AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-
> RC4
> > -SHA:AES128:AES256:RC4-
> SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:
> > !PSK
> >
> >  However, when I run the test tool, it reports that the server is
> only
> > supporting the following list:
> > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> > TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256
> > TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA
> > TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA
> > TLS_RSA_WITH_RC4_128_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
> > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
> > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> >
> > Notice, none of the ECDHE-based ciphers are showing up in the list.
> > This is apparently what is keeping me from getting that perfect
> > score, as IE wants those ciphers for Forward Security.   It ends up
> > taking one of the lower ciphers on the list. Does anyone know, is
> > there a setting that needs to be made to enable those ciphers?
> > Were they turned off in the dev stage?  Is it related to my
> > certificate? Running the openssl.exe that comes with the APR binary
> > download shows the ECDHE ciphers in the list. Any help appreciated.
> 
> Did you set-up the Elliptic-curve parameters? If not, you can't use
> those ciphers.
> 

Per someone (Mladen?) the capability wasn't enabled at build.
Last notice I received is he's addressing that in the next release.
Jeff

RE: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

2014-04-09 Thread Jeffrey Janner 
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, April 09, 2014 12:25 AM
> To: Tomcat Users List
> Subject: Re: Does the HeartBleed vulnerability affect Apache Tomcat
> servers using Tomcat Native?
> 
> 
> Arlo,
> 
> On 4/8/14, 5:36 PM, Arlo White wrote:
> > After updating OpenSSL I simply restarted Tomcat to eliminate the
> > vulnerability.
> 
> - -1
> 
> You must re-key your server, and get a new cert from your CA. You have
> stopped the bleeding but your key should still be considered
> compromised.
> 
> > (Checked http://filippo.io/Heartbleed before and after) I built APR
> > and Tomcat Native from source on the server, so I assume it's doing
> > dynamic library loading.
> >
> > Is the binary build staticly linked? Otherwise, I'm not sure it's
> > necessary to redo the builds.
> 
> The ASF only provides binaries for win32, and yes, they are statically-
> linked. Users without the expertise to build their own tcnative binary
> will have to wait for the tcnative team to roll a new release.
> 
> - -chris
Just to clarify what Chris is saying, ASF provides statically-linked binaries 
for Windows in zip files with the string "win32" in the name.  The zip file 
actually contains versions for both x86 and x64 versions of Windows.
And yes, some of us don't have the expertise and/or tools to build the library 
ourselves under Windows.
Jeff

Re: [OT] HeartBleed bug

2014-04-09 Thread Ognjen Blagojevic 

Chris,

On 9.4.2014 14:53, Christopher Schultz wrote:

My recommendation would be to treat everything OpenSSL touches as
tainted and re-key anyway.


[I will assume we are talking about OpenSSH implementation.]

That dependins of the definition of "what OpenSSL touches". OpenSSL 
consists of two libraries: libcrypto and libtls. OpenSSH implementation 
depends on OpenSSL package, but only to utilize primitive crypro 
functions from libcrypto library. Libtls library contains implementation 
of TLS protocol, including Heartbeat functionality, but OpenSSH does not 
utilize that library, AFAIK. Therefore, I stand by my earlier position 
-- no need to rekey SSH keys.


-Ognjen



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

Re: [OT] HeartBleed bug

2014-04-09 Thread Robert Klemme 
On Wed, Apr 9, 2014 at 2:53 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Ognjen,
>
> On 4/9/14, 3:30 AM, Ognjen Blagojevic wrote:
>> On 9.4.2014 9:49, André Warnier wrote:
>>> I wonder if I may ask this list-OT question to the SSH experts on
>>> the list :
>>>
>>> I run some 25 webservers (Apache httpd-only, Tomcat-only, or
>>> Apache httpd + Tomcat). I do not use HTTPS on any of them. But I
>>> use SSH (OpenSSH) to connect to them over the Internet for
>>> support purposes, with "authorized_keys" on the servers. Are my
>>> servers affected by this bug ? Or is this (mainly) an
>>> HTTPS-related affair ?
>>>
>>> I mean : I will update OpenSSH on all my servers anyway.  But do
>>> I have to consider that, with a non-negligible probability, the
>>> keys stored on my servers are already compromised ?
>>
>> This is OpenSSL 1.0.1--1.0.1f vulnerabilty, so any protocol using
>> OpenSSL implementation of TLS/SSL protocol (if OpenSSL libarary
>> version is in mentioned range) is vulnerable
>
> Not necessarily. SSH, for instance, does not utilize the "heartbeat"
> feature of SSL and so is theoretically safe. I suppose you could have
> used the same server key for both SSH and HTTPS, but that would have
> been pretty silly.

Isn't that exactly what Ognjen said? This quote of him was not
included in your email:

>> SSH protocol does not use TSL/SSL, so it is not vulnerable to Heartbleed bug.

> My recommendation would be to treat everything OpenSSL touches as
> tainted and re-key anyway.

That may be a costly recommendation because one might buy more new and
revoke more old certificates than necessary.

Cheers

robert


-- 
[guy, jim].each {|him| remember.him do |as, often| as.you_can - without end}
http://blog.rubybestpractices.com/

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

Re: [OT] HeartBleed bug

2014-04-09 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ognjen,

On 4/9/14, 3:30 AM, Ognjen Blagojevic wrote:
> On 9.4.2014 9:49, André Warnier wrote:
>> I wonder if I may ask this list-OT question to the SSH experts on
>> the list :
>> 
>> I run some 25 webservers (Apache httpd-only, Tomcat-only, or
>> Apache httpd + Tomcat). I do not use HTTPS on any of them. But I
>> use SSH (OpenSSH) to connect to them over the Internet for
>> support purposes, with "authorized_keys" on the servers. Are my
>> servers affected by this bug ? Or is this (mainly) an
>> HTTPS-related affair ?
>> 
>> I mean : I will update OpenSSH on all my servers anyway.  But do
>> I have to consider that, with a non-negligible probability, the
>> keys stored on my servers are already compromised ?
> 
> This is OpenSSL 1.0.1--1.0.1f vulnerabilty, so any protocol using 
> OpenSSL implementation of TLS/SSL protocol (if OpenSSL libarary
> version is in mentioned range) is vulnerable

Not necessarily. SSH, for instance, does not utilize the "heartbeat"
feature of SSL and so is theoretically safe. I suppose you could have
used the same server key for both SSH and HTTPS, but that would have
been pretty silly.

My recommendation would be to treat everything OpenSSL touches as
tainted and re-key anyway.

Here are some guides for re-keying your openssh servers:

Debian: https://wiki.debian.org/SSLkeys#OpenSSH_.28Server.29
Generic: http://www.softec.lu/site/DevelopersCorner/HowToRegenerateNewSsh

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

iQIcBAEBCAAGBQJTRULAAAoJEBzwKT+lPKRYwwYP/0HrBqKK14wZ9lbLLP8mPzS7
VW3DFmuUbEYtLaRsSiCoAm2Db4ip8GuDLF7QuHRcaPIjejf56vjtOHxzDuPTHs88
d9Wdl045XABbp9esp/yt0PERc3IpFp0aF5HIZ9PUYhq+wEedz29nuQDMgBq2tnhW
EhtTe5IbtvB/e0JCVHfmfrNZ28u3AqD9ymM8F2R3DlvkfEIK+H+iG+jXoYGGoalq
scuYEDcPKQfW1raA6S+Y3+88NGnOfZ9HY8nQexRXN02rU+MzxMUesArdsH6WLrVE
BD7/chXld2Wrtfk2pGpqx326NG2Or8knhsnYDx1N+uH1wi8Z+QTdUuhUUN6+yazh
vYazcYnHxFYMj8TGrEPETa+FbNuok/z1C78ZqfehOfAZ1hxoATq9d8T7vE6C2rCQ
ONc8962Umu1jtNKrtWZUly1G4Bb4SJvRxxTfZif4A6mxipxSUJXBo6DIBdn1ETJB
nogCE+YxXXb9DtmjQRGhuu4vuyA/DoNlEPmkjDjGDiBPcloxGIdsinz9zx1Rk7S0
9Z82sNpsZDztFe/Z1/VZ8jrnhaKHO03saR33XdWthBHna0nOiJ1TBhGFeuPE82kK
Esz79QArjv9237Xf/MMatO1jXA85cqqzILy43hD/jo4dxT+8c0aE/X7nq5ekfUEF
9CfbNtwi/7eQPrjsnZg6
=rb8D
-END PGP SIGNATURE-

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

Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

2014-04-09 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arlo,

On 4/8/14, 4:36 PM, Arlo White wrote:
> What would the Tomcat code change be?

No code changes, even at the tcnative level. It just requires a
re-link (remember, it's statically-linked on win32) with a safe
OpenSSL build.

> I suppose it'd be nice if Tomcat refused to boot and logged an
> ERROR with a vulnerable SSL version? Is that what you were
> thinking?

While this sounds like a good idea in theory, it can fail in practice.
For example, I have an updated Debian 7 system:

$ openssl version
OpenSSL 1.0.1e 11 Feb 2013

But when I run http://filippo.io/Heartbleed against it, it says that I
am protected. That's likely due to a recent Debian-only patch against
1.0.1e: http://www.debian.org/security/2014/dsa-2896

So this means that Debian's OpenSSL version, which will report 1.0.1e,
is safe, so rejecting it based upon version number is not appropriate.

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

iQIcBAEBCAAGBQJTRUBQAAoJEBzwKT+lPKRYh+IQAI/uUZ6STud7vt6U2pCsMU3Q
K6PjZp04gXi36qYlyzGeXUf1W1v4Hkc5lNRQDohT4PnOShkdAC+QLVOyHu0pjfpO
mn9feM6WJVw9ayP0dUo3YJpSXwYz9yic02iT4qrl94b3dv7M6QFwqXe5//ZLXAAU
QxzUHEZzYf4rjdWLu0y0BwNkdGoMw+UuWmo3gWBl1AzbRsT9MnREGgkgv9PXhklO
kIG2dx6WsygFXKAnEHwMTLlNZV/kbIDTcqzjY/en3Z2grDJ1+mIjP9tQJ2LbJ3II
r+wabNpMOc9FMBpN9kgEnv4MoZgOukbsjf6f1CTrNQrAhYHC90cKcFgx7TChIkUY
253d8yLSf8CkaKzr7G813EqCpRqSKDGv8RB/NEc1U0B/ayrVMXTzhBu1ZU4BZXLq
Mv/gHqY9NgvRjxP1hyU+eMGHQHxlumHbytbSdf/eGigM50Tt1ZUrdMqX2jbc31xt
6vDlx0szpZgqoVutRPngqoYhiSAW6q04rk0SUH3HnQQn1sMg08N2eGac6oPUm4dX
wdeq51TPO1Zoh1G+DuLbxj035qSK9QwLRjiC+zZhZUsuIP1I2432CK2xxAIh41ub
iC899Axdg6NQPRQ6O3MUlHIHBGuYLIZGSRTzVjWwg+iwIIRyY3mmyDZq9DoeoPbU
kNBMK5esM8E05B4zuxdi
=QgTY
-END PGP SIGNATURE-

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

Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

2014-04-09 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ognjen,

On 4/9/14, 3:16 AM, Ognjen Blagojevic wrote:
> Chris,
> 
> On 9.4.2014 7:22, Christopher Schultz wrote:
>> - -1
>> 
>> Switching to JSSE only stops the hemorrhaging. You should 
>> consider all your server keys compromised if OpenSSL 1.0.1 was 
>> used (prior to "g" patch level). If you switch to JSSE, your key 
>> may already have been compromised, so the switch does not
>> protect you.
>> 
>> If you were lucky enough to have been ignored by Internet 
>> miscreants, then switching will protect you, but it's a bad bet. 
>> The better bet is to upgrade ASAP to a 1.0.1g version of OpenSSL 
>> and then re-key everything.
>> 
>> Then change all your passwords. :(
> 
> I agree. What I was supposed to say is: After you revoke 
> certificates, and reissue a new one, you may switch to JSSE 
> connector, and then, wait for patched version of tcnative dll. 
> Thank you for pointing that out.

Yup. Technically, it should only require a re-link, since none of the
tcnative code should actually need a change. However, it's probably
best to bump the version number to avoid too much confusion.

Mladen is working on it right now. We'll see what action he chooses to
take. I hope he builds a new version from current 1.1 branch, 'cause I
want some new features available ;)

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

iQIcBAEBCAAGBQJTRTyiAAoJEBzwKT+lPKRYLooP/i9oosXJyTyrzsDVpK0CZgnF
RX6DwYkpxUzrli/Z0qcy1Foj1N1NxDtHGi+gx7VadiM22+W9HQcd2yG4FddiJEXJ
uDq3SE/zWM5Wfr+TAbzyISP3DtbLGaqf1wi9f79pH5eSH1C1H7Kd+aeYk+6Ac3Ek
FKt6hQWr9RBqSnzJavGHOPKa/9zcoQeYF+XwB583lejeZbcyDI4gYS2Yur/Uu+Yl
wKXMLSt5pDkeqXkMtF6ZOUYr5DCX+Bg7ZpjPQIsfW9j0OLMRjynql6RNE55Ebxst
P/K8LCv55h8fiB6nXP5/jqH59KPROs6gT9flwZwZ2wc5y27HLTZkswWrg4PLPpso
htIGQPlto/RBLzwRFNcd4tg5L5QTuZbDx1T73fLHgaN393ymxtDzmuSx96/S+oLa
GGK7+sxAndfseQX25CW9hqFhkFXip30clKXIgl7ZA3EWax193Jt8pf61Rc3HsMJQ
AvPZ637CxuKPIPnVqYatefzertdJLbJ9X454veUScn1okT1dwhundESwmkBDiXw8
ujuIffz1MrI/jVXUYJ4hsHtN2eSulN7arJnuQ3uVd+lOyDdvRh7purctOwru/4ND
ZlPjXE6bUAPOhDzY8WzM6zdHUKST2X1HDfOlElE/xJiHwqITzrZMqZKM/V9m7KqY
f7R71H/nVFZFAU/Y4lGt
=PMId
-END PGP SIGNATURE-

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

Re: [OT] HeartBleed bug

2014-04-09 Thread André Warnier 

Ognjen Blagojevic wrote:

André,

On 9.4.2014 9:49, André Warnier wrote:

I wonder if I may ask this list-OT question to the SSH experts on the
list :

I run some 25 webservers (Apache httpd-only, Tomcat-only, or Apache
httpd + Tomcat).
I do not use HTTPS on any of them.
But I use SSH (OpenSSH) to connect to them over the Internet for support
purposes, with "authorized_keys" on the servers.
Are my servers affected by this bug ?
Or is this (mainly) an HTTPS-related affair ?

I mean : I will update OpenSSH on all my servers anyway.  But do I have
to consider that, with a non-negligible probability, the keys stored on
my servers are already compromised ?


This is OpenSSL 1.0.1--1.0.1f vulnerabilty, so any protocol using 
OpenSSL implementation of TLS/SSL protocol (if OpenSSL libarary version 
is in mentioned range) is vulnerable, like: STARTTLS extension for 
protocols like SMTP, POP, IMAP, XMPP, FTP, LDAP, NNTP, and also other 
protocols which uss TLS/SSL like SSL VPN, and HTTPS.


SSH protocol does not use TSL/SSL, so it is not vulnerable to Heartbleed 
bug.


-Ognjen



Thanks for clarifying for this SSH/SSL near-dummy.

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

Re: Fwd: Unable to start tomcat as a service.

2014-04-09 Thread akshay jain 
Hey,

I just modified service.bat to set the JRE_HOME. It working really good
now.
Thanks for the help.

Akshay Jain

Re: [OT] HeartBleed bug

2014-04-09 Thread Ognjen Blagojevic 

André,

On 9.4.2014 9:49, André Warnier wrote:

I wonder if I may ask this list-OT question to the SSH experts on the
list :

I run some 25 webservers (Apache httpd-only, Tomcat-only, or Apache
httpd + Tomcat).
I do not use HTTPS on any of them.
But I use SSH (OpenSSH) to connect to them over the Internet for support
purposes, with "authorized_keys" on the servers.
Are my servers affected by this bug ?
Or is this (mainly) an HTTPS-related affair ?

I mean : I will update OpenSSH on all my servers anyway.  But do I have
to consider that, with a non-negligible probability, the keys stored on
my servers are already compromised ?


This is OpenSSL 1.0.1--1.0.1f vulnerabilty, so any protocol using 
OpenSSL implementation of TLS/SSL protocol (if OpenSSL libarary version 
is in mentioned range) is vulnerable, like: STARTTLS extension for 
protocols like SMTP, POP, IMAP, XMPP, FTP, LDAP, NNTP, and also other 
protocols which uss TLS/SSL like SSL VPN, and HTTPS.


SSH protocol does not use TSL/SSL, so it is not vulnerable to Heartbleed 
bug.


-Ognjen


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

tomcat 6.0.32 with myfaces 1.2.2

2014-04-09 Thread Dariusz Wawer 
I have been using tomcat 6.0.18 with myfaces 1.2.2 and it works well. I 
now have to upgrade to tomcat 6.0.32 and the application fails to work.
The error is strange - there is no exception, no problem visible in 
logs, seems like the data from input fields is just not submitted. It is 
probably connected to the fact that the faces value is inside the field, 
as shown in attached screenshot.


I've searched the Internet for solutions, but I can't seem to find any. 
There are lots of libraries used, including myfaces, spring and 
hibernate. It's difficult to pinpoint which one is the source of the 
problem, though I suspect it's myfaces.


Any thoughts, ideas?

Java used: 6u32
Libs in app:
activation-1.1.jar   commons-lang-2.1.jar  oro-2.0.8.jar
antlr-2.7.6.jar  commons-logging-1.1.1.jar 
postgresql-8.3-603.jdbc4.jar

aopalliance-1.0.jar  commons-logging-api-1.1.jar   quartz-1.6.1.jar
asm-1.5.3.jarcommons-validator-1.3.0.jar saxpath-1.0-FCS.jar
asm-attrs-1.5.3.jar  dom4j-1.6.1.jar   spring-2.5.6.jar
bcmail-jdk14-138.jar ehcache-1.2.3.jar spring-beans-2.5.6.jar
bcprov-jdk14-138.jar hibernate-3.2.6.ga.jar spring-context-2.5.6.jar
cc-jstd-core-1.0.24.jar  icu4j-2.6.1.jar spring-core-2.5.6.jar
cc-jstd-log-1.0.02.jar   itext-2.1.4.jar spring-orm-2.5.6.jar
cc-jstd-mail-2.0.00.jar  jacc-1.0.jar spring-tx-2.5.6.jar
cc-jstd-web-0.0.3.jarjaxen-1.1.1.jar spring-web-2.5.6.jar
cglib-2.1_3.jar  jdom-1.0.jar tomahawk-1.1.6.jar
commons-beanutils-1.7.0.jar  jstl-1.2.jar  velocity-1.5.jar
commons-codec-1.3.jarjta-1.0.1B.jarxalan-2.6.0.jar
commons-collections-3.2.jar  jxl-2.6.12.jar xercesImpl-2.6.2.jar
commons-digester-1.8.jar mail-1.4.jar xml-apis-1.3.02.jar
commons-discovery-0.4.jarmyfaces-api-1.2.2.jar xmlParserAPIs-2.6.2.jar
commons-el-1.0.jar   myfaces-extensions-1.0.9.jar  xom-1.0.jar
commons-fileupload-1.0.jar   myfaces-impl-1.2.2.jar

Pozdrawiam,
Dariusz Wawer

--
+--- http://www.cc.com.pl/ --- +
       CC Otwarte Systemy Komputerowe Sp. z o.o. - |
  CCC  CCC   - CheckPoint, Juniper, SafeNet, Vasco Partner |
  CC   CC  - Internet, Intranet, WWW, Bezpieczne sieci |
  CCC  CCC   - TEL,FAX (+48) 22 646-68-73, 606-37-80 - |
       - Rakowiecka 36, Warszawa, 02-532 PL -- |
+--+
Spółka zarejestrowana w Wydz.XIII Gospodarczym Krajowego  Rejestru |
Sądowego, nr KRS 023570, zarząd: Grzegorz Blinowski  -  Prezes |
Zarządu, Tomasz Ramsza - Członek Zarządu; Kapitał zakł.:10 PLN |
+- +


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

Re: Does the HeartBleed vulnerability affect Apache Tomcat servers using Tomcat Native?

2014-04-09 Thread Ognjen Blagojevic 

Chris,

On 9.4.2014 7:22, Christopher Schultz wrote:

- -1

Switching to JSSE only stops the hemorrhaging. You should consider all
your server keys compromised if OpenSSL 1.0.1 was used (prior to "g"
patch level). If you switch to JSSE, your key may already have been
compromised, so the switch does not protect you.

If you were lucky enough to have been ignored by Internet miscreants,
then switching will protect you, but it's a bad bet. The better bet is
to upgrade ASAP to a 1.0.1g version of OpenSSL and then re-key everything.

Then change all your passwords. :(


I agree. What I was supposed to say is: After you revoke certificates, 
and reissue a new one, you may switch to JSSE connector, and then, wait 
for patched version of tcnative dll. Thank you for pointing that out.


-Ognjen

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

[OT] HeartBleed bug

2014-04-09 Thread André Warnier 

I wonder if I may ask this list-OT question to the SSH experts on the list :

I run some 25 webservers (Apache httpd-only, Tomcat-only, or Apache httpd + 
Tomcat).
I do not use HTTPS on any of them.
But I use SSH (OpenSSH) to connect to them over the Internet for support purposes, with 
"authorized_keys" on the servers.

Are my servers affected by this bug ?
Or is this (mainly) an HTTPS-related affair ?

I mean : I will update OpenSSH on all my servers anyway.  But do I have to consider that, 
with a non-negligible probability, the keys stored on my servers are already compromised ?


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