|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Many Web applications, especially those deployed for e-commerce, necessitate the transmission of sensitive data between the Web server and the client browser. This data could include passwords, credit card numbers, or bank account numbers -- any information users would not want divulged to the general public. To protect sensitive data during transmission, developers at Netscape Communications created Secure Sockets Layer (SSL) and its companion protocol, HTTP over Secure Sockets Layer (HTTPS). HTTPS employs SSL to protect data by encrypting it at the source, be it the server or the client, and decrypting it at the destination, thus preventing anyone monitoring Internet data transmissions from easily capturing this data. The client and server exchange public keys to enable encryption and decryption.
The encryption/decryption process comes at a performance price, however. Data throughput for a Web server transmitting via HTTPS is often as little as one-tenth that of data transmission via HTTP. For this reason, you shouldn't deploy an entire Web application under SSL. For fastest performance, deploy a Web application under HTTP and employ HTTPS only for those pages and processes that transmit sensitive data. In this article, I propose and develop a solution for implementing this protocol mixture.
Perhaps the most prevalent approach for integrating SSL into a Web application is to specify the entire URL, including the HTTPS protocol, in those hyperlinks that lead to Webpages or servlets requiring HTTPS. This leads to HTML code like the following snippet from a page not requiring SSL:
<a href="../nonssl/insecurePage.jsp">Non-SSL link</a> <a href="https://www.somedomain.com/ssl/securePage.jsp">SSL Link</a>
Similarly, pages requiring HTTPS should specify the HTTP protocol in hyperlinks that lead to pages or servlets that do not require the extra data protection. The following HTML would come from a page requiring SSL:
<a href="http://www.somedomain.com/nonssl/insecurePage.jsp">Non-SSL link</a> <a href="../ssl/securePage.jsp">SSL Link</a>
One advantage to this method: you can easily implement it during development. You need no mechanism beyond what basic HTML provides.
As is often the case, what proves easy to implement during development turns into a maintenance problem in production. Changing the protocol for any particular Webpage or servlet requires that you find and edit all links to that page or servlet to specify the new protocol. For portability reasons, you should specify hyperlinks in a fashion relative to a common directory or root context. Forcing the entire URL specification in hyperlinks creates a maintenance problem when the application moves from development to deployment, or any time the domain name or root context changes.
The biggest problem with the static link implementation is that nothing prevents a user from specifying the wrong protocol by manually entering a URL into the browser. The penalty for manually specifying HTTPS for a page or servlet not requiring HTTPS: reduced performance. Far worse is the penalty for manually specifying HTTP for nonsecure access of a page that does require HTTPS: sensitive data exposure.