Networking and Internet security has become an important issue in the Industry Automation. This blog takes three very basic terminologies which are used by us in routine.
Socket
A socket is the endpoint of a connection over a TCP/IP network, much like a phone is the endpoint of a connection in the telephone network. A socket is the combination of a TCP port and an IP address. Ports are logical interfaces for applications, and they are assigned numbers. For example, The Web’s HTTP protocol is located at port 80. Using the telephone analogy, the TCP port is then like a telephone number and the IP address is the location of the phone. A socket is like a phone that has been assigned a phone number. However, a typical host can have many sockets active at the same time (multiplexing). A socket is created during a connection setup between two systems when a process makes a request to a remote machine to open a connection at a specific port. Once the connection is set up, data transfers can begin. Sockets are the main abstraction of the socket interface, which was originally developed in the Berkeley implementation of UNIX. The socket interface is an API, and a socket is the place where an application process makes a connection to some other process over a network.
Socks
SOCKS is a circuit-level proxy gateway that provides security based on sessions (i.e., at the TCP layer). It provides a secure channel between two TCP/IP hosts—a SOCKS-enabled client on the internal network and an outside Web server. SOCKS provides firewall services, as well as auditing, management, fault tolerance, and other features. With SOCKS in place, an internal corporate network can be connected to the Internet in a way that allows internal users to access servers on the Internet while providing firewall protection against outside intruders. NEC Corporation has promoted SOCKS. When a client needs to contact a Web server on the Internet, the request is intercepted by the SOCKS server. The SOCKS server relays this request to the target Web server. It may first evaluate whether the request is allowed based on predefined policies. When the response arrives from the Web server, the SOCKS server evaluates the packet before relaying it to the internal client. Thus, the SOCKS server can collect, audit, screen, filter, and control data flowing in and out of the network. SOCKS also provides the foundation for other critical networking services such as security, management, auditing, and accounting.
Secure Socket Layer (SSL)
SSL was originally developed by Netscape, then submitted to the IETF (Internet Engineering Task Force) for standardization. There are several versions of SSL, and two look-alike protocols. Microsoft considered the original SSL protocol to be lacking in some security features, so it created PCT (Private Communication Technology). Later, Netscape and others created SSL 3.0 to include the features Microsoft added. Now SSL 3.0 is the most common protocol. Another related protocol is Secure HTTP.
When Netscape originally designed SSL, it was meant to secure credit card transactions over the Internet, but the protocol became popular for securing Web connections in general. A typical configuration might consist of Web clients accessing Web servers using SSL and the Web servers accessing back-end databases and application servers using IPSec.
SSL benefits electronic commerce and other Web communications by protecting data in transit from eavesdroppers and tampering. With SSL, browsers and servers can authenticate one another, then encrypt data transmitted during a session. SSL (and PCT) provide the following services:
i) Authentication: Clients can verify that a server is authentic (and not a fake) by checking the server’s certificate and verifying it with the public key of the certifying authority that issued the certificate. The server can authenticate the client in the same way if the client has a certificate (this is optional in SSL).
ii) Confidentiality: A session key is created that both client and server use to encrypt exchanged data.
iii) Integrity Messages may be individually signed (using hash routines) to ensure that they are authentic and have not been altered during transit. The hash creates a unique message digest that is sent with transmitted data and verified by the receiver. Signing also prevents the sender from repudiating the message (denying having sent it).
SSL relies on digital certificates, which combine a public key with the credentials of the person, company, or server to which that key belongs. Certification authorities (CAs) issue certificates, signing them with their own private keys so that certificates may be authenticated. SSL requires that Web servers have certificates. When a user connects to the Web server, the server sends the user its certificate. The user can verify that the certificate is authentic (this is usually handled automatically in the background). Once verified, the public key in the certificate is used to encrypt messages that only the server can decrypt with its private key.
Note that a certificate is “bound” to a Web site. In other words, the certificate says that it works only at a particular IP address (or range of addresses). The idea is that the client must know they are connected to an authentic Web site and not a spoof of that site. The certificate binds a public key with a named entity. This same certificate can be bound to a particular Web site, so if someone steals the certificate and tries to set up a new Web site, that Web site must have an IP address that is already assigned to the real site—and an error would occur if the hacker attempted to do so.
Microsoft Windows 2000 supports SSL public-key certificate authentication. Certificates may be conveniently stored in Microsoft’s Active Directory by mapping certificates to existing accounts. After a user has been identified via their certificate and public key, the server still needs to determine the client’s access rights on the system. This can come from the Active Directory, but may also be defined in the client’s certificate as a mapping that determines authorization to resources