Re: How to configure SPNEGO authentication with fallback to FORM auth?

[Terence M. Bandoian]

On 6/24/2016 10:45 AM, ken edward wrote:

On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas  wrote:


On 24/06/2016 16:17, ken edward wrote:

On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:


On 24 June 2016 14:22:32 BST, ken edward  wrote:

Hello,

I have tomcat 8 on linux, configured with kerberos/SPNEGO
authentication.
All works well, but if the client cannot use kerberos to authenticate,
it
will not fallback to FORM authentication.

I see some references that tomcat 8 does not do fallback negotiation
for
FORM auth. True?

Yes


Any workarounds?

Nothing simple. Both SPNEGO and FORM have their complications. You'll

need

to code some form of custom solution.

Have a look in the archives. This has come up before and I think there

is

some sample code that might get you most of the way there.




I had already searched the mail archives, and did not see any sample

code.

If anyone has any insight, please do post some code fragments.

I was thinking of this:
http://wiki.apache.org/tomcat/SSLWithFORMFallback

Not quite what you are looking for but it might help.



I guess I need to extend the SPNEGO valve code in tomcat 8 to handle
fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a simple
and essential use case. Perplexing that it is not implemented.




If you get it working, you might consider submitting a patch.  Doing so 
might save someone else from cursing under their breath.


-Terence Bandoian
http://www.tmbsw.com/


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

Re: Configuring Tomcat to support TLSv1.2

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 6/24/16 3:42 PM, Daniel Savard wrote:
> 2016-06-24 11:50 GMT-04:00 Joleen Barker
> :
> 
>> Hi Chris,
>> 
>> The SSL_VERSION parameter was already defined by the vendor.
>> 
>> 
> I still would delete the SSL_VERSION from the catalina.sh or
> comment it at least and adopt the suggested approach to configure
> everything in the server.xml file instead.

I believe the SSL_VERSION isn't affecting the configuration of the
server at all, but the application's client configuration (in its role
as a proxy).

> Without a specific definition of the SSL_VERSION, there will be no 
> constraints on the versions at this point. This SSL_VERSION 
> environment variable will bite you when you will need to upgrade 
> Tomcat to another version.
> 
> 
>> The web application we use allows users to connect to it via FTP,
>> FTPS, SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to
>> different back end servers. The web application is a proxy.
>> 
>> Without me making the change to the predefined SSL_VERSION
>> parameter that was originally configured as
>> "-Dhttps.protocols=TLSv1" to now be configured to 
>> "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for
>> correcting my typo) our remote party that uses and AS2 client
>> that is locked down to only using TLSv1.2 connection could now
>> connect to us successfully and upload a file. So with this change
>> I was able to accomplish the client to connect to the Tomcat
>> server. But I am unable to accomplish a successful connection 
>> when Tomcat is acting as the client to reach the remote AS2
>> server for us to send a file to them. It appears we are not
>> connecting to them using TLSv1.2 and therefore we are dropped. I
>> have a ticket open with the vendor on this but they don't seem to
>> be any help. I was trying to open the Java console on the UNIX
>> server but I am unable to as I do not have any X11 setup. I am
>> unable to find a command line option to set what is allowed in 
>> the Java application itself. On one of our test servers a
>> colleague could open the console and we saw that none of the TLS
>> options were NOT enabled and only SSLv3 was. I am not sure if
>> this is the case with this server that I am working on that we
>> have an outside connection open to be able to work with the
>> outside customer.  I am unsure if this change would allow us to 
>> reach them. I didn't know what the catalina.sh TLSv1.2 change
>> versus changing the Java application TLSv1.2 change is really
>> responsible for. (I know enough to brake stuff...lol) The vendor
>> is not much help. It's very frustrating so I reach out to this
>> community and get the help I need.
>> 
>> 
> The connection that isn't working is initiated by the web
> application on your Tomcat server as far as I understand. If so,
> then there is no configuration at the Tomcat level that will
> resolve this issue. You must look at the SSL debugging info to see
> what is going on in the negotiation with the remote party. To do
> that, use the -Djavax.net.debug=ssl option to the JVM and look at
> the log files (probably catalina.out) You should see the
> handshaking protocol negotiation.

+1

Or, if possible, have a look at the application's code to see how it's
configuring itself. Many components that give access to TLS don't
provide a way to configure it (grr) so it's possible that system
properties are the only way to go.

> Perhaps your application is not sending a valid certificate or no 
> certificate at all or something like that, which then has nothing
> to do with the inability to perform a full TLSv1.2 handshaking
> procedure. Is this connection worked previously using a less secure
> protocol?
> 
> 
>> Another interesting thing I found in my testing after the change
>> to the SSL_VERSION was in place was when I connected to the web
>> application using FTPS client using FileZilla in Debug mode to be
>> able to see the connection logging, not only was the key
>> presented to the client from the server using TLSv1.2 but the
>> entire communication used TLSv1.2. Before the change only the key
>> was presented to the client using TLSv1.2 and the rest of the 
>> communications showed TLSv1.0. So somehow the change to the
>> SSL_VERSION parameter allowed this. I am of course the kid that
>> turns around and asks "but why" :-)
> 
> Because previously you didn't complete the TLSv1.2 protocol
> handshaking process given the fact you server didn't support it. It
> then negociated a lesser protocol understood by both parties which
> happen to be TLSv1.0 (the one set by the previous value of
> SSL_VERSION in your catalina.sh startup file).

Yep. This is going to come down to the capabilities of the JVM +
application + support libraries. The good news is you've confirmed
that Tomcat itself can handle an incoming TLSv1.2 connection. That
means that the JVM can support it, so that's one piece of the puzzle
you don't 

Re: I don't understand a recent change released in Tomcat 7.0.70

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lyallax,

Okay, one last time before I start ignoring you. We really are trying
to be helpful. But nobody knows why who are so exercised about this.

You haven't:

a) Clearly explained what you want to do (redirect which requests?
with what response code? in what cases?)
b) Told us what you've tried before (be specific)
c) Explained what in the world your issue has to do with the commit
you have been talking about that first appeared in 7.0.70

...

On 6/24/16 1:19 PM, Lyallex wrote:
> On 24 June 2016 at 16:45, Christopher Schultz 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
> 
> 
> 
>> 3. You can redirect anything yourself if you want to. The only
>> reason for the Realm option was because Tomcat itself is issuing
>> this particular redirect based upon an authentication situation
>> (as defined by the servlet specification).
>> 
>> 4. If you want "easy" redirection from http -> https and you
>> don't want to write the 5-line Filter to do it for you, use
>> url-rewrite and set up a rule that redirects all http:// requests
>> to https:// URLs.
> 
> If you really understood the issue you wouldn't make such a lame
> observation it has nothing to do with not being able to redirect,
> it is to do with the *response code* returned by tomcat when the
> redirect occurs.

I understand the relevant issues perfectly. What I don't understand is
why the response code for the Realm is even an issue for you. From
your description, you don't have or need a Realm. You have just
decided that you want to redirect requests using the http:// scheme to
using the https:// scheme, which is perfectly reasonable.

> I have tried a number of things to try and solve this issue using 
> Servlet Filters but I just can't seem to get the timing right.

Okay. What did you actually try. Show some code and/or configuration.

> The Tuckey UrlRewriteFilter does not make the slightest bit of
> difference. I know this because I tried it. Did you?

I have user url-rewrite to great effect in various situations.

