tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: SSL session attribute
Date Tue, 30 Oct 2001 02:30:26 GMT
Do you think it would make sense to provide a patch along those lines?
Any other opinions from SSL specialist?

It is a bit of a far fetched scenario (although there have been banks
that allowed such blunders), but one could establish a valid session
with TC (over SSL) and then start picking other session ID's until it
gets a valid (another user's) session. Checking the SSL session ID
against TC session ID would prevent such behaviour and kick all such
attempts straight out.

The only detail I'm not 100% sure of is sites that use frames, but since
SSL is a transport layer thing, I'm guessing SSL session ID would be the
same across frames as well.

Bojan

Bill Barker wrote:
> 
> No, it doesn't check.  It is simply there as information for the servlet.
> And actually, it is only even set if you are using Ajp13 or JNI as your
> connector.  The HttpSession identifier is still either the JSESSIONID cookie
> or the ;jsessionid= identifier.
> ----- Original Message -----
> From: "Bojan Smojver" <bojan@binarix.com>
> To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
> Sent: Monday, October 29, 2001 5:59 PM
> Subject: Re: SSL session attribute
> 
> > I checked 2.2 only and couldn't find anything. Google only finds it in
> > TC source.
> >
> > Without going through the source, does TC 3.3 make the effort to check
> > the TC 3.3 session against the SSL session (if it exists) to verify that
> > there is no cheating or is this considered an application issue?
> >
> > Bojan
> >
> > Bill Barker wrote:
> > >
> > > It doesn't seem to be in either the 2.2 or 2.3 spec.
> > > ----- Original Message -----
> > > From: "Bojan Smojver" <bojan@binarix.com>
> > > To: "Tomcat Dev List" <tomcat-dev@jakarta.apache.org>
> > > Sent: Monday, October 29, 2001 5:00 PM
> > > Subject: SSL session attribute
> > >
> > > > Is the request attribute "javax.servlet.request.ssl_session" (in TC
> 3.3)
> > > > a 'standard' attribute that keeps the SSL session ID? Is there a spec
> > > > that defines it?
> > > >
> > > > It seems like an extremely important part of keeping the users from
> > > > bumping into each others TC session 'by accident' (or should I say by
> > > > cracking).
> > > >
> > > > Bojan
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <mailto:tomcat-dev-help@jakarta.apache.org>
> > > >
> > > >
> > >
> > > *----*
> > >
> > > This message is intended only for the use of the person(s) listed above
> > > as the intended recipient(s), and may contain information that is
> > > PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> > > you may not read, copy, or distribute this message or any attachment.
> > > If you received this communication in error, please notify us
> immediately
> > > by e-mail and then delete all copies of this message and any
> attachments.
> > >
> > > In addition you should be aware that ordinary (unencrypted) e-mail sent
> > > through the Internet is not secure. Do not send confidential or
> sensitive
> > > information, such as social security numbers, account numbers, personal
> > > identification numbers and passwords, to us via ordinary (unencrypted)
> > > e-mail.
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:tomcat-dev-help@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:tomcat-dev-help@jakarta.apache.org>
> >
> >
> 
> *----*
> 
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
> 
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message