Do you have more specific information, since I only know that SSL/IPSec
can be end-to-end in a per link basis, but the idea of a real End-to-End
encryption using SSL, that is the case of Chintan is interesting.
Any link or whitepaper on how to do this in Tomcat as you mention?
Regards,
Juan Carlos
-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]]
On Behalf Of bigbert007
Sent: Martes, 08 de Septiembre de 2009 10:34 p.m.
To: webappsec (at) securityfocus (dot) com [email concealed]
Subject: Re: Securing password between webserver & appserver.
Till - great recommendation, I'll expand on it.
Depending on the back end app server, there is usually a mechanism in
place for creating a trust between the web server and appserver and then
encrypting that connection with SSL. When credentials are entered the
entire pipe is encrypted from the client > webserver > app server based
upon that trust relationship and SSL- encrypted connection
Websphere has this option available as does Tomcat. I suspect that
Coldfusion and other app servers have something similar.
Good luck.
Don
Till Elsner wrote:
> What about securing (i.e. encrypting) the connection between web
> server and app server itself, like connecting to the app server from
> the web server via a SSH-forwarded local port? You could keep the
> original authentication method and have the entire communication
> encrypted anyway.
>
> Greetings
> Till
>
> Am 07.09.2009 um 08:04 schrieb Chintan Oza:
>
>> Dear All,
>>
>> We have a web application which perform user authentication on
>> id+password basis.
>>
>> The architecture is like this.
>> Browser<-HTTPS->WebServer<-->AppServer
>>
>> We have a requirement where password should not be available to the
>> WebServer (even in hashed format).
>>
>> Only solution that I can think of is having an Applet performing PKI
>> encryption on the password before submitting the form.
>>
>> Please suggest if there are any better alternatives.
>>
>> Thanks,
>>
>> Chintan
>>
>>
>
>
>
Do you have more specific information, since I only know that SSL/IPSec
can be end-to-end in a per link basis, but the idea of a real End-to-End
encryption using SSL, that is the case of Chintan is interesting.
Any link or whitepaper on how to do this in Tomcat as you mention?
Regards,
Juan Carlos
-----Original Message-----
From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]]
On Behalf Of bigbert007
Sent: Martes, 08 de Septiembre de 2009 10:34 p.m.
To: webappsec (at) securityfocus (dot) com [email concealed]
Subject: Re: Securing password between webserver & appserver.
Till - great recommendation, I'll expand on it.
Depending on the back end app server, there is usually a mechanism in
place for creating a trust between the web server and appserver and then
encrypting that connection with SSL. When credentials are entered the
entire pipe is encrypted from the client > webserver > app server based
upon that trust relationship and SSL- encrypted connection
Websphere has this option available as does Tomcat. I suspect that
Coldfusion and other app servers have something similar.
Good luck.
Don
Till Elsner wrote:
> What about securing (i.e. encrypting) the connection between web
> server and app server itself, like connecting to the app server from
> the web server via a SSH-forwarded local port? You could keep the
> original authentication method and have the entire communication
> encrypted anyway.
>
> Greetings
> Till
>
> Am 07.09.2009 um 08:04 schrieb Chintan Oza:
>
>> Dear All,
>>
>> We have a web application which perform user authentication on
>> id+password basis.
>>
>> The architecture is like this.
>> Browser<-HTTPS->WebServer<-->AppServer
>>
>> We have a requirement where password should not be available to the
>> WebServer (even in hashed format).
>>
>> Only solution that I can think of is having an Applet performing PKI
>> encryption on the password before submitting the form.
>>
>> Please suggest if there are any better alternatives.
>>
>> Thanks,
>>
>> Chintan
>>
>>
>
>
>
[ reply ]