You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gregor Schneider <rc...@googlemail.com> on 2009/03/10 20:19:37 UTC
j_security_check & SSL
And another one:
AFAIK, when using Form-based Authentication, the parameters for
j_security_check are send in a readable manner over the wire, thus
prone for an attack.
Therefore, it is recommended to use SSL-encription for the Form-Loginpage.
However, that means that one has to buy one of those quite expensive SSL-certs.
Since those pages actually don't need SSL at all except for the
Login-process, is there any way to achieve encryption for the
Login-process without a valid SSL-cert?
Your suggestions very welcome
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Gregor Schneider <rc...@googlemail.com>.
Hi André,
first: Please forgive me my late answer also to your PM, however, I
was really busy here so that I didn't find any time to answer in an
appropriate (aka detailed) manner.
So here we go:
Customers
----------------
When talking about customers, I'm actually talking about our staff
from the business-dept, and I'm talking about external customers.
Since we are a Reinsurer, the external customers are primary insurers
as mots of you guys will have to deal with sooner or later.
If any requirement for a website is suggested, this always comes from
our internal customers
Type of Websites
-------------------------
We have to distinguish between to different types of websites:
Type I:
Are websites open to the public which might be interested in our
products. This contains some data available to the public, plus some
protected contents where only selected propects / customers have
access to.
Currently, those sites are not SSL-encrypted, however, there is AAA
for some content using Form-based login.
Type II:
Are websites accessible to our external worlwide customers
(Life-Insurers) only. Since our clients also might enter data from
their customers (i.e. Life-Insurance-clients from primary insurers),
data always are confidential, thus those sites are always
SSL-encrypted.
Setup
--------
Our current setup for both types is as follows:
- Apache 2.2 in front for static content
- Tomcat 5.5 for dynamic content attached to Apache HTTPD via mod_jk
- For authorization we are using Apache HTTPD's authorization in
combination with mod_auth_cookie_mysql2
(http://home.digithi.de/digithi/dev/mod_auth_cookie_mysql/)
AAA works in such a way, that Apache HTTPD is taking the request,
checks, if it point to protected content, if so, forwards to a
protected Tomcat-hosted JSP.
The JSP is utilizing Tomcat's FORM-Login, and after successful login
writes a Session-cookie into a MySQL-database (among other stuff).
When the next request to a protected content comes to Apache HTTPD,
Apache HTTPD checks wether a certain cookie exists and compares it's
value with the value stored inside the MySQL-database. If found, it's
ok, else it goes back to the Login-Page.
As I said before, we have multiple website all hosted on the same
servers (behind a Loadbalancer).
Role-Based AAA
------------------------
Since some customers do have access to more than one website of ours,
we hvae created a role-based system so that once authorized and
belonging to multiple roles, they don't have to re-login again thanks
to Tomcat's SSO-Valve.
We are using session-cookies timing out after a defined period of
time. They are also invalidated if the brwoser is closed.
Motivation for Setup
----------------------------
We server a lot of static content (html, javascript, pdf), so that we
decided to serve this via Apache HTTPD for performance reasons.
Since for security reasons we didn't want to use PHP for dynamic
content (and since I'm a Java-guy), we opted for JSPs / Servlets for
dynamic content. Since I'm into Opensource and I like Apache Group's
stuff a lot (and for some other reasons), we opted for Tomcat for the
dynamic content.
Problems
--------------
Most of our users are running IE in various versions. Sometimes, some
strange error occurs when instead of dynamic content to be served, the
user just sees a "Page cannot be displayed" error-message.
We checked our logs (Apache HTTPD, Tomcat), alas, to no avail.
However, whene I checked the logs of mod_jk, I found some messages
like this one:
[Fri Mar 13 13:48:22 2009][0869:0000] [info] jk_handler::mod_jk.c
(1971): Aborting connection for worker=wrkr
[Fri Mar 13 13:48:44 2009][20858:0000] [info]
ajp_process_callback::jk_ajp_common.c (1412): Connection aborted or
network problems
[Fri Mar 13 13:48:44 2009][20858:0000] [info]
ajp_service::jk_ajp_common.c (1761): Receiving from tomcat failed,
because of client error without recovery in
send loop 0
Besides, it's quite difficult when a Tomcat session times out:
This has to be propagated to Apache HTTPD, meaning, the cookie-entry
has to be removed from the MySQL-database.
Currently we're achieving this with a SessionListener clearing the
values from the database once a Session gets destroyed.
SSL / Costs
-----------------
Actually the costs of the SSL-certs is not such a big issue (we talk
about 300€ which is an equivalent for 3 hrs work - this is not the
money *I'm* getting but what my company calculates with). It's just
the hazzle getting them via our provider, re-authenticate with the
SSL-provider and so on. It's simply not a smooth process, and that's
why I was looking for an alternate solution.
Current Development
------------------------------
I'm curently porting the first few site into a Tomcat-only-environment
strctly following the KISS-principle: Keep It Simple, Stupid!
I'm testing them now with Tomcat 6 using the APR, thus avoiding all
the hazzle with Apache / mod_jk / Tomcat-connectivity, avoiding the
hazzle with AAA using mod_auth_cookie2 and so on.
Besides, I believe the less components are involved within the serving
of a website, the lower any possible security-issue is.
Whew, that was quite some post, however, I owed you that one and maybe
you guys now have some idea why I'm asking all those questions.
Cheers!
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 3/13/2009 10:38 AM, André Warnier wrote:
> Unless I am mistaken, I don't think that using HTTPS in order to protect
> the user-id/password from eavesdropping by some miscreant, you
> necessarily have to have a Verisign certificate for each site.
Correct. You need to use an SSL cert, but it doesn't need to be signed
by a widely-trusted certificate authority.
> Again unless I am mistaken, a CA-signed certificate is meant to be used
> to reassure the client that he is really talking to the server you say
> you are, and not some other impersonating phishing site.
Again, correct.
> But it is not a prerequisite for simply making a connection through HTTPS.
Right, but it /is/ a prerequisite for most users not getting a scary
"UNTRUSTED SECURITY CERTIFICATE" warning. It's too bad that, with the
introduction of EV certs, the big CAs aren't just giving-away the old
certs. Or, offering a super-low-cost certificate that says "this is
really only good for channel encryption, we didn't do any checking into
the legitimacy of this organization".
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6eHYACgkQ9CaO5/Lv0PC3YQCgtNnSZoK+9MrVZYD5zrfJ65mo
g3kAn0h4yitFysnid4jq6dN70CRC7Ad0
=IsQQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by André Warnier <aw...@ice-sa.com>.
Hi guys. I'm following this loosely, along with some other threads.
There is another one going on right now which also talks about
authentication, hijacking JSESSIONID etc..
Gregor, what is not very clear to me, and maybe you want to do a wrapup,
is what exactly you are - and are not - trying to achieve.
For example, /why/ you want the users to login, and /if/ you want this
one login to be valid for your 4 websites/applications (say "convenience
SSO") or not. And /if/ you want that one user, having logged-in once
today, should be able to re-access the same application later on without
re-logging in, if in the meantime he went to have a long lunch, or
closed his browser etc..
Or if you want a login just to block robots from accessing the site, or
if you want a login just so that you can track a user for reasons of
statistics and so on.
From earlier explanations, it does not seem that you really have any
confidential information to protect, nor that you are too worried about
someone hijacking a user session etc..
And, if you want users to login, how are you giving them a user-id and
password to login ?
I'm just mentioning all this because I generally get the feeling that
you are not too hot on using HTTPS and CA certificates on all these
sites, and maybe you don't really need to, for what you want to achieve.
Unless I am mistaken, I don't think that using HTTPS in order to protect
the user-id/password from eavesdropping by some miscreant, you
necessarily have to have a Verisign certificate for each site.
Again unless I am mistaken, a CA-signed certificate is meant to be used
to reassure the client that he is really talking to the server you say
you are, and not some other impersonating phishing site. But it is not
a prerequisite for simply making a connection through HTTPS.
Or ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 3/13/2009 1:58 PM, Gregor Schneider wrote:
> So will I then be able to access the HttpSession-object created when
> inside HTTPS (login-page) when I'm querying it from within a JSP
> served via plain HTTP?
No, the session will be created in HTTP mode, then you'll submit in
HTTPS mode (and the non-secure session is viewable in the secure
context) and then go back to HTTP mode.
> That was the problem Chuck mentioned, and this I tried to solve with
> my - silly - suggestion from above?
Try creating a sequence of requests that you think are likely, and apply
the rules I laid out to see how the webapp would react. If there's a
case you think won't work, let me know and I'll see if I can come up
with an idea.
> I sees quite some pages using HTTPS for Authorization (Form-based),
> but once authorized, they serve via HTTP.
> How just simply do they do that?
The session is created in HTTP mode which is why this works.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6x/cACgkQ9CaO5/Lv0PD4BQCfcqJdd3wVDn7/YfMtKiMTMMia
0jMAn07FSA6Au3j9ZwWqAhmS10J3uHVu
=ncMM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Gregor Schneider <rc...@googlemail.com>.
Chris,
On Fri, Mar 13, 2009 at 5:14 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gregor,
>
> On 3/13/2009 11:42 AM, Gregor Schneider wrote:
>> So would following scenario work?
>>
>> - login using form-based login via https
>>
>> - when successful:
>> HttpSession session = request.getSession();
>> // guess that shoudln't happen
>> if (session != null) {
>> session.invalidate();
>> }
>> session = request.getSession (true);
>>
>> Looks ok to me - you comments?
>
> I don't see how this could work. Immediately after login you invalidate
> the session, thus logging-out the user.
>
Duuh... you're right: Invalidated the session logs the user out.
> Here's what you want to do:
>
[ snip ]
>
> I think that will make it all work.
>
So will I then be able to access the HttpSession-object created when
inside HTTPS (login-page) when I'm querying it from within a JSP
served via plain HTTP?
That was the problem Chuck mentioned, and this I tried to solve with
my - silly - suggestion from above?
Actually I don't think so.
What I'm just wondering is:
I sees quite some pages using HTTPS for Authorization (Form-based),
but once authorized, they serve via HTTP.
How just simply do they do that?
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 3/13/2009 11:42 AM, Gregor Schneider wrote:
> So would following scenario work?
>
> - login using form-based login via https
>
> - when successful:
> HttpSession session = request.getSession();
> // guess that shoudln't happen
> if (session != null) {
> session.invalidate();
> }
> session = request.getSession (true);
>
> Looks ok to me - you comments?
I don't see how this could work. Immediately after login you invalidate
the session, thus logging-out the user.
Here's what you want to do:
- - Write a filter that intercepts all HTTPS traffic and redirects it to
HTTP. This will make sure that anyone attempting to use HTTPS for the
fun of it will end up seeing a non-secure page. This will not affect
calls to j_security_check.
- - Modify your login page to invalidate the session and redirect to HTTP
if HTTPS is detected. This will expire sessions that are created in
the secure realm in response to deep requests to your webapp (this
handles the case of someone trying to hit /some/secure/place and
Tomcat automatically forwarding to the login page, in HTTPS mode).
I was going to say that you should make sure that your login page forces
a session creation, but Tomcat will already have created your session
before the login page displays. Make sure your login form points to
https://your.server/j_security_check (of course!).
I think that will make it all work.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6hmkACgkQ9CaO5/Lv0PAtfwCdGxR5PFUxNNc+DHtXhEVmBukS
ercAnRdFVf/EAUPr6NfP5xzOGDOw5FUT
=8q9E
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Gregor Schneider <rc...@googlemail.com>.
Chris,
On Fri, Mar 13, 2009 at 3:26 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Just to be clear, it's the session creation that is sensitive to SSL,
> not the actual login (authentication step). If your session exists and
> is visible to non-secure communications before authentication, then it
> will also be so after authentication.
>
Well, I believe this scenario is quite unlikely, since the login-form
(running as https) usually is the first page to be displayed.
Let me twist your words a bit ;)
If the session is created *after* the login-form, that means it's
created while using HTTP, there shouldn't be any problems left except
for the Session-Cookies which might be hijacked, right?
So would following scenario work?
- login using form-based login via https
- when successful:
HttpSession session = request.getSession();
// guess that shoudln't happen
if (session != null) {
session.invalidate();
}
session = request.getSession (true);
Looks ok to me - you comments?
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 3/10/2009 3:24 PM, Caldarale, Charles R wrote:
>> From: Gregor Schneider [mailto:rc46fi@googlemail.com]
>> Subject: j_security_check & SSL
>>
>> is there any way to achieve encryption for the
>> Login-process without a valid SSL-cert?
>
> Note that if the login is performed under HTTPS, the generated
> session is only for HTTPS; falling back to HTTP will result in use of
> a different session object.
Just to be clear, it's the session creation that is sensitive to SSL,
not the actual login (authentication step). If your session exists and
is visible to non-secure communications before authentication, then it
will also be so after authentication.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6bPoACgkQ9CaO5/Lv0PACKQCfRYLd0qS2v84xckUW0Tpk/y2g
+y4AnjJR9ny4mWd7RdBPJjhE8CRS7GXp
=Deaf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: j_security_check & SSL
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Gregor Schneider [mailto:rc46fi@googlemail.com]
> Subject: j_security_check & SSL
>
> is there any way to achieve encryption for the
> Login-process without a valid SSL-cert?
We normally use a self-signed certificate. That does pop up a browser message to that effect, which might scare off clients that haven't been forewarned.
Note that if the login is performed under HTTPS, the generated session is only for HTTPS; falling back to HTTP will result in use of a different session object.
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 3/10/2009 5:44 PM, Gregor Schneider wrote:
> Mark,
>
> On Tue, Mar 10, 2009 at 8:23 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>> Ditch FORM auth, use DIGEST.
>>
> I'm afraid I don't see how to combine DIGEST with a Login-form - and
> that's a customer request.
Then you're out of luck.
The only workarounds I've ever heard are to use some javascript tricks
to hash or encrypt the username and/or password before it's sent to the
server. Of course, this technique actually /reduces/ the security to
zero because either replay attacks are trivial or the encryption keys
are found in the javascript code. Duh.
> I know that SecurityFilter is quite a handy tool, however, that
> doesn't support Tomcat's SSO-functionality yet (?).
Correct. It also doesn't support FORM auth with anything but plaintext
j_password parameters.
> I guess I can live with an unencrypted SessionID since our sites are
> not that important as to expect any session-hijacking (btw., does
> Tomcat check if the SessionID maps to a certain IP?).
No. But securityfilter's cvs head contains a filter that does just that.
You can use it completely independently of securityfilter if you want to
"borrow" it from the project. ;)
> What is important is performance - therefore I tend to not use SSL
> except for the LoginForm.
>
> Looks like we have to get a few certs then.
I would give your customer the choice: no cert (less money) but you have
to use DIGEST auth ; versus use form auth and buy an SSL cert.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkm6bKEACgkQ9CaO5/Lv0PCSigCgu5sIRcpHaR97j2sDDJzHcVz5
4xEAoJE6nrwCHFKEYfCNmeAjnfBJzIer
=D8C3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Gregor Schneider <rc...@googlemail.com>.
Mark,
On Tue, Mar 10, 2009 at 8:23 PM, Mark Thomas <ma...@apache.org> wrote:
>
> Ditch FORM auth, use DIGEST.
>
I'm afraid I don't see how to combine DIGEST with a Login-form - and
that's a customer request.
I know that SecurityFilter is quite a handy tool, however, that
doesn't support Tomcat's SSO-functionality yet (?).
I guess I can live with an unencrypted SessionID since our sites are
not that important as to expect any session-hijacking (btw., does
Tomcat check if the SessionID maps to a certain IP?). What is
important is performance - therefore I tend to not use SSL except for
the LoginForm.
Looks like we have to get a few certs then.
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: j_security_check & SSL
Posted by Mark Thomas <ma...@apache.org>.
Gregor Schneider wrote:
> And another one:
>
> AFAIK, when using Form-based Authentication, the parameters for
> j_security_check are send in a readable manner over the wire, thus
> prone for an attack.
Correct.
> Therefore, it is recommended to use SSL-encription for the Form-Loginpage.
Correct.
> However, that means that one has to buy one of those quite expensive SSL-certs.
Or self-sign but that has other issues.
> Since those pages actually don't need SSL at all except for the
You need to protect the session ID as well so you do need SSL for all those pages.
> Login-process, is there any way to achieve encryption for the
> Login-process without a valid SSL-cert?
Ditch FORM auth, use DIGEST.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org