>> And seriously, calm down.
> 
> And seriously, try to understand the issue before criticizing.
> 
> You really are a delicate lot aren't you, the slightest suggestion 
> that you might not be the geniuses you obviously think you and your
> fragile egos crumple and you get all defensive. I've seen it so
> many times in 20+ years as a developer/software engineer that I 
> shouldn't be surprised but I still am.

Nobody is getting defensive, and this isn't about ego. We are trying
to help you and you are just flying off the handle. "THIS CHANGE MAKES
NO SENSE TO ME" and then you talk about how you haven't been able to
make your own code redirect requests. Total non-sequitur IMO.

(In your initial post, you did prepare everyone for a lot of (quite
unnecessary) shouting. I have no idea why shouting would even be
necessary. Did you ever get that sleep you needed?)

I'm happy to help with your root issue... which seems to have nothing
to do with BZ 59399.

>> You completely lost your mind over a new configuration option
>> that you misunderstood.
> 
> Oh the irony

http://www.dailymail.co.uk/tvshowbiz/article-3312236/Alanis-Morissette-u
pdates-1995-hit-Ironic-2015-laughs-admits-song-s-lack-ironies.html

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

iQIcBAEBCAAGBQJXbZ0lAAoJEBzwKT+lPKRY+10P/3LU/4FK0/IrocXpZCZ5CQgN
7zlps1cT2L1fQz53Vva9BiTfNavwo4gfOuSI4oLJvnmymDuJrdakpj8zKRxwVOyQ
ZUfvTye51o1jS8d4zByGo9xas15G5d2LCrhJlKnMgK1WTebC1K12Q7JqUIJA+tx4
UilOMBZrz1T/M+FtWq7WDdtnZP8oA7yJImBDygncGsjUbDMYduCbMsNBf702ALbM
BY5QB2oqPM8RFAT7oMZXgmM3MMrdqXySk9Wkgf5rFD+PcpAqTQOBJP48FlHzimQK
YKYAT28VPJqD8YfIT4Qe0OpZBCEiYGXd4po36S7BusJFNdg5odv4YParcvgn1ZaB
4ceV1YmmRnTI1V2w7y4rkwAA+0uA0v5WALZZz/stfGPirafyqry2ZrraoWNZ1W+Q
Mm+FNpiCJtQ7i0e5DP2S4zrzT+1lf6W9Bg2ri9hYN5dgVhAcQssQ7NSxieAyM6ib
i1dbA7WOgDvjL4tSB31FHrai1gfq1VuV4gfp3nSDA3UI8sdOne87WJGQfYPwVlUD
k3KnhQQpzGYLY9SYCOW+O0A0Lea1fEUFEM1G4qTu4Jzy3Azg3kTSF4M9z0It2Btt
NeN9OyTOTIZ+uqUs4wt5ZnnE6/c2FjAblKe0hoN0/xNp81PtPplXpIAZoGN6DDI0
JRu3u4W1Jd4iRIzicOv2
=M1A5
-END PGP SIGNATURE-

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

RE: Configuring Tomcat to support TLSv1.2

[Caldarale, Charles R]

> From: Daniel Savard [mailto:daniel.sav...@gmail.com] 
> Subject: Re: Configuring Tomcat to support TLSv1.2

> > The SSL_VERSION parameter was already defined by the vendor.

> I still would delete the SSL_VERSION from the catalina.sh or comment it at
> least and adopt the suggested approach to configure everything in the
> server.xml file instead.

The proper place to define environment variables is in bin/setenv.sh, not 
catalina.sh nor startup.sh.  The setenv.sh file (when present) is automatically 
invoked by catalina.sh during Tomcat startup. 

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-24 11:50 GMT-04:00 Joleen Barker :

> Hi Chris,
>
> The SSL_VERSION parameter was already defined by the vendor.
>
>
I still would delete the SSL_VERSION from the catalina.sh or comment it at
least and adopt the suggested approach to configure everything in the
server.xml file instead. Without a specific definition of the SSL_VERSION,
there will be no constraints on the versions at this point. This
SSL_VERSION environment variable will bite you when you will need to
upgrade Tomcat to another version.


> The web application we use allows users to connect to it via FTP, FTPS,
> SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to different back
> end servers. The web application is a proxy.
>
> Without me making the change to the predefined SSL_VERSION parameter that
> was originally configured as "-Dhttps.protocols=TLSv1" to now be configured
> to
> "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for correcting my
> typo) our remote party that uses and AS2 client that is locked down to only
> using TLSv1.2 connection could now connect to us successfully and upload a
> file. So with this change I was able to accomplish the client to connect to
> the Tomcat server. But I am unable to accomplish a successful connection
> when Tomcat is acting as the client to reach the remote AS2 server for us
> to send a file to them. It appears we are not connecting to them using
> TLSv1.2 and therefore we are dropped. I have a ticket open with the vendor
> on this but they don't seem to be any help. I was trying to open the Java
> console on the UNIX server but I am unable to as I do not have any X11
> setup. I am unable to find a command line option to set what is allowed in
> the Java application itself. On one of our test servers a colleague could
> open the console and we saw that none of the TLS options were NOT enabled
> and only SSLv3 was. I am not sure if this is the case with this server that
> I am working on that we have an outside connection open to be able to work
> with the outside customer.  I am unsure if this change would allow us to
> reach them. I didn't know what the catalina.sh TLSv1.2 change versus
> changing the Java application TLSv1.2 change is really responsible for. (I
> know enough to brake stuff...lol) The vendor is not much help. It's very
> frustrating so I reach out to this community and get the help I need.
>
>
The connection that isn't working is initiated by the web application on
your Tomcat server as far as I understand. If so, then there is no
configuration at the Tomcat level that will resolve this issue. You must
look at the SSL debugging info to see what is going on in the negotiation
with the remote party. To do that, use the -Djavax.net.debug=ssl option to
the JVM and look at the log files (probably catalina.out) You should see
the handshaking protocol negotiation.

Perhaps your application is not sending a valid certificate or no
certificate at all or something like that, which then has nothing to do
with the inability to perform a full TLSv1.2 handshaking procedure. Is this
connection worked previously using a less secure protocol?


> Another interesting thing I found in my testing after the change to the
> SSL_VERSION was in place was when I connected to the web application using
> FTPS client using FileZilla in Debug mode to be able to see the connection
> logging, not only was the key presented to the client from the server using
> TLSv1.2 but the entire communication used TLSv1.2. Before the change only
> the key was presented to the client using TLSv1.2 and the rest of the
> communications showed TLSv1.0. So somehow the change to the SSL_VERSION
> parameter allowed this. I am of course the kid that turns around and asks
> "but why" :-)
>
>
Because previously you didn't complete the TLSv1.2 protocol handshaking
process given the fact you server didn't support it. It then negociated a
lesser protocol understood by both parties which happen to be TLSv1.0 (the
one set by the previous value of SSL_VERSION in your catalina.sh startup
file).

-
Daniel Savard

Re: Configuring Tomcat to support TLSv1.2

[Daniel Savard]

2016-06-24 11:15 GMT-04:00 Christopher Schultz :

>
> 
>
No SSL_VERSION environment variable is recognized by a stock Tomcat.
>

I see, however what I meant was the SSL_VERSION variable isn't defined in
the vanilla catalina.sh script. Jolene cleared out this in her next post
saying it was setup by the vendor. I was assuming she was working from a
vanilla installation someone else has customized somewhat, hence my
suggestion to stick on vanilla catalina.sh and so on.

-
Daniel Savard

Re: I don't understand a recent change released in Tomcat 7.0.70

[Lyallex]

