RE: SSL just for a login page

[Craig R. McClanahan]

On Fri, 9 Aug 2002, Drinkwater, GJ (Glen) wrote:

> Date: Fri, 9 Aug 2002 14:51:32 +0100
> From: "Drinkwater, GJ (Glen)" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> Subject: RE: SSL just for a login page
>
> Hi
>
> I am not am expert in the security of the web at the moment.
> Could you explain to me why this would open such a big secuirty hole from
> swapping from https to https.
>

Switching from "http" to "https" is not the problem.  Switching back is.

> I was suggesting this because it read this i a 'professional j2ee' book?!!
>
> The problem i have is that i need the username and password to be encrypted
> but i have heard that ssl hits performance quite badly!!  I dont think that
> i could handle filtering, so what do you suggest for the security??
>
> What is the 'norm' for these such problems.
>

On an "http" connection, anyone who has access to the physical network can
snoop packets and see what is going on.  That's why you're trying to
encrypt the username and password in the first place, right?

The problem is that username/password is not the only sensitive
information going back and forth -- the session identifier is also passed
up to the server on each request, either in a cookie or as part of the
URLs.  This is how the server knows that a subsequent request belongs to
the logged-in user.  Anyone who knows the session id can impersonate the
logged on user, and do anything that user is allowed to do.

If you switch back to "http" after logging in, that means the session id
will get transmitted in cleartext (and, no, there's nothing you can do to
encrypt *just* that).  Therefore, any snooper on the network can see this
session id and start submitting their own requests with that session id.
The server thinks that you've already authenticated, so it lets you do
whatever you want.

All the snooper has to do is wait for someone to log on, observe their
next submit to the server, and snarf the session id ...

The bottom line is that using SSL only for the username/password is a
total waste of time from a security perspective.  If you're not going to
encrypt the entire conversation (which includes the session ids), don't
even bother trying -- you will only get the illusion (or should I say,
*delusion*) of being more secure.  In reality, you'd accomplish
nothing useful.

A more general statement of the principle:  once you switch a session from
"http" to "https", you should never again accept a non-https request for
that same session.  Applications that don't obey this rule are hopelessly
insecure, and should be avoided like the plague.

> Thanks Glen.
>

Craig McClanahan


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL just for a login page

[Anderson, Richard D ERDC-ITL-MS Contractor]

i'm using j2sdk1.4.0_01 for linux, and you have to set JAVA_HOME in your
PATH.  now i do know that javac automatically sets the classpath to the
location of the tools.jar file located in /lib 

-Original Message-
From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 09, 2002 10:26 AM
To: 'Tomcat Users List'
Subject: RE: SSL just for a login page


just downloaded it version 1.7 using it with java 1.4 beta

installation says that you dont need to do anything (already got JAVA_HOME),
when i run it it just pulls up errors??


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL just for a login page

[Durham David Cntr 805CSS/SCBE]

post this on the jmeter-user list

> -Original Message-
> From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 10:26 AM
> To: 'Tomcat Users List'
> Subject: RE: SSL just for a login page
> 
> 
> just downloaded it version 1.7 using it with java 1.4 beta
> 
> installation says that you dont need to do anything (already 
> got JAVA_HOME),
> when i run it it just pulls up errors??
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL just for a login page

[Drinkwater, GJ (Glen)]

just downloaded it version 1.7 using it with java 1.4 beta

installation says that you dont need to do anything (already got JAVA_HOME),
when i run it it just pulls up errors??


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL just for a login page

[Richard Plukker]

For stress testing use Apache JMeter.
good luck Richard


Drinkwater, GJ (Glen) wrote:

>Yes, you are probably right, I will have to use ssl.
>
>Does anybody know of some good stress testing free software???
>
>How does this sound.
>
>1)User logs on and username and password send over ssl. password md5 hashed
>and compared against users on a database.
>2)If valid user logs on, if not user sent to error page.
>3) rest of session ssl.
>
>if database compromised, hash value would be no use???
>
>Lastly, how do i enforce that the whole of the web site must be over ssl,
>except the initial welcome page so the user doesn't have to type in port
>numbers
>
>is it something like this in the web.xml file.
>
>  
>   
>   ***
>   /index.html
>   
>   
>   NONE
>   
>
>
>  
>   
>   ***
>   /*  //or will this overwrite the
>index.html
>   
>   /*jsp //should it be like this
>   /data/*
>   /etc/*   //etc
>   GET
>   POST
>   
>   
>   CONFIDENTIAL
>   
> 
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SSL just for a login page

[Durham David Cntr 805CSS/SCBE]

jmeter, available from jakarta.apache.org

> -Original Message-
> From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 9:59 AM
> To: 'Tomcat Users List'
> Subject: RE: SSL just for a login page
> 
> 
> Yes, you are probably right, I will have to use ssl.
> 
> Does anybody know of some good stress testing free software???
> 
> How does this sound.
> 
> 1)User logs on and username and password send over ssl. 
> password md5 hashed
> and compared against users on a database.
> 2)If valid user logs on, if not user sent to error page.
> 3) rest of session ssl.
> 
> if database compromised, hash value would be no use???
> 
> Lastly, how do i enforce that the whole of the web site must 
> be over ssl,
> except the initial welcome page so the user doesn't have to 
> type in port
> numbers
> 
> is it something like this in the web.xml file.
> 
>  
>   
>   ***
>   /index.html
>   
>   
>   NONE
>   
> 
> 
>  
>   
>   ***
>   /*  //or will this 
> overwrite the
> index.html
>   
>   /*jsp //should it be 
> like this
>   /data/*
>   /etc/*   //etc
>   GET
>   POST
>   
>   
>   CONFIDENTIAL
>   
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: SSL just for a login page

[Jose Francisco Junior]

And what happens with the user session ??? Every single
 page a verify if the user session is Ok, if not I have to
 redirect him to the login page. But if I do what you are
 saying I will lost the user session.

Junior

On Fri, 9 Aug 2002 09:08:22 -0500
"Durham David Cntr 805CSS/SCBE"
 <[EMAIL PROTECTED]> wrote:
>Why don't you just build your redirect after they log in.
>  
>
>   response.sendRedirect("http://"; + request.getHostName() +
> "/myApp/home.jsp");
>
>
>
>
>> -Original Message-
>> From: Drinkwater, GJ (Glen)
> [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, August 09, 2002 8:52 AM
>> To: 'Tomcat Users List'
>> Subject: RE: SSL just for a login page
>> 
>> 
>> Hi
>> 
>> I am not am expert in the security of the web at the
> moment. 
>> Could you explain to me why this would open such a big 
>> secuirty hole from
>> swapping from https to https.
>> 
>> I was suggesting this because it read this i a
> 'professional 
>> j2ee' book?!! 
>> 
>> The problem i have is that i need the username and
> password 
>> to be encrypted
>> but i have heard that ssl hits performance quite badly!!
>  I 
>> dont think that
>> i could handle filtering, so what do you suggest for the
> security??
>> 
>> What is the 'norm' for these such problems.
>> 
>> Thanks Glen. 
>> 
>> 
>> --
>> To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:
>   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>

-
Prefiro as lágrimas da derrota
do que a vergonha de não ter lutado... 

Willan Brook
-

Don't E-Mail, ZipMail! http://www.zipmail.com/

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL just for a login page

[Drinkwater, GJ (Glen)]

Yes, you are probably right, I will have to use ssl.

Does anybody know of some good stress testing free software???

How does this sound.

1)User logs on and username and password send over ssl. password md5 hashed
and compared against users on a database.
2)If valid user logs on, if not user sent to error page.
3) rest of session ssl.

if database compromised, hash value would be no use???

Lastly, how do i enforce that the whole of the web site must be over ssl,
except the initial welcome page so the user doesn't have to type in port
numbers

is it something like this in the web.xml file.

   

***
/index.html


NONE



   

***
/*  //or will this overwrite the
index.html

/*jsp //should it be like this
/data/*
/etc/*   //etc
GET
POST


CONFIDENTIAL

  



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SSL just for a login page

[peter lin]

what's to stop a hacker from stealing the session, then going to the
user profile page and looking at the password? Of course if you do pass
the user to http from https, you can still require profile management go
through https, or simply never print the password to the browser.

I personally wouldn't want to use a insecure site for anything with
personal information.  as others have said, you have to weigh the cost
vs advantage of tight security. if you're prohibited by cost, ie paying
for cert, and hardware, then you really don't have a choice.


peter


Durham David Cntr 805CSS/SCBE wrote:
> 
> Like I said, you're session is open to snooping and hijacking, but your password is 
>not revealed.
>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SSL just for a login page

[Durham David Cntr 805CSS/SCBE]

Like I said, you're session is open to snooping and hijacking, but your password is 
not revealed.

> -Original Message-
> From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 9:38 AM
> To: Tomcat Users List
> Subject: AW: SSL just for a login page
> 
> 
> That's no solution, as now the oneway hash can be snooped
> and hijacked. You win absolutly nothing but wasted efford.
> 
> > -Ursprüngliche Nachricht-
> > Von: Durham David Cntr 805CSS/SCBE 
> [mailto:[EMAIL PROTECTED]]
> > Gesendet: Freitag, 9. August 2002 16:30
> > An: Tomcat Users List
> > Betreff: RE: SSL just for a login page
> > 
> > 2) After a successful login, (still ssl, don't put anything 
> > session yet) pass the user's ID and a one-way hashed version 
> > of their password to a non ssl page that authenticates this 
> > information and sets up their session.
> > 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: SSL just for a login page

[Ralph Einfeldt]

Yes, I know, if you spend some more effort,
you get a bit more security.
(- define a time window where the code is valid)
(- make the client IP part of the hashcode)

But in the end all variants are less secure 
than https.

> -Ursprüngliche Nachricht-
> Von: Ralph Einfeldt 
> Gesendet: Freitag, 9. August 2002 16:38
> An: Tomcat Users List
> Betreff: AW: SSL just for a login page
> 
> 
> That's no solution, as now the oneway hash can be snooped
> and hijacked. You win absolutly nothing but wasted efford.
> 
> > -Ursprüngliche Nachricht-
> > Von: Durham David Cntr 805CSS/SCBE 
> [mailto:[EMAIL PROTECTED]]
> > Gesendet: Freitag, 9. August 2002 16:30
> > An: Tomcat Users List
> > Betreff: RE: SSL just for a login page
> > 
> > 2) After a successful login, (still ssl, don't put anything 
> > session yet) pass the user's ID and a one-way hashed version 
> > of their password to a non ssl page that authenticates this 
> > information and sets up their session.
> > 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: SSL just for a login page

[Ralph Einfeldt]

If you switch from HTTPs to HTTP and keep the session,
that means that now the sessionid is send unencrypted
(either as cookie or as part of the url). So now everybody
who can listen to your traffic, can take that data and steel
the session and act as the owner of the session, and there 
is nothing you can do about it.

Yes SSL has some effect on the performance, but to really
feal it, you must get a high load on the server. In typical 
applications the main load comes from other hot spots.
The higher the needed tranfer rate is the higher will the 
risk be that you experience some penalties, but I think
it's cheaper to solve them by scaling the hardware.

I think you should stresstest your application with both
protocols and judge on your own, what impact HTTPs has 
and what you are willing to invest (in work or hardware)
to reduce the impact.

> -Ursprüngliche Nachricht-
> Von: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 9. August 2002 15:52
> An: 'Tomcat Users List'
> Betreff: RE: SSL just for a login page
> 
> 
> Could you explain to me why this would open such a big 
> secuirty hole from swapping from https to https.
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

AW: SSL just for a login page

[Ralph Einfeldt]

That's no solution, as now the oneway hash can be snooped
and hijacked. You win absolutly nothing but wasted efford.

> -Ursprüngliche Nachricht-
> Von: Durham David Cntr 805CSS/SCBE [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 9. August 2002 16:30
> An: Tomcat Users List
> Betreff: RE: SSL just for a login page
> 
> 2) After a successful login, (still ssl, don't put anything 
> session yet) pass the user's ID and a one-way hashed version 
> of their password to a non ssl page that authenticates this 
> information and sets up their session.
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: SSL just for a login page

[Durham David Cntr 805CSS/SCBE]

Well, obviously the only thing being protected here is the login and password, user 
activity after the login will be open to snooping, hijacking, etc.  So here's what I 
think you should do.

1) User logs in through ssl.

2) After a successful login, (still ssl, don't put anything session yet) pass the 
user's ID and a one-way hashed version of their password to a non ssl page that 
authenticates this information and sets up their session.

Dave

> -Original Message-
> From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 9:19 AM
> To: 'Tomcat Users List'
> Subject: RE: SSL just for a login page
> 
> 
> Hi
> 
> Let me reply to a few of the emails.
> 
> >>the problem is your own encryption isn't signed by a third 
> party, which
> >>means if someone hack into your server, they could compromise the
> >>security.
> 
> wouldn't this still be a problem if my public key was signed by a CA??
> isn't the cert. for the client to verify who i am, this would 
> not effect the
> SSL encryption??
> 
> 
> >>Why don't you just build your redirect after they log in.  
> >>
> >>response.sendRedirect("http://"; + request.getHostName() +
> "/myApp/home.jsp");
> 
> i have tried this.  What i am doing is using the login to set 
> up a session
> and adding a attribute to this session.  Every jsp checks the 
> session for
> this object to verify that the user has logged in, if they 
> have not or they
> have logged out the user is unable to bookmark or go backward into the
> website.  Using the redirect like this some how interferes 
> with the session
> and messes up the checking.  I am not sure why this happens?
> 


> 
> Glen
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: SSL just for a login page

[peter lin]

"Drinkwater, GJ (Glen)" wrote:
> 
> Hi
> 
> Let me reply to a few of the emails.
> 
> >>the problem is your own encryption isn't signed by a third party, which
> >>means if someone hack into your server, they could compromise the
> >>security.
> 
> wouldn't this still be a problem if my public key was signed by a CA??
> isn't the cert. for the client to verify who i am, this would not effect the
> SSL encryption??
> 

For more details on SSL, here's the spec.
http://wp.netscape.com/eng/ssl3/draft302.txt

Remember that using SSL include a lot than just encrypting data. It
includes establishing secure session, cert management and other
processes.  In theory, if a hacker compromises your server they can
break both a custom encryption ans ssl. But breaking SSL is harder than
just decompiling java code to see which algo/padding/key scheme you are
using. Whereas breaking SSL would require much more work.

In reality, a hacker would more likely break into your database than
mess with decompiling your code. Casual hackers will be discouraged by
SSL. Hardcore hackers are hard to protect against. good luck with what
ever you choose.


peter

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SSL just for a login page

[Drinkwater, GJ (Glen)]

Hi

Let me reply to a few of the emails.

>>the problem is your own encryption isn't signed by a third party, which
>>means if someone hack into your server, they could compromise the
>>security.

wouldn't this still be a problem if my public key was signed by a CA??
isn't the cert. for the client to verify who i am, this would not effect the
SSL encryption??


>>Why don't you just build your redirect after they log in.  
>>
>>  response.sendRedirect("http://"; + request.getHostName() +
"/myApp/home.jsp");

i have tried this.  What i am doing is using the login to set up a session
and adding a attribute to this session.  Every jsp checks the session for
this object to verify that the user has logged in, if they have not or they
have logged out the user is unable to bookmark or go backward into the
website.  Using the redirect like this some how interferes with the session
and messes up the checking.  I am not sure why this happens?


Glen


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SSL just for a login page

[Durham David Cntr 805CSS/SCBE]

Why don't you just build your redirect after they log in.  

response.sendRedirect("http://"; + request.getHostName() + "/myApp/home.jsp");




> -Original Message-
> From: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 8:52 AM
> To: 'Tomcat Users List'
> Subject: RE: SSL just for a login page
> 
> 
> Hi
> 
> I am not am expert in the security of the web at the moment. 
> Could you explain to me why this would open such a big 
> secuirty hole from
> swapping from https to https.
> 
> I was suggesting this because it read this i a 'professional 
> j2ee' book?!! 
> 
> The problem i have is that i need the username and password 
> to be encrypted
> but i have heard that ssl hits performance quite badly!!  I 
> dont think that
> i could handle filtering, so what do you suggest for the security??
> 
> What is the 'norm' for these such problems.
> 
> Thanks Glen. 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: SSL just for a login page

[peter lin]

the problem is your own encryption isn't signed by a third party, which
means if someone hack into your server, they could compromise the
security.

Hackers are smart and have tons of free time. If there's a hole, it will
be found and exploited.

Most big e-comm sites use hardware acceleration to improve the
performance. If you're going to handle moderate SSL traffic, you should
get hardware acceleration that sits between the webservers and the
browser. Look at BigIP, network SSL modules or other hardware solutions.

there are companies selling ssl ethernet cards for systems if you don't
need heavy duty SSL.

peter lin


"Drinkwater, GJ (Glen)" wrote:
> 
> Hi
> 
> I am not am expert in the security of the web at the moment.
> Could you explain to me why this would open such a big secuirty hole from
> swapping from https to https.
> 
> I was suggesting this because it read this i a 'professional j2ee' book?!!
> 
> The problem i have is that i need the username and password to be encrypted
> but i have heard that ssl hits performance quite badly!!  I dont think that
> i could handle filtering, so what do you suggest for the security??
> 
> What is the 'norm' for these such problems.
> 
> Thanks Glen.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: SSL just for a login page

[Drinkwater, GJ (Glen)]

Hi

I am not am expert in the security of the web at the moment. 
Could you explain to me why this would open such a big secuirty hole from
swapping from https to https.

I was suggesting this because it read this i a 'professional j2ee' book?!! 

The problem i have is that i need the username and password to be encrypted
but i have heard that ssl hits performance quite badly!!  I dont think that
i could handle filtering, so what do you suggest for the security??

What is the 'norm' for these such problems.

Thanks Glen. 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: SSL just for a login page

[Ralph Einfeldt]

Don't do it.

It has been pointed out several times that it is 
not recommanded to switch from https to http and
stay in the same session. That would open a 
!!!BIG!!! security hole.

If you really know what you are doing, you can write
a filter that redirects every request that came in  
over HTTPS (except the ones for your login pages) 
to HTTP.

> -Ursprüngliche Nachricht-
> Von: Drinkwater, GJ (Glen) [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 9. August 2002 15:11
> An: '[EMAIL PROTECTED]'
> Betreff: SSL just for a login page
> 
> initial login page which sends the username and password to a 
> servlet that checks them against a database.  I want to have 
> the informatin sent over ssl but then i want the user to be sent

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

SSL just for a login page

[Drinkwater, GJ (Glen)]

Hi

I have been working with tomcat with a web site.  There is a initial login
page which sends the username and password to a servlet that checks them
against a database.  I want to have the informatin sent over ssl but then i
want the user to be sent back to a none ssl page for the rest of the
session.  With out explicitly calling https:// and http:// within the
redirects (ie i want all locations relative) how do i canfigure tomcat.  I
have configured it to the login page is on ssl but when the servlet sends
the user back to a page that page is also ssl.

I have added this to my web.xml file

   

DataPortal
/*


NONE



   

DataPortal
/Login.html
/servlet/LoginServlet
GET


CONFIDENTIAL

  


Also the second problem when i take off the Login page and off the
CONFIDENTIAL section so a person goes to the login page and then enters the
username and password, the information is sent to the server over ssl but my
LoginServlet code cannot pick out the parameters passed to it???

Can anybosy help me with this


Thanks glen

--
To unsubscribe, e-mail:   
For additional commands, e-mail: