RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

>> Hi Tomcat Users,
>>
>> I am having a difficult time trying to enable SSLv3 in Tomcat 8.5.15.  (A 
>> 3rd-party component of our product requires SSLv3 and there's no getting 
>> around it!)  Our Tomcat is running on a custom Linux distribution based on 
>> Centos 7, and we're running Java 1.8.0_131.  Note that I've already (and 
>> correctly) enabled SSLv3 support in the JVM and verified that SSLv3 is 
>> correctly enabled when running our existing Tomcat 7.0.47.  My guess is that 
>> I have an incorrect server.xml configuration (for Tomcat 8), but the Tomcat 
>> documentation 
>> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support) as I 
>> read it, seems to say that simply setting the "protocols" attribute of the 
>> SSLHostConfig element to include "SSLv3" should do the job.
>>
>> Thank you in advance for any help offered!
> 
> 8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.
> 
> The docs need to be updated to reflect that. Also the migration guide.
> 
> I've done some svn archaeology and this change was introduced during 
> the refactoring that added support for SNI, ALPN and multiple certificates.
> Originally, the removal of SSLv2 and SSLv3 was only for the default 
> protocols (as it currently is in 8.0.x and earlier). During the 
> refactoring, the filtering effectively switched to applying to the 
> supported protocols.
> 
> A warning is logged during start-up that an unsupported protocol has 
> been requested.
> 
> Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the JVM 
> used also supports it.
> 
> Given the inherent insecurities in SSLv3, I don't like the message 
> re-enabling sends. On the other hand, it drives me mad when software 
> blocks something because it thinks it knows best rather then letting 
> me judge the risk and make the decision for myself.
> 
> I'm therefore leaning towards allowing SSLv3 to be requested but 
> logging a clear warning if it is.
> 
> Mark
> --
> 
> Thank you Mark for clarifying that SSLv3 is *not* supported (at all) 
> in Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat docs), 
> I could have saved days of research and experimentation. :-(

SSLv3 will be available (not by default and using it will result in a warning 
in the logs) from 9.0.0.M23 and 8.5.17 onwards (i.e. not the releases currently 
in progress but the next ones in around a month's time).

Mark

That is great news, thank you Mark!

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

Re: Problem enabling SSLv3 in Tomcat 8.5.15

[Mark Thomas]

On 21/06/17 19:04, Marc Dorsa wrote:
>> Hi Tomcat Users,
>>
>> I am having a difficult time trying to enable SSLv3 in Tomcat 8.5.15.  (A 
>> 3rd-party component of our product requires SSLv3 and there's no getting 
>> around it!)  Our Tomcat is running on a custom Linux distribution based on 
>> Centos 7, and we're running Java 1.8.0_131.  Note that I've already (and 
>> correctly) enabled SSLv3 support in the JVM and verified that SSLv3 is 
>> correctly enabled when running our existing Tomcat 7.0.47.  My guess is that 
>> I have an incorrect server.xml configuration (for Tomcat 8), but the Tomcat 
>> documentation 
>> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support) as I 
>> read it, seems to say that simply setting the "protocols" attribute of the 
>> SSLHostConfig element to include "SSLv3" should do the job.
>>
>> Thank you in advance for any help offered!
> 
> 8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.
> 
> The docs need to be updated to reflect that. Also the migration guide.
> 
> I've done some svn archaeology and this change was introduced during the
> refactoring that added support for SNI, ALPN and multiple certificates.
> Originally, the removal of SSLv2 and SSLv3 was only for the default
> protocols (as it currently is in 8.0.x and earlier). During the
> refactoring, the filtering effectively switched to applying to the
> supported protocols.
> 
> A warning is logged during start-up that an unsupported protocol has
> been requested.
> 
> Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the JVM
> used also supports it.
> 
> Given the inherent insecurities in SSLv3, I don't like the message
> re-enabling sends. On the other hand, it drives me mad when software
> blocks something because it thinks it knows best rather then letting me
> judge the risk and make the decision for myself.
> 
> I'm therefore leaning towards allowing SSLv3 to be requested but logging
> a clear warning if it is.
> 
> Mark
> --
> 
> Thank you Mark for clarifying that SSLv3 is *not* supported (at all) in 
> Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat docs), I could 
> have saved days of research and experimentation. :-(

SSLv3 will be available (not by default and using it will result in a
warning in the logs) from 9.0.0.M23 and 8.5.17 onwards (i.e. not the
releases currently in progress but the next ones in around a month's time).

Mark

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

Re: Tomcat 8.5.15 Client Authentication Trust Store Changes

[Racine Faye]

Thanks for the reply Christopher. The way tomcat has always worked in
the past(Before 8.5.15) , is that your trust store is what tomcat uses
to decide what certificates the browser should show to the user
because it only shows them certificates that are in the certificate
chain of whatever you import into your trust store. So if you import a
root certificate it will show everything that has that root
certificate in its chain but if you import in an intermediate it will
only show the certificates that the intermediate accepts. So the way
it works for DoD is that on each CAC there are 2 client authentication
certificates one Email Cert and one ID cert. They contain different
information mainly the email address is only contained in the Email
cert. When users are prompted to select a certificate they are only
supposed to be given the selection of what certificates are in the
trust store because it knows that anything not in that trust store
won't be accepted anyways. When you set the clientAuth to true in the
connector that is what makes it so Tomcat then asks for a certificate
from the user for validation. I have used both IE and Chrome and I get
the same results in both. I am pretty sure it is not a browser issue
though because I have both Tomcat 8.5.15 and 8.5.14 running on the
same server using the same trust store and 8.5.14 asks for only
Certificates that are in the Chain of the Intermediates that I
imported in and 8.5.15 asks for all of the certificates. Unfortunately
I am not able to run openssl as I am on a goverment network and the
software we can use is restricted.
https://stackoverflow.com/questions/1666052/java-https-client-certificate-authentication
The previous link  has a pretty good explanation of the way Tomcat has
always worked in the past in the comments and explains about the
behavior I am expecting.

On Wed, Jun 21, 2017 at 1:16 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Racine,
>
> On 6/21/17 12:38 PM, Racine Faye wrote:
>> I have noticed that in Tomcat 8.5.15 on the Windows Server 2008
>> Operating System that the way that tomcat presents user
>> certificates has changed. I have a trust store that I use on the
>> tomcat 8.5.14 version that has only DoD intermediate Email
>> certificates which makes it so when users go to the site they are
>> prompted for only their email cert.
>>
>> When upgrading to 8.5.15 I used the same trust store and it now
>> prompts for all certificates on the computer.
>
> What prompts for all certificates on the computer?
>
>> I am not sure if that is intended behavior or an oversight but it
>> is kind of confusing to users to be presented certificates that
>> they can't use.
> I don't believe Tomcat is presenting any certificates to the user, is
> it? It's the browser that is showing the certificate selection to the
> user. What browser are you using?
>
>> Another reason for having them only select the email cert is that
>> only the email certificate contains the information that we need
>> to get their user ID.
> This is informative, but not really relevant. Theoretically, the user
> can provide any certificate that has been signed by a certificate in
> the trust store. So if the user decides to provide a signed
> certificate that does *not* have the email address in it, then your
> application needs to be the one signalling an error.
>
>> I want to see if anyone else is having this issue or if anyone has
>> noticed that when specifying a trust store in Tomcat 8.5.15 that it
>> will present the user with all the certificates they have rather
>> than only the ones that the trust store will accept.
>
>> To rule out an issue with my server xml I have installed both
>> 8.5.15 and 8.5.14 on the server and used the exact same server.xml
>> file and I see that the 8.5.14 version will ask the user for only 1
>> cert and that the 8.5.15 version will ask the user for all certs.
>> If anyone has a fix for this or might know what is going on or if
>> there is an extra configuration needed that would be helpful.
>
> Are you using the same web browser with both Tomcat versions? What
> browser(s) are you using? Versions? What OS?
>
> Are you able to run openssl s_client against your Tomcat server? That
> can tell you what the server is providing as part of the TLS
> handshake... you may be able to tell the difference between what certs
> are being sent back with the handshake.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKxfIACgkQHPApP6U8
> pFhKFw//S1RAkI/aB2dJ0jhRM3VuzNBXOW3cvO+LdB0cUA+B2az9VKskPrRSgAPx
> Pu4uIcadJrda7PlLHEP/W5MxQRrBBPONybyIM/AUOx3t0halXRXAb+IUKPnZ0IH8
> /cS4vcI4C55mUh393hxVTcNPHh8egHvd1cJSm3nWwx+ZJwmfnjiLlssoMdgs3Lla
> 3NvAqVajCrVksgygkXr23qkcfH1utNxXZnTAxRXF4PmLgFk46M3Jnu6cJVhFNO3s
> 

RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

Marc,

On 6/21/17 3:30 PM, Marc Dorsa wrote:
> Marc,
> 
> On 6/21/17 2:04 PM, Marc Dorsa wrote:
>> Thank you Mark for clarifying that SSLv3 is *not* supported (at
>> all) in Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat 
>> docs), I could have saved days of research and experimentation. :-(
> http://lmgtfy.com/?q=how+to+enable+sslv3+in+tomcat
> 
> ?
> 
> - -chris -
> 
> Hi Chris,
> 
> Very funny :) , however, the articles out there on the Web re:
> this issue (stackoverflow, etc.), including the Tomcat 8.5 docs,
> all suggest fairly simple steps to enable SSLv3 in Tomcat (after
> first enabling it in the Java 8 JVM). I didn't see any information
> or comments stating that SSLv3 was permanently *disabled* starting
> with Tomcat 8.5 (as Mark Thomas just suggested).   If you believe
> what I just stated is not correct, please clue me in!

You're right, but, prior to 8.5 the release, the instructions were
straightforward. Having tried them and finding it not working, you
could have come directly to the users@ mailing list and asked your
question. As you see, we are fairly responsive around here :)