On 24 June 2016 at 15:37, Mark Thomas  wrote:
> On 24 June 2016 11:51:25 BST, Lyallex  wrote:
>
> 
>
>>However I can't get my head around your assertion that forcing the use
>>of TLS is a 'user data constraint'
>
> Have a look in the Servlet specification for that phrase. I don't have a copy 
> to hand right now but it will be in the security section.

OK. I'll concede that point, thank you for making that clear

In web.xml a security-constraint can contain an


 and or a


It makes sense to me that auth-constraint is associated with a Realm
given that a Realm is a database of users

It still doesn't make sense to me that a user-data-constraint, which
is 'all about the scheme' should be managed/configured/maintained (use
whatever word feels right) in a component that is 'all about a
database'. That's all I'm saying, it just doesn't 'feel right' that's
all.

As for an alternative solution, well until I can get enough time
together to get a build system together I haven't got one, that
doesn't mean that there isn't one. Building Tomcat is now working it's
way up my todo list.

I'll get back to you.

Lyallex

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

Re: Fail secure state

[Anthony Biacco]

On Fri, Jun 24, 2016 at 7:36 AM, Jason Ricles 
wrote:

> Yes, which has security modules and settings which may fail to be
> loaded or might be unloaded from tomcat if the computer fails to start
> up or shut down correctly. In that case, how does tomcat handle that
> failure?
>


Furthermore, what state the filesystem is in if Tomcat fails to start/stop.
The state of the webapp dirs (if exploded from war), work dirs, temp dir,
which may contain data you deem sensitive.

-Tony


>
> On Thu, Jun 23, 2016 at 6:19 PM, André Warnier (tomcat) 
> wrote:
> > On 23.06.2016 21:43, Jason Ricles wrote:
> >>
> >> Fail-secure is a condition achieved by the application server in order
> >> to ensure that in the event of an operational failure, the system does
> >> not enter into an unsecure state where intended security properties no
> >> longer hold
> >
> >
> > Just to make sure : you do know that tomcat is a computer program, right
> ?
> >
> >
> >>
> >> On Thu, Jun 23, 2016 at 3:33 PM, Mark Thomas  wrote:
> >>>
> >>> On 23/06/2016 20:21, Jason Ricles wrote:
> 
>  Does tomcat have a secure state if system initialization fails,
>  shutdown fails, or aborts fail?
> >>>
> >>>
> >>> Define "secure state", "system initialization", "fails", "shutdown" and
> >>> "aborts" and we might be able to help you.
> >>>
> >>> Mark
> >>>
> >>>
> >>> -
> >>> 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
> >>
> >
> >
> > -
> > 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: I don't understand a recent change released in Tomcat 7.0.70

[Lyallex]

On 24 June 2016 at 16:45, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256



> 3. You can redirect anything yourself if you want to. The only reason
> for the Realm option was because Tomcat itself is issuing this
> particular redirect based upon an authentication situation (as defined
> by the servlet specification).
>
> 4. If you want "easy" redirection from http -> https and you don't
> want to write the 5-line Filter to do it for you, use url-rewrite and
> set up a rule that redirects all http:// requests to https:// URLs.

If you really understood the issue you wouldn't make such a lame observation
it has nothing to do with not being able to redirect, it is to do with
the *response code*
returned by tomcat when the redirect occurs.

I have tried a number of things to try and solve this issue using
Servlet Filters but I just can't seem to get the timing right.

The Tuckey UrlRewriteFilter does not make the slightest bit of difference.
I know this because I tried it. Did you?

> And seriously, calm down.

And seriously, try to understand the issue before criticizing.

You  really are a delicate lot aren't you, the slightest suggestion
that you might not be the geniuses you obviously think you
and your fragile egos crumple and you get all defensive. I've seen it
so many times in 20+ years as a developer/software engineer that I
shouldn't be surprised but I still am.
.
> You completely lost your mind over a new
> configuration option that you misunderstood.

Oh the irony



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

Re: How to force keystoreFile and truststoreFile to be absolute paths

[Mark Eggers]

Chris,

On 6/24/2016 9:07 AM, Christopher Schultz wrote:
> Mark,
> 
> On 6/21/16 3:46 PM, Mark Eggers wrote:
>> On 6/21/2016 11:03 AM, Miller, Gerald wrote:
>>> I'm seeing errors from attempts to append uncorrected paths
>>> (e.g., C:\out\) and corrected ones (e.g., ~/out/) onto some
>>> arbitrary path.
>>>
>>> [snip]
> 
>> [snip]
> 
>> keystoreFile="${user.home}/Apache/apache-tomcat-8.0.36/conf/keystore.j
> ks"
> 
> One
> 
> of the problems is that "~", while often used to mean "the current
> user's home directory" is really only a CLI shell concept. Mark's use
> of ${user.home} id correct, here, and should always be fully-qualified.
> 
> I think this is the core of the problem.
> 
> -chris

Exactly.

The path needs to be absolute rather than relative. I don't know where
relative paths start from (should read the documentation or experiment
to find out).

As you noted, tildes are a shell concept. I don't know which shells
(most likely all tcsh, sh, bash, csh shells at this point but certainly
not Windows).

Using shortcuts (even if they worked) would certainly make the
configuration file non-portable between systems.

I was going to let the original poster read the docs and the example I
gave to figure out the details. Starting a question with a rant even if
you are frustrated doesn't engender volunteer help . . . :-)

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature

Re: How to force keystoreFile and truststoreFile to be absolute paths

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/21/16 3:46 PM, Mark Eggers wrote:
> On 6/21/2016 11:03 AM, Miller, Gerald wrote:
>> I'm seeing errors from attempts to append uncorrected paths
>> (e.g., C:\out\) and corrected ones (e.g., ~/out/) onto some
>> arbitrary path.
>> 
>> [snip]
> 
> [snip]
> 
> keystoreFile="${user.home}/Apache/apache-tomcat-8.0.36/conf/keystore.j
ks"

One
> 
of the problems is that "~", while often used to mean "the current
user's home directory" is really only a CLI shell concept. Mark's use
of ${user.home} id correct, here, and should always be fully-qualified.

I think this is the core of the problem.

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

iQIcBAEBCAAGBQJXbVrSAAoJEBzwKT+lPKRY5OsQAJQSQws5p/IzxSa4nWPpXy6+
t7i1UhJH+AkkaD3kLNG/55NWjUYEm9B8ig65qy4Kw3LNKbtZKkS2WsXJzzKZil50
wsC82jU0F3uXgp3iRC2LfSnlrOPFq8YI38P8zP1EBDSgIGNwhaAhTITkm0/VTMlB
lroEl5br700HU0A0U+79koA+Lx9POV0e/VEzseCTmwZye2RTqnZHgz0bEYyNzNqr
h13idflc+jx695eQXiDdQXYQbYJbrBlAkxz7nnxcS+peToe+94mZK7+vY9Aas3zo
HT0j7ThqZp2VWAxV1Kjh+AaADfqapYLNRAxsKszkiZXeMa2bu2KiPCba9BnZFjuZ
SyLYDEHCCH/+enf390tY4A0Ip3XkdGAEmleDdR/5KJE3v01Vso3SYUuqztdUc3VD
3eVXPPYHxjYjacwJq4+Xm+13bfyNSXhU1rJ7DpGi21Krok+BUi0CNrwGB2Ha1Z3Z
mlaBpFDp2l1vSvuwJFTR0eRTa2v7ng73unbpt1/lnNv98PCRRo3214uPzS5kvARW
ofmqQfOubhxdY87teYp+dBFyLkHDBDkLqeM5G7TWHzwlkkN5hNJpPFDVQjSr7S/v
uLhJSBNL+OZ2/W9isQVud+KQgvdM0R8877xr8oZEVKsYMR0IBButHga6m+h9XQcl
/w1MhDgcyH9hT9oRbOAA
=vayW
-END PGP SIGNATURE-

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

Re: Tomcat 7 performance tuning take full advantage of hardware

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Tanming,

On 6/21/16 9:04 AM, tanming1...@163.com wrote:
> Hi, I had done some stress tests on Apache Tomcat/7.0.47 and found
> that tomcat didn't taken full advantage of hardware resources. I
> had used Apache Benchmark tool(ab) to do benckmark,and then monitor
> the jvm instance of tomcat via jvisualvm. In the benchmark,I just
> test the response time of request a jsp. The CPU usage is not
> high,about 20%,even when the concurrent requests increased. So how
> can I to do some performance tuning to make tomcat 7 take full
> advantage of hardware resources?

What makes you think that the CPU should be higher than 20%?

What does your test load profile look like?

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

iQIcBAEBCAAGBQJXbVpTAAoJEBzwKT+lPKRYcM0P/R7J7aCIcIY5cCuPjrRQRPk7
ZeGcUmEbEr+5MxXC4jYFSqZuxthpWjta/kICmTPAMF/n6YB3206SHBSUOWVitCqX
FxlaPCmhkoZ+9nyeEhlRTr3y6HrqfZBpYmQZMac8FSFV22Expq/k0vUhGqPKsmjy
g8eQiA8e8L7BxEDHS5CAPawvsSNog6ZrBi2Gdjo69C17QubM0lsbNKZ7NNNwmsDE
pSiaTa0lCL6xxUkd+un74JhPKxHBDPNdw+Zr7sEWky6K5ophcJUf4Ch2Q+TX8Hgr
EiHMnknqAi7vI5zkhnC3AgMEt+9hurMqnBTZ8B4CTq/JtB4YP72AchN3aUSGoIFy
zXolRZSR3SqmhxNTCLVegNNTF502DRCvALa+ZjZ+9SfQAPF3UDrcvnm4MZ+4btIz
gekP3hGRq2v9Z5m4KgwQpFHyRF6ncRos3e3+bn7OgYi6U3SyY+UO+2PVsXurrUy6
YtMIugERc79z8d8zh1pXCznT6TCE/ePakWqL/hImZce3wP+9InlLilgbcK68D5W2
7zY82wj1nig6GinUjYeQMf/LzC2AYKotza/gYFx8Fv896OkjlTaG/Zvy1E2ZJubK
jwYmRjMVEd7tvQBuJjuKOlVnCv7TMAAvNOVkZxIvld4GbhJZJUmJg2X4g0ticIT0
ywmiAvvoMjp7Ugj9Irs3
=wHy7
-END PGP SIGNATURE-

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

Re: Configuring Tomcat to support TLSv1.2

[Joleen Barker]

Hi Chris,

The SSL_VERSION parameter was already defined by the vendor.

The web application we use allows users to connect to it via FTP, FTPS,
SSH, AS2, HTTPS, HTTP, etc. to transfer files through it to different back
end servers. The web application is a proxy.

Without me making the change to the predefined SSL_VERSION parameter that
was originally configured as "-Dhttps.protocols=TLSv1" to now be configured
to
"-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" (thank you for correcting my
typo) our remote party that uses and AS2 client that is locked down to only
using TLSv1.2 connection could now connect to us successfully and upload a
file. So with this change I was able to accomplish the client to connect to
the Tomcat server. But I am unable to accomplish a successful connection
when Tomcat is acting as the client to reach the remote AS2 server for us
to send a file to them. It appears we are not connecting to them using
TLSv1.2 and therefore we are dropped. I have a ticket open with the vendor
on this but they don't seem to be any help. I was trying to open the Java
console on the UNIX server but I am unable to as I do not have any X11
setup. I am unable to find a command line option to set what is allowed in
the Java application itself. On one of our test servers a colleague could
open the console and we saw that none of the TLS options were NOT enabled
and only SSLv3 was. I am not sure if this is the case with this server that
I am working on that we have an outside connection open to be able to work
with the outside customer.  I am unsure if this change would allow us to
reach them. I didn't know what the catalina.sh TLSv1.2 change versus
changing the Java application TLSv1.2 change is really responsible for. (I
know enough to brake stuff...lol) The vendor is not much help. It's very
frustrating so I reach out to this community and get the help I need.

Another interesting thing I found in my testing after the change to the
SSL_VERSION was in place was when I connected to the web application using
FTPS client using FileZilla in Debug mode to be able to see the connection
logging, not only was the key presented to the client from the server using
TLSv1.2 but the entire communication used TLSv1.2. Before the change only
the key was presented to the client using TLSv1.2 and the rest of the
communications showed TLSv1.0. So somehow the change to the SSL_VERSION
parameter allowed this. I am of course the kid that turns around and asks
"but why" :-)

-Joleen

On Fri, Jun 24, 2016 at 11:15 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Daniel,
>
> On 6/22/16 12:59 AM, Daniel Savard wrote:
> > 2016-06-21 19:08 GMT-04:00 Joleen Barker
> > :
> >
> >> Hello Daniel,
> >>
> >> Thank you for your replies.
> >>
> >> Yes, I have the Java build 1.7.0_71 installed and I have the
> >> Unlimited security package installed as the application from the
> >> vendor requires it.
> >>
> >> Ok, you say never to edit the catalina,sh. I can change it back.
> >> The settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"
> >>
> >>
> > I believe this is not from the original version of the file. I have
> > no longer any Tomcat 7 installed to check this, however if I am
> > checking my Tomcat 8 catalina.sh, there is no SSL_VERSION
> > environment variable anywhere. If you are having an already
> > modified catalina.sh, it will be difficult to provide any
> > meaningful guidance.
>
> +1
>
> No SSL_VERSION environment variable is recognized by a stock Tomcat.
>
> Furthermore, the system property "https.protocols" (not that it's
> plural, and Jolene had used the singular noun) only effects the
> default configuration for HttpsURLConnection and URL.openStream calls.
>
> https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_an
> d_https
>
> >> Why is it set for only one version in the catalina.sh what is
> >> having this set to one version limiting us to?
> >>
> >>
> > It seems your catalina.sh has already been modified by someone
> > else. This doesn't look like the vanilla version of the catalina.sh
> > file.
> >
> >
> >> Our connector has this set in it:
> >>
> >> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"
> >>
> >> Is this all we need to allow TLSv1.2 clients to come in and for
> >> Tomcat acting as a client to go out as TLSv1.2?
> >
> > You didn't provide enough details about your connector, so, read
> > this page:
> > https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> The above should be all you need. In fact, current Tomcat versions
> should out-of-the-box support TLSv1.0, TLSv1.1, and TLSv1.2 assuming
> that the JVM supports those protocols as well.
>
> > I assume you are configuring a NIO or BIO connector, then
> > sslProtocol="TLS" is the only needed attribute to support TLSv1,
> > TLSv1.1 and TLSv1.2. The sslEnabledProtocols attribute is not
> > necessary since it overalps with 

Re: I don't understand a recent change released in Tomcat 7.0.70

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lyllax,

