Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Sun, 21 Nov 2004 02:57:30 -0600
From: erh@swapsimple.com
To: tomcat-user@jakarta.apache.org
Subject: Re: SSL and form-based login
Message-ID: <20041121085730.GA25820@poe.swapsimple.com>
References: <20041121005931.91819.qmail@web60603.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041121005931.91819.qmail@web60603.mail.yahoo.com>
User-Agent: Mutt/1.4.2.1i

On Sat, Nov 20, 2004 at 04:59:31PM -0800, footh wrote:
> SSL seems to be working fine, however, I don't believe
> the login page is using SSL.  The reason being is,
> when I try to hit any other page on the site with SSL,
> my browser invokes the certificate dialog box. 
> However, when the form-based login forces the redirect
> to my custom login page, I don't get the certificate
> dialog box.  Here's a snippet the relevant parts of
> web.xml (sorry if the formatting is bad):

	Does your browser url say https?  If so, it should be in 
secure mode.  Are you sure you didn't already accept the
certificate during your browser session?  Try sniffing your
network traffic to make sure though.

> However, all these types of posts seem to be several
> years old.  Is this still a bad idea...to switch from
> https to http?

	That depends on what you're trying to guarantee.
	If you're just trying to protect the password information that is
entered during login, then switching back to http is ok.

	However, since the subsequent traffic is unencrypted an attacker could
observe the sessionid that is used and hijack the session, often without
any immediate indication of a problem from the user's point of view.
	If you're paranoid you'll want to do things like make sure a _new_
sessionid is created once you jump into https mode, and cause any non-https
access using that new sessionid to instantly invalidate the session.
(although as soon as there's any non-encrypted access with a given
sessionid the attacker can theoretically race your session-killing request
and create some havoc)

	For the slightly less paranoid, identifying the sensitive portions
of your application and gating them with another https enabled password
page might be reasonable.

	It all depends on how worried you are and how much effort you
think someone will put into circumventing your security.  

eric

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org