(I'll update my answer on SO to indicate that 8.5 and 9.0 are a little
different right now.)

- -chris

Yes indeed. :) 

Re: Problem enabling SSLv3 in Tomcat 8.5.15

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 6/21/17 3:30 PM, Marc Dorsa wrote:
> Marc,
> 
> On 6/21/17 2:04 PM, Marc Dorsa wrote:
>> Thank you Mark for clarifying that SSLv3 is *not* supported (at 
>> all) in Tomcat 8.5+.  Wow, if only I had known that (via the
>> Tomcat docs), I could have saved days of research and
>> experimentation. :-(
> http://lmgtfy.com/?q=how+to+enable+sslv3+in+tomcat
> 
> ?
> 
> - -chris -
> 
> Hi Chris,
> 
> Very funny :) , however, the articles out there on the Web re:
> this issue (stackoverflow, etc.), including the Tomcat 8.5 docs,
> all suggest fairly simple steps to enable SSLv3 in Tomcat (after
> first enabling it in the Java 8 JVM). I didn't see any information
> or comments stating that SSLv3 was permanently *disabled* starting
> with Tomcat 8.5 (as Mark Thomas just suggested).   If you believe
> what I just stated is not correct, please clue me in!

You're right, but, prior to 8.5 the release, the instructions were
straightforward. Having tried them and finding it not working, you
could have come directly to the users@ mailing list and asked your
question. As you see, we are fairly responsive around here :)

