Database Reference
In-Depth Information
Visa and Microsoft, major players in the development of SET, have since
provided Secure Transaction Technology (SST). This technology enables bank
payments over the Internet to be secure.
SSL and S-HTTP
Netscape developed the Secure Sockets Layer (SSL) protocol for transmit-
ting private documents over the Internet in a secured manner. Many websites
use this standard to obtain confidential information such as credit card numbers.
The protocol prevents tampering, forgery, and eavesdropping by unauthorized
persons.
SSL is layered between services like FTP, Telnet, and HTTP and the TCP/IP con-
nection sessions. It guarantees a secure connection between a client and a server.
Once a secure connection is established, the server can transmit any amount of
confidential information to the client over the safe connection. SSL verifies that the
client and server networks are valid, provides data encryption using a private key
encryption method, and ensures that the message does not contain any embedded
commands or programs.
Secure HTTP (S-HTTP) offers a different method to transmit data securely from
the server to the client. This protocol, a revised version of HTTP, allows single mes-
sages to be transmitted securely. Enterprise Integration Technologies (EIT) devel-
oped S-HTTP.
SSL and S-HTTP both enable secure transmission of confidential information
over the Internet—SSL establishes a safe connection, and S-HTTP safeguards indi-
vidual messages. Therefore, one method complements the other. In effect, both tech-
nologies offer the following functions:
Enable authentication between a browser and a server
Allow website administrators to control access selectively over specific services
Permit a browser and a server to share confidential information while keeping
others away from the protected transmission
Ensure reliability of transmitted information, preventing accidental interrup-
tion or corruption
Java Security
You know that Java applets, embedded in a web page and transmitted from the Web
server to the browser, execute on the client machine. This is unlike a known program
executing on your computer. As a user on the client machine, you may not know
where the executable code is coming from. Perhaps, if the applet needs local
resources to execute, it will ask for permission through the browser. You may grant
permission or deny permission to execute. But even if you know the source of the
web page containing the applet, you cannot be completely sure. Nevertheless, you
must allow a useful applet to execute and still maintain a level of trust. Network
applications cannot be operational if you unequivocally deny permission to any
outside programs to do useful work on your client machine. This is the crux of Java
security.
Search WWH ::




Custom Search