tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Morelock <subscripti...@phillipmorelock.com>
Subject Re: Security problem?
Date Fri, 07 Jun 2002 09:18:28 GMT
On 6/7/02 2:14 AM, "Nikola Milutinovic" <Nikola.Milutinovic@ev.co.yu> wrote:

>> On 6/7/02 1:54 AM, "Barney Hamish" <Hamish.Barney@ect-telecoms.de> wrote:
>> 
>>> - the amount of money the user is to pay encrypted with the private key of
>>> site X as a digest.
>>> 
>>> On site Y you recieve both. You decrypt the encrypted amount with site X's
>>> public key. If the clear text amount matches the encrypted amount then you
>>> know the request originates from X and that the user hasn't tampered with
>>> the request. If the amounts differ then you know the user has tampered with
>>> the request and it should be rejected.
>> 
>> Is this backwards?
>> 
>> I thought public keys encrypt and private keys decrypt..
>> 
>> so site X would need to use site Y's public key to encrypt the amount, and
>> site Y would then decrypt it with its private key.  Am I wrong?
> 
> I don't know if I have to say this, but... I believe that with X.509
> certificates there are two courses of action:
> 
> encrypt
> --------
> A public entity uses the certificate (which is publicly available) to encrypt
> an object to the owner of the certificate. Only the owner has the private part
> of the certificate with the private key, which can decrypt the object.
> 
> sign
> ----
> The owner of the certificate ca use the private part of certificate/key to
> digitally sign the object. All public entities, who have that certificate, can
> verify the integrity and authenticity of the object.
> 
> So, what is suggested is that the "shopping cart" server creates the final
> payment report and signs it with it's private key/certificate. The "financial
> transaction" server would verify that *that* is an authentic request from the
> "shopping cart" server.
 
Ok, it was signing.  This still doesn't mean that it's "encrypted" right?
Just that there's a high-tech version of a "checksum" in a sense?  I guess
maybe I don't understand signing.  I thought that signed files were
unencrypted, and that the process of "signing" generates a sort of MD5-style
one-way hash and this is verified against the x.509.  Is this wrong?


> I must say that this is a bit ellaborate. I think that Java Servlet/JSP should
> serve as a "Web portal" towards the Enterprize application. This would be a
> typical case where the application design would benefit from a real JEE
> environment. IOW, there would be no redirection, the "shopping cart" servlet
> would fire up an Enterprize Java Bean component on the "financial transaction"
> server and that EJB would do the work, return the result to the servlet. There
> is no "browser leaving the server", one point of entry.

Yeah -- the redirect thing sounds like a very bad idea.

> Nix.

fillup 


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


Mime
View raw message