(I'll update my answer on SO to indicate that 8.5 and 9.0 are a little
different right now.)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKym8ACgkQHPApP6U8
pFiWYRAAjDZSqhFLWi2+eEFgMqzrC+WhK3CznlCtNbtkNiVq6ErxZFCb0MaMGhIl
PEoxpyG7XgG7Dd/VAXYzDO/c6uHq5eSm2rz4ToEkEVSbcgaWV1w1FBN8KV91Eocg
QXN1JEObEQ95Tkgh1Xq8cXe3fRFDdQ+F7qRD+zz7BgrrVhRU9RNrwDrgFWVIXpI5
OoimdN8FHWo6v+BlSTmEayiLslpr7SELy32nPvHwrqIiZbsQaWqtm9uI/6PJ2mFl
vUx0LaEiT2humPLOAUYF6WSeo/bKl6ARbKTKJbo5kWMDN9M76Thqx1/FR3t/AXUl
nPtbc0DlzxAVBJ7PboouCjm32f9OFyR670Psk21aE2JP5VLxy9+4kPAr8FxS4YsR
O3s/ua9GY0B7vfJck0l6qxqygOCc81V5VUM8Vub4bj1HsWqRTbiencMwg0IHyFbm
65In0cn4Y4dvVPFiMEv/ZisCmSI1maalSuyCuql4efmcLUY7OlOEJC7F574ZLV1T
Bsa1msLdRT2RDcLCr7dxGORc+CslUYqrORtz80IlaYX0EiHn0ftrxPDNtbmyzhct
B8HkMxLopFGnoPua7wbuLKY8PNv/a9jfPrSaYzrb2PewP2kntOrDZDdI4JHDfAel
TPigpC5gzk08tgQmSZYqDfO8GVGqt1dV/5DOr3so08ESB/n/kbs=
=7uzS
-END PGP SIGNATURE-

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

Re: Database Session Manager

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lance,

On 6/21/17 11:09 AM, Campbell, Lance wrote:
> Tomcat 8, 8.5, or 9 Is there a session manager for Tomcat that does
> not keep sessions in memory at all but stores the session
> attributes in a database?

http://tomcat.apache.org/tomcat-8.0-doc/cluster-howto.html#Overview

http://tomcat.apache.org/tomcat-8.0-doc/config/manager.html
(search for "database")

> Example:  If I create a session for the first time then the
> session manager would create a session ID and write it to a
> database table. Now if you do setAttribute on the session it would
> then insert a row in the database based on the session ID and name
> of the attribute. It would not delay.  It would write it at that
> moment.  If you do a getAttribute it would then select the value
> from the database based on the session ID and name.  At no time is
> a session object kept in memory by the session manager.> I looked
> over the Tomcat JDBCStore. But it looks like it still maintains
> sessions in memory for a time before writing them. I would like an
> implementation that never keeps them in memory. Direct writing and
> direct reading when a session does a setAttribute or getAttribute.
I believe the JDBCStore doesn't prevent data from existing in memory.

> The other element is that if I have N number of tomcat instances 
> that run behind a load balancer any one of them can receive an 
> incoming request. There is no communication that has to occur
> between tomcat instances.
Using JDBCStore basically requires the use of Clustering, which does
in fact notify the other nodes in the cluster about new sessions being
created, etc.

It can't work any other way, because a node needs to know if a session
exists or not. If there is no data in the session, what is in the db?
If it's only session attributes, then there is no difference between
an empty session and an invalid session.

Clustering also generally batches the updates to the other cluster
members when the request is completed, so I expect JDBCStore does the
same thing.

> Is this even possible to do? My feeling is that the Manager might 
> have some fields that never do anything. I don't want to create 
> something that someone else has already done.

I don't believe there is a way to do what you are requesting with an
out-of-the-box Tomcat.

> If this is able to be done and it has not been developed before I 
> would be happy to do it if someone wants to give me some basic
> starting information on how to do this. I would be happy to share
> it with the community.