On 6/24/16 1:30 AM, Lyallex wrote:
> On 23 June 2016 at 19:43, Mark Thomas  wrote:
>> On 23/06/2016 17:56, Lyallex wrote:
>>> I'm trying to understand why a recent change in 7.0.70 has been
>>> done the way it has. The change makes absolutely no sense to me
>>> and I need to ask the implementer why in the name of sanity he
>>> did what he did. I'm talking to you markt whoever you are :-)
>>> 
>>> Where should I ask the question? dev list?
>>> 
>>> I couldn't care less how much shouting ensues, I just need to
>>> get some sleep.
>> 
>> How about you cut the attitude and just ask your question?
> 
> OK, I will.
> 
> To give this some context and with the greatest respect to a
> dedicated committer none of what follows is intended as criticism
> it's just that I think the current solution to 59399 need
> rethinking
> 
> My commercial site has been up for years, there are links dating
> back years that refer to the old http scheme I have no control over
> this, now, whenever I get a hit from an 'old' link I need to force
> the switch to https, lots of sites have this probem and need a
> solution, it has nothing whatsoever to do with dabases in any way
> shape or form.
> 
> So,
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
> 
> What has the status code returned when switching from http ->
> https got to do with a Realm?
> 
> http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html
> 
>  "A Realm is a "database" of usernames and passwords that
> identify valid users of a web application .. " 
> 
> Or: What has the status code returned when switching from http -> 
> https got to do with a database of usernames and passwords?
> 
> https://tomcat.apache.org/tomcat-7.0-doc/config/realm.html
> 
> JDBCDatabaseRealm
> 
> attrbute: transportGuaranteeRedirectStatus
> 
>  The HTTP status code to use when the container needs to
> issue an HTTP redirect to meet the requirements of a configured
> transport guarantee. The prpvoded status code is not validated. If
> not specified, the default value of 302 is used. 
> 
> I just don't get why this is here
> 
> furthermore https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
> 
>  Mark Thomas 2016-06-15 11:12:11 UTC
> 
> This has been implemented as a new option in the Realm and will
> has implemented in: - 9.0.x for 9.0.0.M9 onwards - 8.5.x for 8.5.4
> onwards - 8.0.x for 8.0.37 onwards - 7.0.x for 7.0.70 onwards 
> 
> 
> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your 
> comment seems to imply that all Realms have it
> (transportGuaranteeRedirectStatus)
> 
> In which case surely it should be a common attribute and (I'm
> guessing here) the functionality be included in the base class for
> Realm
> 
> What happens if I don't use JDBCDatabaseRealm, does that mean I
> can't configure the switchover status code. What happens if I write
> my own Realm?
> 
> In the 'good old days' it was common practice to only switch to
> https during or after signing in to an application, networks were
> slow and encryption takes time, now networks are faster and the
> overhead isn't such an issue. Entire sites now use the https
> scheme, I know mine does. I can see a situation where, because the
> mighty Google says it must be so, even an entirely static site with
> no database and no manager will be served up under https. How is
> such a site suppose to implement https?
> 
> FYI I have it in black and white, from a Google webaster forum 
> responder that, in the event of  a tie between two pages in a
> ranking calculation, the https scheme would produce a ranking
> signal that would elevate the https page above the non https page
> in the resulting rankings.
> 
> Once again this is not intended as criticsm of a dedicated and 
> prolific committer

Wow, what a diatribe. What is necessary?

1. This is a new option which defaults to the previous behavior. This
should literally effect nobody except people who care about it.

2. There is a bug in the documentation which suggests that its only
available for a single Realm when it is in fact available for all Realms
.

3. You can redirect anything yourself if you want to. The only reason
for the Realm option was because Tomcat itself is issuing this
particular redirect based upon an authentication situation (as defined
by the servlet specification).

4. If you want "easy" redirection from http -> https and you don't
want to write the 5-line Filter to do it for you, use url-rewrite and
set up a rule that redirects all http:// requests to https:// URLs.

And seriously, calm down. You completely lost your mind over a new
configuration option that you misunderstood. You made it sound like we
introduced a breaking change to a product that brought-down your whole
enterprise. But the reality is that a relatively benign commit has
completely enraged you for ... what reason exactly?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - 

Re: How to configure SPNEGO authentication with fallback to FORM auth?

[ken edward]

On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas  wrote:

> On 24/06/2016 16:17, ken edward wrote:
> > On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:
> >
> >> On 24 June 2016 14:22:32 BST, ken edward  wrote:
> >>> Hello,
> >>>
> >>> I have tomcat 8 on linux, configured with kerberos/SPNEGO
> >>> authentication.
> >>> All works well, but if the client cannot use kerberos to authenticate,
> >>> it
> >>> will not fallback to FORM authentication.
> >>>
> >>> I see some references that tomcat 8 does not do fallback negotiation
> >>> for
> >>> FORM auth. True?
> >>
> >> Yes
> >>
> >>> Any workarounds?
> >>
> >> Nothing simple. Both SPNEGO and FORM have their complications. You'll
> need
> >> to code some form of custom solution.
> >>
> >> Have a look in the archives. This has come up before and I think there
> is
> >> some sample code that might get you most of the way there.
> >>
> >>
> >>
> > I had already searched the mail archives, and did not see any sample
> code.
> > If anyone has any insight, please do post some code fragments.
>
> I was thinking of this:
> http://wiki.apache.org/tomcat/SSLWithFORMFallback
>
> Not quite what you are looking for but it might help.
>
>
I guess I need to extend the SPNEGO valve code in tomcat 8 to handle
fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a simple
and essential use case. Perplexing that it is not implemented.

Re: Fail secure state

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 6/24/16 9:36 AM, Jason Ricles wrote:
> Yes, which has security modules and settings which may fail to be 
> loaded or might be unloaded from tomcat if the computer fails to
> start up or shut down correctly. In that case, how does tomcat
> handle that failure?

Don't blame Jason: he's in regulatory hell. It happens to us all at
one point or another. He's got to check a checkbox somewhere that says
"we swear nothing bad will ever happen," even though the reality of
the situation is that bad things can happen all the time. If we could
prevent them (fail-secure), then nobody would ever have intrusions.

