|
•
|
SSL- Secure Sockets Layer (SSL) is a network security mechanism introduced by Netscape in 1995. SSL was designed “to provide privacy between two communicating applications (a client and a server) and also to authenticate the server, and optionally the client.” SSLs most popular application is HTTPS, designated by a URL beginning with https:// rather than simply http://, and it is recognized as the standard method of encrypting Web traffic on the Internet. An SSL HTTP transfer typically uses TCP port 443, whereas a regular HTTP transfer uses TCP port 80. Although HTTPS is what SSL is best known for, SSL is not limited to securing HTTP, but can also be used to secure other TCP protocols such as SMTP, POP3, IMAP, and LDAP.
|
SSL session establishment occurs as follows:
SSL Session Establishment Communication
|
•
|
SSLv2 – The earliest version of SSL still in common use. SSLv2 was found to have a number of weaknesses, limitations, and theoretical deficiencies (comparatively noted in the SSLv3 entry), and is looked upon with scorn, disdain, and righteous indignation by security purists.
|
|
•
|
SSLv3 – SSLv3 was designed to maintain backward compatibility with SSLv2, while adding the following enhancements:
|
|
•
|
MAC – A MAC (Message Authentication Code) is calculated by applying an algorithm (such as MD5 or SHA1) to data. The MAC is a message digest, or a one-way hash code that is fairly easy to compute, but which is virtually irreversible. In other words, with the MAC alone, it would be theoretically impossible to determine the message upon which the digest was based. It is equally difficult to find two different messages that would result in the same MAC. If the receiver’s MAC calculation matches the sender’s MAC calculation on a given piece of data, the receiver is assured that the data has not been altered in transit.
|
|
•
|
Client Hello – The first message sent by the client to the server following TCP session establishment. This message starts the SSL session, and consists of the following components:
|
|
•
|
Version – The version of SSL that the client wishes to use in communications. This is usually the most recent version of SSL supported by the client.
|
|
•
|
Random – A 32-bit timestamp coupled with a 28 byte random structure.
|
|
•
|
Session ID – This can either be empty if no Session ID data exists (essentially requesting a new session) or can reference a previously issued Session ID.
|
|
•
|
Cipher Suites – A list of the cryptographic algorithms, in preferential order, supported by the clients.
|
|
•
|
Compression Methods – A list of the compression methods supported by the client (typically null).
|
|
•
|
Server Hello – The SSL server’s response to the Client Hello. It is this portion of the SSL exchange that SSL Control inspects. The Server Hello contains the version of SSL negotiated in the session, along with cipher, session ID and certificate information. The actual X.509 server certificate itself, although a separate step of the SSL exchange, usually begins (and often ends) in the same packet as the Server Hello.
|
|
•
|
Certificates - X.509 certificates are unalterable digital stamps of approval for electronic security. There are four main characteristics of certificates:
|
|
•
|
Subject – The guarantee of a certificate identified by a common name (CN). When a client browses to an SSL site, such as https://www.MySonicWall.com, the server sends its certificate which is then evaluated by the client. The client checks that the certificate’s dates are valid, that is was issued by a trusted CA, and that the subject CN matches the requested host name (that is, they are both “www.MySonicWall.com”). Although a subject CN mismatch elicits a browser alert, it is not always a sure sign of deception. For example, if a client browses to https://MySonicWall.com, which resolves to the same IP address as www.MySonicWall.com, the server will present its certificate bearing the subject CN of www.MySonicWall.com. An alert will be presented to the client, despite the total legitimacy of the connection.
|
|
•
|
Certificate Authority (CA) - A Certificate Authority (CA) is a trusted entity that has the ability to sign certificates intended, primarily, to validate the identity of the certificate’s subject. Well-known certificate authorities include VeriSign, Thawte, Equifax, and Digital Signature Trust. In general, for a CA to be trusted within the SSL framework, its certificate must be stored within a trusted store, such as that employed by most Web-browsers, operating systems and run-time environments. The SonicOS trusted store is accessible from the System > Certificates page. The CA model is built on associative trust, where the client trusts a CA (by having the CA's certificate in its trusted store), the CA trusts a subject (by having issued the subject a certificate), and therefore the client can trust the subject.
|
|
•
|
Untrusted CA – An untrusted CA is a CA that is not contained in the trusted store of the client. In the case of SSL Control, an untrusted CA is any CA whose certificate is not present in System > Certificates.
|
|
•
|
Self-Signed Certificates – Any certificate where the issuer’s common-name and the subject’s common-name are the same, indicating that the certificate was self-signed.
|
|
•
|
Virtual Hosting – A method employed by Web servers to host more than one website on a single server. A common implementation of virtual hosting is name-based (Host-header) virtual hosting, which allows for a single IP address to host multiple websites. With Host-header virtual hosting, the server determines the requested site by evaluating the “Host:” header sent by the client. For example, both www.website1.com and www.website2.com might resolve to 64.41.140.173. If the client sends a “GET /” along with Host: www.website1.com, the server can return content corresponding to that site.
|
|
•
|
Weak Ciphers – Relatively weak symmetric cryptography ciphers. Ciphers are classified as weak when they are less than 64 bits. For the most part, export ciphers are weak ciphers. Common Weak Ciphers lists common weak ciphers.
|