What would be great. I think you might want to look at the memcached
implementation(s) of a Tomcat Manager floating around on the
Internet... those will probably give you a good starting point. If you
want to share the code back to the Tomcat project, please take care to
obtain the proper permission and ensure that the original license of
anything you "borrow" is compatible with AL2.

I would be +1 on incorporating such a Manager into Tomcat, as long as
it was configurable enough to be useful to others (e.g. batch updates
at request-completion as opposed to immediate-write, customizable
serialization mechanism e.g. XML/JSON/Java Serialization).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKyb0ACgkQHPApP6U8
pFgQqw//WQpA2buIBWpJ10uLpNVs/Ic43Ll2d0+skWpqATrhJOavgIMs0ytTgV2u
IeQuGf1G9a298HicNEBlEVF7pLbzqF1MX4ixMFbFfjY0Q/kCc2sZT/XuqV3FbDaK
Nt1WRQ42pvgPNMOkabbwubq4jCkWaQIjRdbrBXkveYJObuCxN7gs4iLZff43rAjX
GwznapnpR1eKZzMTS4fiAoKQjQU9Gx9tRDVrOcRG4/62WBFrTh84D+HkVpISbIq+
Y/7rMndzkL6iMf+s0VB/J9MAE72EiT61xKD1QhG7dDvSBsiRAfNJqQbDhFBOICOG
/6BmkxMB5TXeAEvHmmaJeoDZwOScDAjv9KUrSAGSA0sMghfddIGlQgmbWLKkgXL6
v54Yh9oXZaraSuQyPBreDWwBWSW7Rbptnt53tryv3McjXrDq1DuGWFJejuHz7X57
J+LULa3JK6OaOoKr0tzx6U+IBc5GIQ/0ANzqJA7yCRHWjFFPf6yeSF4k+IRfGh67
CEYjC7u7jxRW9wsRrafHKgkFEVpVWsDr4JoqKlofYDeThdi6oz8+55uMoiirF21O
R1XKQs7EyNmU8xPYEH6+yw8oBsPAG6BJjmoMz1ybvxg82VCk/493jWyICgD19M6q
ldsmKuRcT4dO0E6HWeUerKHOp/gDT6s1GKlcYTUDw84vsy2oUys=
=vFLG
-END PGP SIGNATURE-

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

RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

Marc,

On 6/21/17 2:04 PM, Marc Dorsa wrote:
> Thank you Mark for clarifying that SSLv3 is *not* supported (at
> all) in Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat 
> docs), I could have saved days of research and experimentation.
> :-(
http://lmgtfy.com/?q=how+to+enable+sslv3+in+tomcat

?

- -chris
-

Hi Chris,

Very funny :) , however, the articles out there on the Web re: this issue 
(stackoverflow, etc.), including the Tomcat 8.5 docs, all suggest fairly simple 
steps to enable SSLv3 in Tomcat (after first enabling it in the Java 8 JVM). I 
didn't see any information or comments stating that SSLv3 was permanently 
*disabled* starting with Tomcat 8.5 (as Mark Thomas just suggested).   If you 
believe what I just stated is not correct, please clue me in!

Thanks,
Marc

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

Re: Problem enabling SSLv3 in Tomcat 8.5.15

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Marc,

On 6/21/17 2:04 PM, Marc Dorsa wrote:
> Thank you Mark for clarifying that SSLv3 is *not* supported (at
> all) in Tomcat 8.5+.  Wow, if only I had known that (via the Tomcat
> docs), I could have saved days of research and experimentation.
> :-(
http://lmgtfy.com/?q=how+to+enable+sslv3+in+tomcat

?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKxt0ACgkQHPApP6U8
pFhNDQ/+Pdih3SXZs00VWITRVuv0ur2qNmF3dZt0IivJZlN+iWteQ2+SjAvZGz/d
z6tFE1ne28RuA7LRZyqsnU96sA5w/Y8AZrEBADQWiYmg9UVJOJAowrJBb63T3PLC
C/j8Yf+65lUdxd1pNiC/WFTSKTRPvA8cAl5+5W+LBDmXujziNLByzHZlKuIJU3vx
GXlFGum5/O0SwZeSvd2pEkaDH+m62adHEwCcYoX/MwBUKOpQqj3XJh/4WjSNIzMX
+pt+wlvkb7VZAG9VSCHft2r6wVx2RaUhVYvKNzMdsRzTt8ASVbTx5TmyRgGegM7W
RUbFyVq2RCSPaUCDZBnvV6XIORPxgPsKaxD+rMGHujeqhowVSPmwqQUYF8Z5PN4C
r4m3g6z/fC4eflNnASRScQuBLAPWgHYJTuz54nNyaDhBV0NRvN1nOUG15ECyG/6o
mGfKjQS91F/839+VGflqQYvJK7IY+CFqpayrGJGX1jKdjE+o8fjnx6y5fdxQuT33
oxklT40hTx7rrRrjY2K897WKhhF8lgEhoQSkuxPuV8+ESFyy6kt3IEMpNBEq/ut5
y43BXkkTdHGvdGTMmnDdBfXybdET8M/f3wWKB+UCsDH4Moe9Imix3/+FEEFRglXr
HhwreIOZzRCVvTFZNKWB0CethD78ga0Z2RWmtC1mBa1AP29bIGg=
=M2zr
-END PGP SIGNATURE-

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

Re: Tomcat 8.5.15 Client Authentication Trust Store Changes

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Racine,

On 6/21/17 12:38 PM, Racine Faye wrote:
> I have noticed that in Tomcat 8.5.15 on the Windows Server 2008 
> Operating System that the way that tomcat presents user
> certificates has changed. I have a trust store that I use on the
> tomcat 8.5.14 version that has only DoD intermediate Email
> certificates which makes it so when users go to the site they are
> prompted for only their email cert.
> 
> When upgrading to 8.5.15 I used the same trust store and it now 
> prompts for all certificates on the computer.

What prompts for all certificates on the computer?

> I am not sure if that is intended behavior or an oversight but it
> is kind of confusing to users to be presented certificates that
> they can't use.
I don't believe Tomcat is presenting any certificates to the user, is
it? It's the browser that is showing the certificate selection to the
user. What browser are you using?

> Another reason for having them only select the email cert is that 
> only the email certificate contains the information that we need
> to get their user ID.
This is informative, but not really relevant. Theoretically, the user
can provide any certificate that has been signed by a certificate in
the trust store. So if the user decides to provide a signed
certificate that does *not* have the email address in it, then your
application needs to be the one signalling an error.

> I want to see if anyone else is having this issue or if anyone has
> noticed that when specifying a trust store in Tomcat 8.5.15 that it
> will present the user with all the certificates they have rather
> than only the ones that the trust store will accept.

> To rule out an issue with my server xml I have installed both
> 8.5.15 and 8.5.14 on the server and used the exact same server.xml
> file and I see that the 8.5.14 version will ask the user for only 1
> cert and that the 8.5.15 version will ask the user for all certs.
> If anyone has a fix for this or might know what is going on or if
> there is an extra configuration needed that would be helpful.

Are you using the same web browser with both Tomcat versions? What
browser(s) are you using? Versions? What OS?

Are you able to run openssl s_client against your Tomcat server? That
can tell you what the server is providing as part of the TLS
handshake... you may be able to tell the difference between what certs
are being sent back with the handshake.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKxfIACgkQHPApP6U8
pFhKFw//S1RAkI/aB2dJ0jhRM3VuzNBXOW3cvO+LdB0cUA+B2az9VKskPrRSgAPx
Pu4uIcadJrda7PlLHEP/W5MxQRrBBPONybyIM/AUOx3t0halXRXAb+IUKPnZ0IH8
/cS4vcI4C55mUh393hxVTcNPHh8egHvd1cJSm3nWwx+ZJwmfnjiLlssoMdgs3Lla
3NvAqVajCrVksgygkXr23qkcfH1utNxXZnTAxRXF4PmLgFk46M3Jnu6cJVhFNO3s
Bc1zI+XYJwsX9fICE4dkmmWJ/ZblWgjG5nh4bSSq3Ons6MJg1anUcy0p7GsNUvaU
8uPUQiz2Xz4t/qPA2kBfsZUYwm/besLDdSp+CYr9VweT6apAp0Kr6kJu79W40MfR
w4Qpo+8wEkLDjPL/VBBU9yEso4PCGkpFHFsCnfSPf/L+eltyCZkaQfaQK5OehUaa
px1suyhbYe9xbMdq1WD06CSQYTlDuc7XxuNVgr8Nd1q3nQvkLZJAB/jIkEUhZ174
GXw+Sqzp09YPSKleQuetPvsP1iqmqsikX40Asl70UdEmEvW55KUrzD+DzY68cGjn
dcq6hEKVlLZ+0X96k3UEU8yRN7rCOexvypK0lfX2U0jgB2nZld4F5c0dwvqPy+UZ
xnwJToijUlnCDh4t0+6WEggVizYEEuXZf04aI00WZeC96WfgJG8=
=4E5V
-END PGP SIGNATURE-

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

RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

> Hi Tomcat Users,
> 
> I am having a difficult time trying to enable SSLv3 in Tomcat 8.5.15.  (A 
> 3rd-party component of our product requires SSLv3 and there's no getting 
> around it!)  Our Tomcat is running on a custom Linux distribution based on 
> Centos 7, and we're running Java 1.8.0_131.  Note that I've already (and 
> correctly) enabled SSLv3 support in the JVM and verified that SSLv3 is 
> correctly enabled when running our existing Tomcat 7.0.47.  My guess is that 
> I have an incorrect server.xml configuration (for Tomcat 8), but the Tomcat 
> documentation 
> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support) as I 
> read it, seems to say that simply setting the "protocols" attribute of the 
> SSLHostConfig element to include "SSLv3" should do the job.
> 
> Thank you in advance for any help offered!

8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.

The docs need to be updated to reflect that. Also the migration guide.

I've done some svn archaeology and this change was introduced during the
refactoring that added support for SNI, ALPN and multiple certificates.
Originally, the removal of SSLv2 and SSLv3 was only for the default
protocols (as it currently is in 8.0.x and earlier). During the
refactoring, the filtering effectively switched to applying to the
supported protocols.