Anyhow, Jason, it's hard to say whether Tomcat itself would
"fail-secure" unless you are interested in some specific component.
For example, if Tomcat can't initialize the TLS system, then the TLS
endpoint will never come-up, thus making is fail-secure. (A more
specific example is if you are using tcnative with OpenSSL and trying
to use FIPS-mode... if you "require" FIPS mode, then Tomcat will fail
if FIPS-mode fails, so you will get a Tomcat that won't listen to
outside traffic. I'd call that fail-secure).

On the other hand, there are things that can happen with the JVM where
the process becomes completely unpredictable. Once an OOME happens,
for instance, there are lots of weird things that can happen (or not
happen). Generally, once the JVM is upset about something like that,
errors happen all over the place and "no" meaningful work gets done
(requests aren't serviced because they fail at some stage, etc.). But
it's conceivable that some security control could fail to process
correctly and yet the request would proceed to be serviced. I can't
think of a situation where Tomcat would actually allow that to happen,
but in a massive-JVM-failure scenario, there is simply no way to say
definitively that nothing bad will ever happen.

Any product or vendor that claims otherwise is simply lying to you.

- -chris

> On Thu, Jun 23, 2016 at 6:19 PM, André Warnier (tomcat)
>  wrote:
>> On 23.06.2016 21:43, Jason Ricles wrote:
>>> 
>>> Fail-secure is a condition achieved by the application server
>>> in order to ensure that in the event of an operational failure,
>>> the system does not enter into an unsecure state where intended
>>> security properties no longer hold
>> 
>> 
>> Just to make sure : you do know that tomcat is a computer
>> program, right ?
>> 
>> 
>>> 
>>> On Thu, Jun 23, 2016 at 3:33 PM, Mark Thomas 
>>> wrote:
 
 On 23/06/2016 20:21, Jason Ricles wrote:
> 
> Does tomcat have a secure state if system initialization
> fails, shutdown fails, or aborts fail?
 
 
 Define "secure state", "system initialization", "fails",
 "shutdown" and "aborts" and we might be able to help you.
 
 Mark
 
 
 ---
- --

 
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
>>> 
>> 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXbVNRAAoJEBzwKT+lPKRY/dIP/jwnDwgdek1DkyeU9le5tfNm
bhQCvMkUhwIXMVmsB9hff4/paehggNG4fFn+TvroI4cCIYrzwwV9fH8E2NwlmQ7n
JXwazQ7HfwCkJyBkv9vANr+oWhMXPx5KMQkOeoiUKUkd+NOB4TYmFeP9gsBjM5gR
nXUG6Cb/n4Ph4wpqfzKDG5445iiYE68odmo5lhql0aWWFx6A1j6JozW6jVkcuaLm
NadGkFzqAOpOYkNC+acl4xpPTz8PgZo1gK6h9Bw/FgsmlPZKabE99YECif0Wts6q
foczkVn+wQro/eo39RXApG4yGVo6S+io5bHypoSpulqLtHdZGEgykYDbko32FuAV
PLVHcCjfTkoOfX/qJhcVRclkhkP6Qs+dxrLofz7ecwYVSyRIIHg1JLYFUiQm283p
lZzm2lbn84J5qNrCUfnkf8FPbEafVMxWVFtHn7r4eJ8vvnc/hXtbk6xAHddSqwAB
vV9Z7dJ3YayhLR3M8YdFNvG1bdVmerQcaAggpxYSDi0oPFInxY8mTfiMuQiU6wNy
1tKJ8W7vb1WKUS0Sx/rAWSo32zcDWe+JsYVnKQgidy8VL8OY62kROgvpP9eKeL0X
nFG3V6ob5B/UeZZt1PU1nCg+KFpsw6cxNxvPUFg7FYu8CeV5Jts1mC0CZ/6i8wnH
H6sKQS6ZJHDSJChobgpG
=jHCI
-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 configure SPNEGO authentication with fallback to FORM auth?

[Mark Thomas]

On 24/06/2016 16:17, ken edward wrote:
> On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:
> 
>> On 24 June 2016 14:22:32 BST, ken edward  wrote:
>>> Hello,
>>>
>>> I have tomcat 8 on linux, configured with kerberos/SPNEGO
>>> authentication.
>>> All works well, but if the client cannot use kerberos to authenticate,
>>> it
>>> will not fallback to FORM authentication.
>>>
>>> I see some references that tomcat 8 does not do fallback negotiation
>>> for
>>> FORM auth. True?
>>
>> Yes
>>
>>> Any workarounds?
>>
>> Nothing simple. Both SPNEGO and FORM have their complications. You'll need
>> to code some form of custom solution.
>>
>> Have a look in the archives. This has come up before and I think there is
>> some sample code that might get you most of the way there.
>>
>>
>>
> I had already searched the mail archives, and did not see any sample code.
> If anyone has any insight, please do post some code fragments.

I was thinking of this:
http://wiki.apache.org/tomcat/SSLWithFORMFallback

Not quite what you are looking for but it might help.

Mark

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

Re: error during startup after applying changes from CVE-2016-3092

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bernd,

On 6/22/16 8:05 AM, Lentes, Bernd wrote:
> 
> 
> - On Jun 22, 2016, at 1:52 PM, Bernd Lentes
> bernd.len...@helmholtz-muenchen.de wrote:
> 
>> Hi,
>> 
>> i changed maxHttpHeaderSize in server.xml following the
>> recommendation in CVE-2016-3092. I changed it to 2048 bytes.
>> 
>> > connectionTimeout="2" redirectPort="8443"
>> maxHttpHeaderSize="2048" />  

Re: Webapp with underscore in it's name leads to failed session-cookies

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 6/22/16 6:58 AM, Mark Thomas wrote:
> On 22/06/2016 11:29, Mark Thomas wrote:
>> On 22/06/2016 09:28, Markus Näher wrote:
> 
>>> In the web console of firefox, I could see that the session
>>> cookie was set with the path /jsf%5ftest, while other cookies
>>> (set by myfaces) were correctly set with the path /jsf_test. It
>>> looks like firefox treats /jsf_test and /jsf%5ftest as
>>> different pathes and therefore does not send the session cookie
>>> with the next request, while chromium ignores the difference.
>> 
>> I see a similar issue if I rename the examples web application
>> to "exa_mples". It shouldn't take me too long to figure out where
>> things are going wrong.
> 
> Tomcat is correctly setting the path for the session cookie as
> "/exa_mples"
> 
>> I'll keep that in mind once I figure out the root cause. It may
>> impact how we fix this.
> 
> The problem is that FireFox, by default, encodes all URIs and
> doesn't take account of the encoding when matching URIs to cookie
> paths. Failing to account for encoding looks like a FireFox bug to
> me.
> 
> A possible work-around is to disable the automatic encoding of URLs
> that FireFox provides by setting network.standard-url.encode-utf8
> to false under about:config.
> 
>>> Unfortunately, my real-world productive project has an
>>> underscore in it's name too, but as many users have bookmarked
>>> it, I can't just rename it.
>>> 
>>> Is this a bug in tomcat ?
>> 
>> At this point I'd say it is likely but until I dig into this to
>> figure out exactly what the root cause is, I can't be sure.
> 
> No, it is a FireFox bug. And a long standing one at that. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=665851

Something doesn't smell right, here.

I've been using Mozilla Firefox and Tomcat together for ... ever and
my primary web application used for development is called
"cschultz-[product]" (note the hyphen). I have never ever had any
issues with that hyphen bring broken anywhere along the way. (I'm not
sure I've tried an underscore... I could try that). Here are my
relevant settings from about:config:

network.standard-url.encode-utf8;true
network.standard-url.escape-utf8;true

Does this only effect underscores?

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

iQIcBAEBCAAGBQJXbVAvAAoJEBzwKT+lPKRYcC4QAJ9vK+NvkJCTDKfW80BaLZSO
j7jXWgbMf9rOTGfV7BSD+seBcId2ixJjOjod2yNJJ21d83BXbdPFGP96staRTt3v
8TOB/42WBIlfMt+CHvI/ltVBUsQ644so55qy6HrQcBO9yjVJiy3mzyJMTjAjLGZW
nGvnZm4enUGqPqiPgY26TRxOR9toNpH9mq4qHQdSM+vesLnB7t0C2pNt0v5Wj3Og
Nr6g8GIWN0czA8eClUp8I4PQP/ZCEs5o8lbkBo9MCmz7H0uijEIfI7R0uDE2ptWy
pZ8N7a4kv/8LHZdShGQJ/RSUDVTb3dbaI2rfpOfKmKEVmt3LSEgHNb6N+DB64KLW
qMXhiKqiSqi2UUOgOZvbBmfpcDFPEd7uYTnHzXjojeOsKxF5jtVxpgEGrWTcTY9t
F3BdVk5PuYUZTAI3fpOT5CuAHfZ8hThi7ouWiIjo9LlYBq8senEXteXwTvZnfJGc
rsOq7ADHQX1T7MQjrH7qqIfSeXb0ekaucRubp2uXH6WSZ7kbGmssUc5M/ZTEOcWu
NJr+XXHKyp7+8ubBgTWZLRVnl1ZrMLAQMklIEj3TbURYUlSQTKDLkwGHHDyFNZck
mamDfoiu/zSbOn6ocuoDBm0UXfK24FDbf/Ega7Y7V+ChFuKPLKdf8pUNPGkuqBmA
Q8lPLYh11HWvayvXTP50
=TobU
-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 configure SPNEGO authentication with fallback to FORM auth?

[ken edward]

On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:

> On 24 June 2016 14:22:32 BST, ken edward  wrote:
> >Hello,
> >
> >I have tomcat 8 on linux, configured with kerberos/SPNEGO
> >authentication.
> >All works well, but if the client cannot use kerberos to authenticate,
> >it
> >will not fallback to FORM authentication.
> >
> >I see some references that tomcat 8 does not do fallback negotiation
> >for
> >FORM auth. True?
>
> Yes
>
> > Any workarounds?
>
> Nothing simple. Both SPNEGO and FORM have their complications. You'll need
> to code some form of custom solution.
>
> Have a look in the archives. This has come up before and I think there is
> some sample code that might get you most of the way there.
>
>
>
I had already searched the mail archives, and did not see any sample code.
If anyone has any insight, please do post some code fragments.

Ed

Re: Configuring Tomcat to support TLSv1.2

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 6/22/16 12:59 AM, Daniel Savard wrote:
> 2016-06-21 19:08 GMT-04:00 Joleen Barker
> :
> 
>> Hello Daniel,
>> 
>> Thank you for your replies.
>> 
>> Yes, I have the Java build 1.7.0_71 installed and I have the
>> Unlimited security package installed as the application from the
>> vendor requires it.
>> 
>> Ok, you say never to edit the catalina,sh. I can change it back.
>> The settings originally was SSL_VERSION="-Dhttps.protocol=TLSv1"
>> 
>> 
> I believe this is not from the original version of the file. I have
> no longer any Tomcat 7 installed to check this, however if I am
> checking my Tomcat 8 catalina.sh, there is no SSL_VERSION
> environment variable anywhere. If you are having an already
> modified catalina.sh, it will be difficult to provide any
> meaningful guidance.

+1

No SSL_VERSION environment variable is recognized by a stock Tomcat.

Furthermore, the system property "https.protocols" (not that it's
plural, and Jolene had used the singular noun) only effects the
default configuration for HttpsURLConnection and URL.openStream calls.

https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_an
d_https

>> Why is it set for only one version in the catalina.sh what is
>> having this set to one version limiting us to?
>> 
>> 
> It seems your catalina.sh has already been modified by someone
> else. This doesn't look like the vanilla version of the catalina.sh
> file.
> 
> 
>> Our connector has this set in it:
>> 
>> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"
>> 
>> Is this all we need to allow TLSv1.2 clients to come in and for
>> Tomcat acting as a client to go out as TLSv1.2?
> 
> You didn't provide enough details about your connector, so, read
> this page: 
> https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

The above should be all you need. In fact, current Tomcat versions
should out-of-the-box support TLSv1.0, TLSv1.1, and TLSv1.2 assuming
that the JVM supports those protocols as well.

> I assume you are configuring a NIO or BIO connector, then
> sslProtocol="TLS" is the only needed attribute to support TLSv1,
> TLSv1.1 and TLSv1.2. The sslEnabledProtocols attribute is not
> necessary since it overalps with sslProtocol attribute. Note if you
> do not specify this attribute it defaults to TLS anyway.
> 
> If you read the documentation page above, you will see the
> sslProtocol attribute is actually passing the value to Java 7.
> That's why there is no need to temper with the catalina.sh to try
> to set this for Java before hand. The proper way to configure
> Tomcat is to modify files in the conf directory only. Playing with
> files in bin and lib is not a recommended approach.

+1

Jolene, how are you determining that Tomcat is *not* handling TLSv1.2?

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

iQIcBAEBCAAGBQJXbU6fAAoJEBzwKT+lPKRYKmkP/0kJX7VVA/uQOUa/OBHR0JW8
UvXgPLIpNkjCV7V5rPho1w6Tp+JYpdOvCEfU5baQB8ZX/rUKG6g9leQZOw7FPmTo
uFnmGdXKjXj/BU/2YfjC85+y+pcHCOfDdHMsC9HObo0TIYJr9o2mKhuEBgvl8otD
A8kNkzZZvbhSmvyQ5JJnurYF9P5n4QB/EsfwjOkHeMEP4ifwFXdXVBV2ozeTS4HP
0auydpdYnBlA1pkz0YSggW5kwr/NI/vcySCWIJC4SFMyMnz6z05YSxaGeDuAp3BI
MHMytD/2+wxxAU8kdQQ++gcQqWF6ZNAyJETjOhWKvXWiNawLeV6ruubE1cvRo3PU
BJv85qVLySbzs5eyCSVnypq9MMo8xRDTcd8N7/KNcu/FUUYaxQclaTFkPIBFYfn7
bm3CFdqmUco1kg/Xsk4HIX3je2nubtQPXqhGerc3ax1SehVrEzQDB493/jEYrBYp
RxXYbG2775x4QcN42VaQm4PiwwQUBymoKbm7utqeJMVLXbeBb6VSbWglw31ld2yl
UN59V7yzWScB4HWppsb5RbmAyeNMqX/HFmZy1P2KuC8mHMHYwlcR8FYWx0iYlOZB
iHR7Xf6LfaWyTHxGBMnBtdDXbJH77In1nKXw1Sucl6I0gZe0lHUAFy7tJHG+N/Pc
SfDuRhaC0MDjIXEBuyA2
=SA17
-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 configure SPNEGO authentication with fallback to FORM auth?

[Mark Thomas]

On 24 June 2016 14:22:32 BST, ken edward  wrote:
>Hello,
>
>I have tomcat 8 on linux, configured with kerberos/SPNEGO
>authentication.
>All works well, but if the client cannot use kerberos to authenticate,
>it
>will not fallback to FORM authentication.
>
>I see some references that tomcat 8 does not do fallback negotiation
>for
>FORM auth. True?

Yes

> Any workarounds?

Nothing simple. Both SPNEGO and FORM have their complications. You'll need to 
code some form of custom solution.

Have a look in the archives. This has come up before and I think there is some 
sample code that might get you most of the way there.

Mark


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

Re: I don't understand a recent change released in Tomcat 7.0.70

[Mark Thomas]

On 24 June 2016 11:51:25 BST, Lyallex  wrote:


 
>However I can't get my head around your assertion that forcing the use
>of TLS is a 'user data constraint'

Have a look in the Servlet specification for that phrase. I don't have a copy 
to hand right now but it will be in the security section.

> but it appears that any attempted
>discussion of design decisions is considered a criticism at least and
>a personal insult at worst so I won't go there.

Design discussions are fine but your (over) reaction to criticism you imagine 
you might receive gives your emails an unnecessarily aggressive tone.

There are other places this configuration could go. The Context being the most 
obvious. However, given the existing relationship between Realm, security 
constraints and user data constraints, Realm seems more logical. It is also 
consistent with the general approach in Tomcat of placing configuration on the 
element that uses it rather having everything on the Context.

Mark


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

Re: Fail secure state

[Jason Ricles]

Yes, which has security modules and settings which may fail to be
loaded or might be unloaded from tomcat if the computer fails to start
up or shut down correctly. In that case, how does tomcat handle that
failure?

On Thu, Jun 23, 2016 at 6:19 PM, André Warnier (tomcat)  wrote:
> On 23.06.2016 21:43, Jason Ricles wrote:
>>
>> Fail-secure is a condition achieved by the application server in order
>> to ensure that in the event of an operational failure, the system does
>> not enter into an unsecure state where intended security properties no
>> longer hold
>
>
> Just to make sure : you do know that tomcat is a computer program, right ?
>
>
>>
>> On Thu, Jun 23, 2016 at 3:33 PM, Mark Thomas  wrote:
>>>
>>> On 23/06/2016 20:21, Jason Ricles wrote:

 Does tomcat have a secure state if system initialization fails,
 shutdown fails, or aborts fail?
>>>
>>>
>>> Define "secure state", "system initialization", "fails", "shutdown" and
>>> "aborts" and we might be able to help you.
>>>
>>> Mark
>>>
>>>
>>> -
>>> 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
>>
>
>
> -
> 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

How to configure SPNEGO authentication with fallback to FORM auth?

[ken edward]

Hello,

I have tomcat 8 on linux, configured with kerberos/SPNEGO authentication.
All works well, but if the client cannot use kerberos to authenticate, it
will not fallback to FORM authentication.

I see some references that tomcat 8 does not do fallback negotiation for
FORM auth. True? Any workarounds? I saw waffle 1.8, but that only works on
windows (I am on linux), Setting Auth-method to SPNEGO, FORM doesn't work.

Thanks,
Ed

Re: I don't understand a recent change released in Tomcat 7.0.70

[Lyallex]

On 24 June 2016 at 10:01, Mark Thomas  wrote:
> On 24/06/2016 06:30, Lyallex wrote:
>
> 
>
>> I think the current solution to 59399 need rethinking
>>
>> My commercial site has been up for years, there are links dating back
>> years that refer to the old http scheme
>> I have no control over this, now, whenever I get a hit from an 'old'
>> link I need to force the switch to https, lots of sites have this
>> probem and need a solution, it has nothing whatsoever to do with
>> dabases in any way shape or form.
>>
>> So,
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
>>
>> What has the status code returned when switching from http -> https
>> got to do with a Realm?
>
> It is the Realm that enforces the security constraints defined in
> web.xml. This includes both authorisation constraints and user data
> constraints. Forcing the use of TLS is a user data constraint. Hence the
> ability to configure the redirect was added to the Realm implementations.
>
> 
>
>> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
>> comment seems to imply that all Realms
>> have it (transportGuaranteeRedirectStatus)
>
> It is supported for any Realm that extends org.apache.catalina.RealmBase
> which is all the Realms that ship with Tomcat and, I should think, a
> reasonable proportion of the custom Realm implementations as well.
>
> That it was only documented for one Realm was an oversight that I'll
> correct shortly. (Along with the typo in the text.)
>
> 
>
>> In the 'good old days' it was common practice to only switch to https
>> during or after signing in to an application, networks were slow and
>> encryption takes time, now networks are faster and the overhead isn't
>> such an issue. Entire sites now use the https scheme, I know mine
>> does. I can see a situation where, because the mighty Google says it
>> must be so, even an entirely static site with no database and no
>> manager will be served up under https. How is such a site suppose to
>> implement https?
>
> I assume the question here is how to configure the redirect status to
> use when a web application does not configure a Realm.
>
> Whether an application configures a Realm or not, it will have one. If a
> web application does not have a specific Realm configured Tomcat looks
> at the Host and then the Engine. If a Realm is not configured for either
> of these then the Engine will be configured with the NullRealm.
>
> Much like the way Tomcat automatically adds an Authenticator when
> required but the user has to add it explicitly if they want to change
> the default configuration for that Authenticator, the user has to
> explicitly add the NullRealm and configure it if they want to change the
> redirect status when no other Realm is defined.
>
> The NullRealm is currently undocumented. I'll fix that as well.
>
>> FYI I have it in black and white, from a Google webaster forum
>> responder that, in the event of  a tie between two pages in a ranking
>> calculation, the https scheme would produce a ranking signal that
>> would elevate the https page above the non https page in the resulting
>> rankings.
>>
>> Once again this is not intended as criticsm of a dedicated and
>> prolific committer
>
> You stated you think the current solution needs rethinking. You haven't
> proposed an alternative and explained why the alternative is better.

Because I don't presume to have the knowledge of the Tomcat source
code required to make such a statement.
I do have explicit knowledge of a problem that I experienced while
using open source software that you (and others) have written. I
didn't understand the solution due to (apparently) incomplete
documentation. What *exactly* is one supposed to do in this situation.
I may not have the time to contribute source code but it took me a
while to figure out exactly was going on and write a bug report, I
consider this contributing to the project, maybe you don't.

As it happens I did have a possible solution that maintained your
abstraction (Realm) even though the connection between realm and
redirect is *in my opinion* not intuitive and somewhat opaque and that
was to add the required functionality to the Realm base class (if such
an entity exists). Then, by way of an attribute expose that
functionality in your chosen Realm.

This sounds remarkably like the solution you have come up with ...

However I can't get my head around your assertion that forcing the use
of TLS is a 'user data constraint' but it appears that any attempted
discussion of design decisions is considered a criticism at least and
a personal insult at worst so I won't go there.

Thank you for your explanation and I eagerly await the updated documentation.

Lyallex


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

Re: I don't understand a recent change released in Tomcat 7.0.70

[Mark Thomas]

On 24/06/2016 06:30, Lyallex wrote:



> I think the current solution to 59399 need rethinking
> 
> My commercial site has been up for years, there are links dating back
> years that refer to the old http scheme
> I have no control over this, now, whenever I get a hit from an 'old'
> link I need to force the switch to https, lots of sites have this
> probem and need a solution, it has nothing whatsoever to do with
> dabases in any way shape or form.
> 
> So,
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399
> 
> What has the status code returned when switching from http -> https
> got to do with a Realm?

It is the Realm that enforces the security constraints defined in
web.xml. This includes both authorisation constraints and user data
constraints. Forcing the use of TLS is a user data constraint. Hence the
ability to configure the redirect was added to the Realm implementations.



> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your
> comment seems to imply that all Realms
> have it (transportGuaranteeRedirectStatus)

It is supported for any Realm that extends org.apache.catalina.RealmBase
which is all the Realms that ship with Tomcat and, I should think, a
reasonable proportion of the custom Realm implementations as well.

That it was only documented for one Realm was an oversight that I'll
correct shortly. (Along with the typo in the text.)



> In the 'good old days' it was common practice to only switch to https
> during or after signing in to an application, networks were slow and
> encryption takes time, now networks are faster and the overhead isn't
> such an issue. Entire sites now use the https scheme, I know mine
> does. I can see a situation where, because the mighty Google says it
> must be so, even an entirely static site with no database and no
> manager will be served up under https. How is such a site suppose to
> implement https?

I assume the question here is how to configure the redirect status to
use when a web application does not configure a Realm.

Whether an application configures a Realm or not, it will have one. If a
web application does not have a specific Realm configured Tomcat looks
at the Host and then the Engine. If a Realm is not configured for either
of these then the Engine will be configured with the NullRealm.

Much like the way Tomcat automatically adds an Authenticator when
required but the user has to add it explicitly if they want to change
the default configuration for that Authenticator, the user has to
explicitly add the NullRealm and configure it if they want to change the
redirect status when no other Realm is defined.

The NullRealm is currently undocumented. I'll fix that as well.

> FYI I have it in black and white, from a Google webaster forum
> responder that, in the event of  a tie between two pages in a ranking
> calculation, the https scheme would produce a ranking signal that
> would elevate the https page above the non https page in the resulting
> rankings.
> 
> Once again this is not intended as criticsm of a dedicated and
> prolific committer

You stated you think the current solution needs rethinking. You haven't
proposed an alternative and explained why the alternative is better.

Mark


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