Using SSL in Studio

The Secure Sockets Layer (SSL) is the standard security technology for establishing an encrypted link between a server and a client. The encrypted link ensures that all data passed between the server and clients remain private and unchanged. To create an SSL connection a server requires an SSL certificate. This section provides an overview of using SSL in Studio, discusses Transport Layer Security (TLS) and SSL security, discusses certificates and supplies the procedures you need to properly import Certificate Authority (CA) and end-entity certificates and private keys for use when verifying SSL client authentication.

SSL and Transport Layer Security

TLS 1.0 represents an upgrade of SSL 3.0. As an example, the TLS handshake protocol for establishing client/server authentication and encryption differs from the SSL handshake protocol. Additionally, TLS is now more extensible. Although they cannot interoperate, TLS provides a mechanism by which a TLS 1.0 implementation can revert to an SSL 3.0 implementation.

The TLS protocol uses public-key and symmetric-key cryptographic technology. Public-key cryptography uses a public key and a private key. Information encrypted with one key can be decrypted only with the other key. For example, information encrypted with the public key can be decrypted only with the private key.

Each server's public key is published, while the private key is kept secret. To send a secure message to the server, the client encrypts the message by using the server's public key. When the server receives the message, it decrypts the message with its private key.

Symmetric-key cryptography uses the same key to encrypt and decrypt messages. The client randomly generates a symmetric key to be used for encrypting all session data. The key is then encrypted with the server's public key and sent to the server.

TLS provides three basic security services:
  • Message privacy – Achieved through a combination of public-key and symmetric-key encryption. All traffic between a client and a server is encrypted using a key and an encryption algorithm negotiated during session setup.
  • Message integrity – Ensures that session traffic does not change en route to its final destination. TLS and SSL use a combination of public/private keys and hash functions to ensure message integrity.
  • Mutual authentication – Exchange of identification through public-key certificates. Client and server identities are encoded in public-key certificates, which contain the following components:
    • Subject's distinguished name
    • Issuer's distinguished name
    • Subject's public key
    • Issuer's signature
    • Validity period
    • Serial number
You can also use secure HTTP (HTTPS) to ensure that a client's security information is not compromised when downloaded from a server.

Certificates

SSL uses digital certificates to authenticate the identity of the server and optionally the client. Digital certificates are issued by a Certificate Authority (CA), a trusted agency that is authorized to issue, renew and revoke digital certificates after verifying the identity and legitimacy of the requesting party. A CA certificate, which may be a root CA certificate or a subordinate CA certificate, includes the CA's signature and the period of validity. A CA guarantees the connection between a key and another CA or end-entity. A end-entity is a person, a role, an organization, a pseudonym or a piece of hardware or software.

Encryption and authentication are performed by means of a public and a private key. The public key is embedded into a certificate, known as a site or server certificate. The certificate contains several items of information, including the name of the CA that issued the certificate, the name and public key of the server or client, the CA's signature and the certificate's date and serial number. The private key is created when you create a self-signed certificate or a CA certificate request and is used to decrypt messages from clients.

A SSL or TLS session is established in the following sequence:
  1. The client and the server exchange hello messages to negotiate the encryption algorithm and hashing function (for message integrity) to be used for the session.
  2. The client requests an ITU-T standard X.509 certificate from the server to prove its identity. Optionally, the server can request a certificate from the client. Certificates are verified by checking the certificate format, the validity dates and by verifying that the certificate includes the signature of a trusted certificate authority (or is self-signed).
  3. The client randomly generates a set of keys that is used for encryption. The keys are encrypted with the server's public key and securely communicated to the server.



Feedback | Notices


Timestamp icon Last updated: Tuesday, 27 September 2016


https://www.ibm.com/support/knowledgecenter/en/SS3LC4_7.5.3/com.ibm.wci.doc/SSL_overview.html