A warning is logged during start-up that an unsupported protocol has
been requested.

Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the JVM
used also supports it.

Given the inherent insecurities in SSLv3, I don't like the message
re-enabling sends. On the other hand, it drives me mad when software
blocks something because it thinks it knows best rather then letting me
judge the risk and make the decision for myself.

I'm therefore leaning towards allowing SSLv3 to be requested but logging
a clear warning if it is.

Mark
--

Thank you Mark for clarifying that SSLv3 is *not* supported (at all) in Tomcat 
8.5+.  Wow, if only I had known that (via the Tomcat docs), I could have saved 
days of research and experimentation. :-(

Marc

Re: TCP (out) connections from webapp gets terminated

[Yaniv Sagron]

On Wed, 21 Jun 2017 at 12:18 Mark Thomas  wrote:

> On 21/06/17 09:26, Yaniv Sagron wrote:
> > Hi,
> >
> > I have a strange issue with Tomcat 8.5 (and with earlier revisions as
> well).
> > I run a Jython interpreter that connects to an external debugger (using
> > PyDev if it matters to anyone) through a TCP connection.
> > running the code on a regular Jar or on Jetty works flawlessly (both when
> > the server is in localhost or on a different machine).
> > Unfortunately, with Tomcat the connection gets terminate after few
> > interactions, e.g. stepping Jython instructions or stepping into
> functions.
> > Tried it with both, embedded Tomcat in a jar and on a standalone Tomcat
> > with a war file deployed to it.
> > Did anyone ever encounter such an issue and can think of a solution or a
> > way to debug it?
>
> Tomcat plays no role in outgoing TCP connections or incoming connections
> to sockets it does not control.
>
> Is the connection initiated from the Jython interpreter to the debugger,
> or does the interpreter listen for a connection from the debugger?
>
> I don't think it is a port clash since it would not work at all in that
> case.
>
> I'd probably look at the network traffic in Wireshark to see if there
> are any clues around the time the connection is terminated.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Thanks for the reply Mark.

I did use Wireshark and it showed the tcp.fin line but it's hard to tell
what piece of code causes it, especially that it doesn't happen in the
exact same point of the recreation.
The jython interpreter is the client in this case and it initiates the
connection to the debug server. Through this connection it sends stack
data, current instruction, etc. And receives breakpoint info and
instructions from the server.
Strange that it only happens in Tomcat

Tomcat 8.5.15 Client Authentication Trust Store Changes

[Racine Faye]

I have noticed that in Tomcat 8.5.15 on the Windows Server 2008
Operating System that the way that tomcat presents user certificates
has changed. I have a trust store that I use on the tomcat 8.5.14
version that has only DoD intermediate Email certificates which makes
it so when users go to the site they are prompted for only their email
cert. When upgrading to 8.5.15 I used the same trust store and it now
prompts for all certificates on the computer. I am not sure if that is
intended behavior or an oversight but it is kind of confusing to users
to be presented certificates that they can't use. Another reason for
having them only select the email cert is that only the email
certificate contains the information that we need to get their user
ID. I want to see if anyone else is having this issue or if anyone has
noticed that when specifying a trust store in Tomcat 8.5.15 that it
will present the user with all the certificates they have rather than
only the ones that the trust store will accept. To rule out an issue
with my server xml I have installed both 8.5.15 and 8.5.14 on the
server and used the exact same server.xml file and I see that the
8.5.14 version will ask the user for only 1 cert and that the 8.5.15
version will ask the user for all certs. If anyone has a fix for this
or might know what is going on or if there is an extra configuration
needed that would be helpful.

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

Tomcat 8.5.15 Client Authentication Trust Store Changes

[Racine Faye]

I have noticed that in Tomcat 8.5.15 on the Windows Server 2008 Operating
System that the way that tomcat presents user certificates has changed. I
have a trust store that I use on the tomcat 8.5.14 version that has only
DoD intermediate Email certificates which makes it so when users go to the
site they are prompted for only their email cert. When upgrading to 8.5.15
I used the same trust store and it now prompts for all certificates on the
computer. I am not sure if that is intended behavior or an oversight but it
is kind of confusing to users to be presented certificates that they can't
use. Another reason for having them only select the email cert is that only
the email certificate contains the information that we need to get their
user ID. I want to see if anyone else is having this issue or if anyone has
noticed that when specifying a trust store in Tomcat 8.5.15 that it will
present the user with all the certificates they have rather than only the
ones that the trust store will accept. To rule out an issue with my server
xml I have installed both 8.5.15 and 8.5.14 on the server and used the
exact same server.xml file and I see that the 8.5.14 version will ask the
user for only 1 cert and that the 8.5.15 version will ask the user for all
certs. If anyone has a fix for this or might know what is going on or if
there is an extra configuration needed that would be helpful.

Database Session Manager

[Campbell, Lance]

Tomcat 8, 8.5, or 9
Is there a session manager for Tomcat that does not keep sessions in memory at 
all but stores the session attributes in a database?

Example:  If I create a session for the first time then the session manager 
would create a session ID and write it to a database table.  Now if you do 
setAttribute on the session it would then insert a row in the database based on 
the session ID and name of the attribute.  It would not delay.  It would write 
it at that moment.  If you do a getAttribute it would then select the value 
from the database based on the session ID and name.  At no time is a session 
object kept in memory by the session manager.

The other element is that if I have N number of tomcat instances that run 
behind a load balancer any one of them can receive an incoming request.  There 
is no communication that has to occur between tomcat instances.

I looked over the Tomcat JDBCStore.  But it looks like it still maintains 
sessions in memory for a time before writing them.  I would like an 
implementation that never keeps them in memory.  Direct writing and direct 
reading when a session does a setAttribute or getAttribute.

Is this even possible to do?  My feeling is that the Manager might have some 
fields that never do anything.  I don't want to create something that someone 
else has already done.

If this is able to be done and it has not been developed before I would be 
happy to do it if someone wants to give me some basic starting information on 
how to do this.  I would be happy to share it with the community.

Thanks,

Lance

Re: Problem enabling SSLv3 in Tomcat 8.5.15

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/21/17 5:04 AM, Mark Thomas wrote:
> On 21/06/17 00:34, Marc Dorsa wrote:
>> Hi Tomcat Users,
>> 
>> I am having a difficult time trying to enable SSLv3 in Tomcat
>> 8.5.15.  (A 3rd-party component of our product requires SSLv3 and
>> there's no getting around it!)  Our Tomcat is running on a custom
>> Linux distribution based on Centos 7, and we're running Java
>> 1.8.0_131.  Note that I've already (and correctly) enabled SSLv3
>> support in the JVM and verified that SSLv3 is correctly enabled
>> when running our existing Tomcat 7.0.47.  My guess is that I have
>> an incorrect server.xml configuration (for Tomcat 8), but the
>> Tomcat documentation
>> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Suppor
t)
>> as I read it, seems to say that simply setting the "protocols"
>> attribute of the SSLHostConfig element to include "SSLv3" should
>> do the job.
>> 
>> Thank you in advance for any help offered!
> 
> 8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.

It's maybe worth noting that no shipped version of Sun/Oracle Java has
ever implemented SSLv2, but I believe some 3rd-party libraries
have/can support parts of that standard... mostly for probing to see
if it's enabled.

Nobody should have been building OpenSSL with SSLv2 in it for ...
decades, now.

But specific code to always disable SSLv2 is a Good Thing.

> The docs need to be updated to reflect that. Also the migration
> guide.
> 
> I've done some svn archaeology and this change was introduced
> during the refactoring that added support for SNI, ALPN and
> multiple certificates. Originally, the removal of SSLv2 and SSLv3
> was only for the default protocols (as it currently is in 8.0.x and
> earlier). During the refactoring, the filtering effectively
> switched to applying to the supported protocols.
> 
> A warning is logged during start-up that an unsupported protocol
> has been requested.
> 
> Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the
> JVM used also supports it.
> 
> Given the inherent insecurities in SSLv3, I don't like the message 
> re-enabling sends. On the other hand, it drives me mad when
> software blocks something because it thinks it knows best rather
> then letting me judge the risk and make the decision for myself.
> 
> I'm therefore leaning towards allowing SSLv3 to be requested but
> logging a clear warning if it is.

+1

Re-enabling SSLv3 in with a current JVM requires a system property to
be set, anyway, so there are two barriers to re-enabling SSLv3 on a
current-setup. I think it's reasonable to allow people who are willing
to manually re-enable SSLv3 to go ahead and have their insecure
service. :/

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllKhWcACgkQHPApP6U8
pFjShw/+Pe5eQ0yqPaX73IswPAiqJX/zehFv8ZUBKjtxJCrzJeCjgJxOAIeP1nSS
v/BGrYY0mHFA3lVad7jI7SGdSN2bWwr4V+4rFadjtJBQ0JqBJBTGm9JJDTQmpwWW
/YeCvqDdwefxtM7eZM2AwrOBT1oWyFROB/dK9beHQ4MHtmlRovrOlLLpQZkNCdIX
svNdTWEHjtXo98YmJUwvvAS5xgrn4pWsaSXpSCBRIpGl5RuS8JTqLoUCTaTYKkGf
TXc9pF65vAjWRNyUuOV8H6JMyKZ2dCyzQl4SixPOwJ2urSiTFlWUcRjCHNU7PnXN
BfCNiyiYmSUZR+qOxu0np6V56je/4HcbBpt7zCd0cjpkxRehw7fnJBNw6I0iL+ei
3PhrubFzJNs5pL7Iue0G29CxZJgLIQIg88dXaqgknGLw8eTCG6mwpwL9jp0ZF1xZ
YyB8K42g5K+VYCb3Eg83eKplmp6F3F/7PQhwMlJn1jUcd+lVZozSIScBOmhyDu8+
pji1Lbc2y8QqqQRmn/V87naqSHdsE/l4+hFYiN6Z015QdiExzRntf33KUxVhoOqB
H+ddK1HoaGF4n1iSXe0AaibwVUCHZGOz/Q6Cbv/+Wean9ZD13o1CXpdKR+2oFxsz
oWQuU0wQKR1q3rCltoO314l0fmH8VcEilI0Wr7zyZ2DJ5HSlPEs=
=kCAy
-END PGP SIGNATURE-

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

Re: How to stop Tomcat if servlet fails to initialize

[Mark Thomas]

On 21/06/17 13:33, Pesonen, Harri wrote:
> Hello, if one servlet fails to initialize, meaning that 
> ServletContextListener.contextInitialized() throws exception, then Tomcat 
> still starts (but without the servlet). 

If ServletContextListener.contextInitialized(), the web application will
not start.

Servlets are not initialised until first used so they can't prevent an
application from starting. The one exception is Servlets configured for
"load on startup". Any failure of these servlets will cause the
application to fail to start.

> I found out that if servlet calls System.exit(1), then Tomcat dies. Is this 
> the only way to make this happen?
> This does not work:
> -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true

You can try setting the (completely undocumented) throwOnFailure
attribute for the Context, Host, Engine, Service and Server.

The Context you can set in conf/context.xml so it applies to all web
applications.

Mark

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

How to stop Tomcat if servlet fails to initialize

[Pesonen, Harri]

Hello, if one servlet fails to initialize, meaning that 
ServletContextListener.contextInitialized() throws exception, then Tomcat still 
starts (but without the servlet). 
I found out that if servlet calls System.exit(1), then Tomcat dies. Is this the 
only way to make this happen?
This does not work:
-Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=true

-Harri

Re: TCP (out) connections from webapp gets terminated

[Mark Thomas]

On 21/06/17 09:26, Yaniv Sagron wrote:
> Hi,
> 
> I have a strange issue with Tomcat 8.5 (and with earlier revisions as well).
> I run a Jython interpreter that connects to an external debugger (using
> PyDev if it matters to anyone) through a TCP connection.
> running the code on a regular Jar or on Jetty works flawlessly (both when
> the server is in localhost or on a different machine).
> Unfortunately, with Tomcat the connection gets terminate after few
> interactions, e.g. stepping Jython instructions or stepping into functions.
> Tried it with both, embedded Tomcat in a jar and on a standalone Tomcat
> with a war file deployed to it.
> Did anyone ever encounter such an issue and can think of a solution or a
> way to debug it?

Tomcat plays no role in outgoing TCP connections or incoming connections
to sockets it does not control.

Is the connection initiated from the Jython interpreter to the debugger,
or does the interpreter listen for a connection from the debugger?

I don't think it is a port clash since it would not work at all in that
case.

I'd probably look at the network traffic in Wireshark to see if there
are any clues around the time the connection is terminated.

Mark

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

Re: Problem enabling SSLv3 in Tomcat 8.5.15

[Mark Thomas]

On 21/06/17 00:34, Marc Dorsa wrote:
> Hi Tomcat Users,
> 
> I am having a difficult time trying to enable SSLv3 in Tomcat 8.5.15.  (A 
> 3rd-party component of our product requires SSLv3 and there's no getting 
> around it!)  Our Tomcat is running on a custom Linux distribution based on 
> Centos 7, and we're running Java 1.8.0_131.  Note that I've already (and 
> correctly) enabled SSLv3 support in the JVM and verified that SSLv3 is 
> correctly enabled when running our existing Tomcat 7.0.47.  My guess is that 
> I have an incorrect server.xml configuration (for Tomcat 8), but the Tomcat 
> documentation 
> (https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support) as I 
> read it, seems to say that simply setting the "protocols" attribute of the 
> SSLHostConfig element to include "SSLv3" should do the job.
> 
> Thank you in advance for any help offered!

8.5.x and 9.0.x are hard-coded not to allow SSLv2 or SSLv3.

The docs need to be updated to reflect that. Also the migration guide.

I've done some svn archaeology and this change was introduced during the
refactoring that added support for SNI, ALPN and multiple certificates.
Originally, the removal of SSLv2 and SSLv3 was only for the default
protocols (as it currently is in 8.0.x and earlier). During the
refactoring, the filtering effectively switched to applying to the
supported protocols.

A warning is logged during start-up that an unsupported protocol has
been requested.

Tomcat 8.0.x and 7.0.x will continue to support SSLv3 assuming the JVM
used also supports it.

Given the inherent insecurities in SSLv3, I don't like the message
re-enabling sends. On the other hand, it drives me mad when software
blocks something because it thinks it knows best rather then letting me
judge the risk and make the decision for myself.

I'm therefore leaning towards allowing SSLv3 to be requested but logging
a clear warning if it is.

Mark

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

TCP (out) connections from webapp gets terminated

[Yaniv Sagron]

Hi,

I have a strange issue with Tomcat 8.5 (and with earlier revisions as well).
I run a Jython interpreter that connects to an external debugger (using
PyDev if it matters to anyone) through a TCP connection.
running the code on a regular Jar or on Jetty works flawlessly (both when
the server is in localhost or on a different machine).
Unfortunately, with Tomcat the connection gets terminate after few
interactions, e.g. stepping Jython instructions or stepping into functions.
Tried it with both, embedded Tomcat in a jar and on a standalone Tomcat
with a war file deployed to it.
Did anyone ever encounter such an issue and can think of a solution or a
way to debug it?

thanks,
Yaniv