This week's book giveaway is in the Java in General forum.
We're giving away four copies of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 and have ishori Sharan & Adam L Davis on-line!
See this thread for details.
Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Data Encryption and J2EE

 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you are using J2EE to present confidential data to a user outside the infranet, isn't there a greater chance that that data could be "snooped" than if you sent the same data encrypted and decrypted it in a client side component?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cindy Glass:
If you are using J2EE to present confidential data to a user outside the infranet, isn't there a greater chance that that data could be "snooped" than if you sent the same data encrypted and decrypted it in a client side component?


Sure. If you encrypt, it's more safe. What exactly is your question? I think I missed it.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might be able to tunnel your RPC calls over an SSL connection, or alternatively wrap your confidential data inside a SealedObject. Either would ensure confidentiality.
- Peter
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps it is just that I do not clearly understand what part the Browser plays in the encryption process.
If I display a JSP page in a browser, and the user enters all sorts of confidential information in a text area, the data has to pass from the Browser (which may be in Europe) over to the server (which for us in the the US) before the servlet can process it.
What keeps others from being able to capture that input before it gets to the server? Is there any processing that happens on the BROWSER side before the data is shipped half way around the world??
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cindy Glass:
If I display a JSP page in a browser, and the user enters all sorts of confidential information in a text area, the data has to pass from the Browser (which may be in Europe) over to the server (which for us in the the US) before the servlet can process it.
What keeps others from being able to capture that input before it gets to the server? Is there any processing that happens on the BROWSER side before the data is shipped half way around the world??


If the URL to which the browser is supposed to send the HTML form is labeled with "https://", the browser performs an SSL "handshake" with the target server to authenticate it (to make sure that the server is who it claims to be). After a successful authentication, the browser encrypts the data being sent to the server and pushes it through the network. The web server receives the encrypted data, decrypts it and passes on to the application code for processing.
So your information (the form values) are secured all the way between the browser and the web server.
[ March 20, 2003: Message edited by: Lasse Koskela ]
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK - but if any browser and any server can talk to each other - does that mean that they ALL use the same encryption technique??
Doesn't that mean that someone else could "tap" the line and decrypt it themselves?. Where is the encryption key in all of this?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cindy Glass:
OK - but if any browser and any server can talk to each other - does that mean that they ALL use the same encryption technique??
Doesn't that mean that someone else could "tap" the line and decrypt it themselves?. Where is the encryption key in all of this?


SSL is based on the public/private key concept. Take a look at http://developer.netscape.com/tech/security/ssl/howitworks.html for an explanation of the SSL protocol.
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ahhhh . . . it is all so much more clear now . Thanks.
One security concept down, 99,999 to go .
 
reply
    Bookmark Topic Watch Topic
  • New Topic