SSL is the abbreviation for Secure Socket Layer. With layers, the transport layers are addressed, with which the data exchange between two computers is represented pictorially. At the top level, the applications are arranged. At the bottom of the model is the hardware. Ideally, seven layers can be defined, to which, in the ideal case, a protocol or program can be assigned. All layers help to ensure the flow of data between the two computers.
In real life, the model does not always fit so ideally. The transmission protocol TCP / IP covers at least four layers with its two components (TCP and IP). The protocol is a kind of Esperanto in the computer world. With the exception of the Zuse computers, all computers and operating systems support TCP / IP (resourceful inventors have even taught the ZX81 TCP / IP). It’s easy to implement, robust and secure – reliable. When TCP / IP was invented nearly 30 years ago, the main focus was on creating a fail-safe and stable connection with high operational reliability. The security and authenticity of the transmitted data played a subordinate role.
With TCP / IP the desire for secure connections in the sense of data security could not be realized. Without TCP / IP there is no internet. The company Netscape solved the problem in the following elegant way: The developers extended TCP / IP by two further layers.
SSL record protocol
SSL Handshake Protocol
This explains the term “layer”; They are functionally between the task area of TCP / IP and the applications. These two layers are metaphorically in direct contact with each other and are therefore addressed by some authors as a single layer. Although all sorts of software know-how rages in these two layers during a secure connection, it is transparent to the adjacent layers: neither the application (the browser nor the transport layer below the SLL protocol notice the effect of the SLL protocol In plain language: SSL requires neither changes to existing applications nor new transport protocols.
During a secure connection, the computers involved only communicate through the mechanism provided by SSL. If the secure connection is not available, the SSL protocol turns off.
At the heart of the SSL protocol are the digital public / private key pair of the server and the ID of the certification authority. Each virtual web server requires its own key pair because the ID includes, among other things, the domain name. Every SSL-protected homepage requires its own IP address. Providers who operate thousands and thousands of sites on their servers on a single machine and under a single IP address must, therefore, fit in with the provision of an SSL certificate or resort to technical aids.
This is how the trick works: The visitor’s browser does not connect to the actual order page but to a special server (SSL proxy) of the provider. Only then will the connection be secured. The proxy server then forwards the information of the visitor to the actual destination, for example an order page. Forwarding from the SSL proxy to the order page is then no longer secure. This can already mean a loss of security if in the network of the provider many customer servers are housed, which may listen to the now unprotected data stream.
What is not secured:
The SSL protocol secures the transfer between a domain on a web server and the visitor of that domain. The on-line customer (visitor) can be fairly sure that his credit card number on the way from his computer to the server of the shop owner is protected against exploration. What then continues to happen with the securely transmitted data is beyond what is regulated by the SSL protocol. For the customer who confides his account information in reliance on the SSL backup, it is not clear how the shop owner processes this information. Cases have become known in which the data processor subsequently stored the backed-up data unsecured on the server. After a successful hacker attack, the sensitive data was suddenly in the wrong hands. We learn from it: SSL-Protects against sloppiness and carelessness.
Online via SSL:
It is safe if the recipient retrieves the data via an SSL-secured connection via the browser or via SSL-secured POP3 retrieval and then deletes it on the server. Whether the recipient of your credit card number really does, he can tell you only. The SSL protocol is only responsible for the delivery of data to the server, not for delivery. This means, however, that the shop owner must be regularly manual. Of course this is a bit impractical and annoying.
It is more convenient if the order with the payment information in a dishwashing by e-mail comes to the office. Many shop owners and other users of SSL-secured data transfer summarize the transmitted data with the other order data to a handy text file that reaches the recipient as an email. It’s like having your valuable cargo made through all the hazards of the world at great expense, then leaving it unguarded in the waiting room of the main train station.
It is better to encrypt the collected information via email before sending it as an email on the server via PGP. The file saved in this way can be safely sent. Nobody, with the exception of the recipient, can read the information. This requires a certain additional effort on the part of the shop provider or the provider. However, this is a one-time process. Ongoing operation is as easy as picking up emails.
Unfortunately, anyone using an SSL-secured transmission for confidential information can not recognize whether the recipient of such data is worth such extra effort. If shop owners are more interested in the security of customer data, they should emphasize this clearly on the homepage. Because the SSL protocol is only half the security. The following rules of thumb provide a first clue as to what security the operator of a website can offer.
Websites that are located on the servers of known mass hosts offer only the use of an SSL proxy because of the common use of IP addresses there. This is an SSL server that is in front of all other websites. The data is only transmitted securely to this server and then passed on to the website unsecured.
As a rule, the ready-to-use shops of the mass-hosters offer the option of querying the data via an SSL-secured web interface or having the information sent to them via SSL-secured e-mail.
Information collected on www.ssl.de is PGP-encrypted to the recipient by default.