When you tell a J2EE Container that you want to implement data confidentiality and/or integrity, the J2EE spec guarantees that the data to be transmitted will travel over a “protected transport layer connection”. In other words, Containers are not required to use any specific protocol to handle secure transmissions, but in practice they nearly all use HTTPS over SSL.
HTTP request—not secured
The Bad Eavesdropper gets a copy of the HTTP request that contains the client’s credit card info. The data isn’t protected, so it comes over in the body of the POST in a nice readable form. The Eavesdropper is happy.
A secured HTTPS over SSL request
The Bad Eavesdropper gets a copy of the HTTP request that contains the client’s credit card info.
But because it was sent with extra-strength HTTPS over SSL, he CANNOT read the information !!
Sharpen your pencil
Think about what’s been covered in this chapter. If your web application is going to be fast, efficient and secure, you’ve got some questions to answer... (there are no answers for this one; it’s for you to figure out).
Do you need for every request and response to be secure? If not, which parts of your app need protected transmissions? | ______________________________ |
What do you think data confidentiality means? | ______________________________ |
What do you think data integrity means? | ______________________________ |
If you could apply transmission security measures to only some requests and responses, how would you want to tell the Container which requests and responses? | ______________________________ |
______________________________ | |
Can you think of any other DD elements that work on the same level of granularity that you want for declaring protected transmissions? | ______________________________ |