EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Tuning SSL components: choosing the configuration that is right for you

Despite looking fairly simple at first glance "just as an additional layer of 'security'", SSL/TLS is a complex multi-layer protocol that relies on a variety of state-of-the-art cryptographic techniques. The authors of the protocol made their best to come up with a protocol as simple for the man in the street as possible, with all the complicated stuff hidden under the hood. Yet, that very oversimplicity of the protocol often results in crucial settings of SSL endpoints being ignored, overlooked or misconfigured. Below we will consider the most important factors that should be taken into account when configuring your SSL endpoint. These hints are equally applicable to SecureBlackbox-driven and third party SSL implementations.

The article is split in two general sections: configuring your client-side SSL implementation and configuring your server. Before proceeding to the main content, let's summarize the main features of the SSL protocol.

Five versions of the protocol have been defined so far: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. SSL 2.0 is derelict old and insecure, and must not be used. SSL 3.0 is far better security-wise, but is also quite old and should only be used if you have serious reasons to do so, e.g., if you need to communicate to an old unupgradable SSL hardware . TLS 1.0 is OK if used with care, and TLS 1.2 is the recommended version. TLS 1.1 appeared halfway between TLS 1.0 and TLS 1.2; there are no specific reasons to use this particular version as it was fairly quickly superseded by TLS 1.2. We will only discuss TLS 1.0-1.2 below.

Security parameters of a particular connection are defined by a cipher suite - a combination of four cryptographic bricks: data encryption algorithm, key exchange algorithm, server authentication algorithm and MAC algorithm. For example, the DHE- RSA-AES128-SHA cipher suite specifies the key exchange algorithm of DHE, server authentication algorithm of RSA, data encryption algorithm of AES128 and MAC algorithm of SHA(1) . More than a hundred different cipher suites are defined, offering different protection strength. The cipher suite to be used during a particular session is picked by the server from a list offered by the client.

SSL comes up with mandatory authentication of the server and optional authentication of the client. Authentication is based on public key cryptography and relies on X.509 certificates as key and identity information containers. Every authenticated party must thus have a valid X.509 certificate and a key pair associated with it.

Now that we know enough about the protocol, we can proceed to the main points of the article.

Configuring your client-side SSL implementation

Versions

 

Switch off SSL 2.0 and SSL 3.0, thus only leaving TLS 1.0, TLS 1.1 and TLS 1.2 enabled. With SecureBlackbox this can be done in the following way:

Client.Versions := [sbTLS1, sbTLS11, sbTLS12];

or

Client.Versions = SBSSLConstants.Unit.sbTLS1 | SBSSLConstants.Unit.sbTLS11 | SBSSLConstants.Unit.sbTLS12;

 

Cipher suites

 

While SecureBlackbox supports the majority of cipher suites ever defined for SSL protocol, an average client application rarely needs to support all of them. First, there are certain cipher suites that provide inadequate protection level. Other cipher suites are only usable in specific configurations (such as DH-, SRP- or PSK-driven) and require special tune-up. We recommend unconditionally disabling cipher suites that contain '˜NULL', '˜ANON', '˜EXPORT' and '˜DES' in their names. It is very likely that cipher suites with '˜PSK' and '˜SRP' suffixes can also be disabled without affecting the functionality of your application. The minimal list of cipher suites to support, which provides maximal compatibility, is given below:

 

Cipher suite

Certificate type

Comments

SB_SUITE_RSA_AES128_SHA

RSA

A mandatory cipher suite required by TLS specification (RFC 5246)

SB_SUITE_RSA_AES256_SHA

RSA

 

SB_SUITE_DHE_RSA_AES128_SHA

RSA

Supports perfect forward secrecy (PFS)

SB_SUITE_DHE_RSA_AES256_SHA

RSA

Supports PFS

SB_SUITE_DHE_DSS_AES128_SHA

DSA

Supports PFS

SB_SUITE_DHE_DSS_AES256_SHA

DSA

Supports PFS

SB_SUITE_ECDH_ECDSA_AES128_SHA

ECDSA

 

SB_SUITE_ECDH_ECDSA_AES256_SHA

ECDSA

 

SB_SUITE_ECDHE_ECDSA_AES128_SHA

ECDSA

Supports PFS

SB_SUITE_ECDHE_ECDSA_AES256_SHA

ECDSA

Supports PFS

SB_SUITE_ECDH_RSA_AES128_SHA

RSA

 

SB_SUITE_ECDH_RSA_AES256_SHA

RSA

 

SB_SUITE_ECDHE_RSA_AES128_SHA

RSA

Supports PFS

SB_SUITE_ECDHE_RSA_AES256_SHA

RSA

Supports PFS

SB_SUITE_RSA_AES128_SHA256

RSA

 

SB_SUITE_RSA_AES256_SHA256

RSA

 

SB_SUITE_DHE_DSS_AES128_SHA256

DSA

Supports PFS

SB_SUITE_DHE_RSA_AES128_SHA256

RSA

Supports PFS

SB_SUITE_DHE_DSS_AES256_SHA256

DSA

Supports PFS

SB_SUITE_DHE_RSA_AES256_SHA256

RSA

Supports PFS

SB_SUITE_RSA_AES128_GCM_SHA256

RSA

 

SB_SUITE_RSA_AES256_GCM_SHA384

RSA

 

SB_SUITE_DHE_RSA_AES128_GCM_SHA256

RSA

Supports PFS

SB_SUITE_DHE_RSA_AES256_GCM_SHA384

RSA

Supports PFS

SB_SUITE_DHE_DSS_AES128_GCM_SHA256

DSA

Supports PFS

SB_SUITE_DHE_DSS_AES256_GCM_SHA384

DSA

Supports PFS

SB_SUITE_ECDHE_ECDSA_AES128_SHA256

ECDSA

Supports PFS

SB_SUITE_ECDHE_ECDSA_AES256_SHA384

ECDSA

Supports PFS

SB_SUITE_ECDH_ECDSA_AES128_SHA256

ECDSA

 

SB_SUITE_ECDH_ECDSA_AES256_SHA384

ECDSA

 

SB_SUITE_ECDHE_RSA_AES128_SHA256

RSA

Supports PFS

SB_SUITE_ECDHE_RSA_AES256_SHA384

RSA

Supports PFS

SB_SUITE_ECDH_RSA_AES128_SHA256

RSA

 

SB_SUITE_ECDH_RSA_AES256_SHA384

RSA

 

SB_SUITE_ECDHE_ECDSA_AES128_GCM_SHA256

ECDSA

Supports PFS

SB_SUITE_ECDHE_ECDSA_AES256_GCM_SHA384

ECDSA

Supports PFS

SB_SUITE_ECDH_ECDSA_AES128_GCM_SHA256

ECDSA

 

SB_SUITE_ECDH_ECDSA_AES256_GCM_SHA384

ECDSA

 

SB_SUITE_ECDHE_RSA_AES128_GCM_SHA256

RSA

Supports PFS

SB_SUITE_ECDHE_RSA_AES256_GCM_SHA384

RSA

Supports PFS

SB_SUITE_ECDH_RSA_AES128_GCM_SHA256

RSA

 

SB_SUITE_ECDH_RSA_AES256_GCM_SHA384

RSA

 

 

Cipher suites can be enabled and disabled with the following code:

// Disabling all cipher suites

for I := SB_SUITE_FIRST to SB_SUITE_LAST do
    Client.CipherSuites[I] := false;

// Enabling DHE-RSA-AES256-SHA cipher

Client.CipherSuites[SB_SUITE_DHE_RSA_AES256_SHA] := true;

or

 

// Disabling all cipher suites

for (int i = SBSSLConstants.Unit.SB_SUITE_FIRST; i <= SBSSLConstants.Unit.SB_SUITE_LAST; i++)
{
    client.set_CipherSuites(i, false);
}

// Enabling DHE-RSA-AES256-SHA cipher
client.set_CipherSuites(SBSSLConstants.Unit.SB_SUITE_DHE_RSA_AES256_SHA, true);

Certificate validation

 

Proper server certificate validation is one of the most important aspects of SSL client configuration. Improper or missing certificate validation procedures might (and will) completely compromise the security of the negotiated secure connection. We encourage you to read this section carefully and follow the below guidance in your SSL implementation.

 

The main goal of certificate validation is to establish the genuineness of the entity that provided the certificate. While the protocol itself does perform certain checks for you, in particular it verifies that the presenter of the certificate has access to the corresponding private key, certain checks are outside the scope of the protocol. They should be performed externally in accordance with local security policy. In a typical scenario of a client connecting to a broad range of publicly accessible servers, the client must ensure that the certificate's Common Name attribute references the correct domain name or IP address. It is also important to verify that the certificate was issued, either directly or indirectly, by a trusted certification authority (CA) and is appropriate for its use as an SSL certificate.

 

SecureBlackbox provides a unified way for validating server SSL certificates, suitable in the majority of typical client-server scenarios. Note that your particular scenario might require specific certificate handling. Certificate validation should be performed inside the OnCertificateValidate event handler, and the validation result has to be returned back to the component via the Valid parameter of the event. Note that OnCertificateValidate may be thrown several times per connection, for each certificate returned by the server, including the CA and root certificates. The certificates are passed to the user in order from the root or CA certificate down to the server's end entity certificate. This feature is reflected in the code snippet below.

if (Certificate.Chain = nil) or Certificate.Chain.Certificates[0].Equals(Certificate) then
begin
	// Certificate contains the end-entity certificate of the server:
    // performing chain validation
	CertificateValidator.ValidateForSSL(Certificate, Client.RemoteHost, 
	    Client.RemoteIP, hrServer, ChainCerts, true, false, UTCNow, 
		Validity, Reason);
	Valid := Validity = cvOk;
end
else
begin
	// Certificate contains an intermediate CA or root certificate:
    // caching it in ChainCerts storage for later use
    ChainCerts.Add(Certificate);
    Valid := true;
end;

or

if ((certificate.Chain == null) || (certificate.Chain.get_Certificates(0).Equals(certificate)))
{
	// certificate contains the end-entity certificate of the server:
    // performing chain validation
	certificateValidator.ValidateForSSL(certificate, client.RemoteHost, 
	    client.RemoteIP, TSBHostRole.hrServer, chainCerts, true, false, 
		SBUtils.Unit.UTCNow(), ref validity, ref reason);
	valid = (validity == TSBCertificateValidity.cvOk);
}
else
{
	// certificate contains an intermediate CA or root certificate:
    // caching it in ChainCerts storage for later use
	chainCerts.Add(certificate);
	valid = true;
}

Client certificates

 

Sometimes, an SSL server will require the client to present its certificate. While not being a typical scenario for the web, client authentication is often used in intranets or restricted areas of public web sites to control user access.

 

The most important task you should address here is to store your private key securely, as everyone who gains access to your private key can impersonate you before the server, and access it on your behalf. We strongly advise from keeping your private keys in files, even password-protected, and consider using secure storages provided by the operating environments instead. This could be a hardware security device or (a cheaper solution) a Windows system store. Windows CryptoAPI is capable of providing adequate software protection facilities for your private keys.

 

To tell the component about your client SSL certificate, load it into a TElMemoryCertStorage instance and assign the storage object to the ClientCertStorage property of your client-side SSL component.

 

Depending on the specifics of your environment, the server might be using PKI procedures when validating your certificate. In certain cases it might require you to send in not only your end-entity certificate, but also the entire chain up to the root certificate. With SecureBlackbox you can force the component to send the entire chain by putting all the certificates comprising it to the ClientCertStorage storage.

 

Renegotiation

 

In Autumn 2009 a serious flaw in TLS protocol was discovered. The flaw has been given a nickname of '˜renegotiation vulnerability/attack' due to the technique of the protocol used to exploit the flaw (secure renegotiation of the established key material). Shortly, a secure TLS conversation could be tampered with by an active adversary during session renegotiation due to a flaw in the renegotiation protocol. More details about the matter are available here.

 

Following discovery of the flaw, the standard was revised and appropriate measures were put in place to get rid of the flaw. A new protocol extension was introduced to allow compatible clients and servers to renegotiate securely. Security software vendors were strongly advised to implement the workaround in their software.

 

Unfortunately, the vulnerability could have only been worked around by introducing changes to the protocol. As a result, older software that could not be updated for any reason (mostly, hardware clients and servers) still can be occasionally found on the market.

 

SecureBlackbox components support three modes of operation with regard to the renegotiation problem (compatible/insecure, strictly secure and automatic) which can be set via the RenegotiationAttackPreventionMode property. A new OnRenegotiationRequest event can also be used to reject server's requests for renegotiation.

 

Please also note that followingthe discovery of the vulnerability, many SSL servers now reject renegotiation requests issued by clients. This may cause OnError event firing, with a non-fatal ERROR_SSL_NO_RENEGOTIATION error shortly after the RenegotiateCiphers() call. A good practice for SSL clients is to refrain from initiating session renegotiations at all.

 

Miscellaneous

 

Environments where the same physical server is used to host a number of web sites (so-called '˜shared hosting' services) are fairly popular today. In order to work correctly with such environments, SSL clients need to pass to the server the exact domain name they are connecting to so that the server could pick the appropriate certificate for the resource. This is achieved via a Server Name Indication extension to the TLS protocol. Remember to enable this extension to make your client-side SSL implementation work correctly with shared hosting services. Higher-level classes of SecureBlackbox 12 onwards, such as TElSimpleSSLClient, are capable of setting this extension automatically, providing that the ssloAutoAddServerNameExtension flag is included in the Options flag set of the component.

 

Other protocol extensions may be used to tune-up the way in which SSL connection is negotiated. For instance, the client can use extensions to specify the algorithms it supports or prefers, set the maximal size of SSL packets, and a variety of other communication parameters.

Configuring your server-side SSL implementation

Tuning up a server may be substantially more complex than configuring a client, primarily due to the need to support a plethora of different client implementations. A requirement to accept older clients might reduce the level of security provided by the server, so the necessity of supporting every particular weak version or cipher suite should be carefully assessed.

Versions

 

It is recommended to avoid using SSL 2.0 and SSL 3.0 versions wherever possible. TLS 1.0, TLS 1.1 and TLS 1.2 are OK. With SecureBlackbox this can be done in the following way:

 

Server.Versions := [sbTLS1, sbTLS11, sbTLS12];

 

or

 

server.Versions = SBSSLConstants.Unit.sbTLS1 | SBSSLConstants.Unit.sbTLS11 | SBSSLConstants.Unit.sbTLS12;

 

Cipher suites

 

We strongly recommend that only safe cipher suites given in the list above are activated. Yet, it is often not desirable / not achievable to narrow down the set of cipher suites supported by the server for compatibility reasons. We recommend a combined solution, built up of disabling all really weak cipher suites (those containing '˜NULL', '˜ANON', '˜EXPORT' or '˜DES' in their names) and arranging proper priorities for the others. It makes sense to assign higher priorities to stronger cipher suites (those providing perfect forward secrecy or designed on AES256 and/or SHA256 algorithms), and lower priorities to less secure ciphers (RC4, 3DES). Priorities can be assigned via the CipherSuitePriorities property. The server will then use the prioritized cipher suite list to choose the most secure one among those offered by the client.

 

Please also note that in order for a cipher suite to be usable by the server, the latter must have a certificate of appropriate type assigned. For example, the SB_SUITE_RSA_AES256_SHA suite requires an RSA certificate to be available, and the SB_SUITE_ECDHE_ECDSA_AES256_SHA suite relies on a certificate with ECDSA key. Unavailability of certificate of appropriate type will make the server unable to use cipher suites relying on that type of certificates.

 

A sample code snippet is given below:

 


// Disabling all cipher suites
for I := SB_SUITE_FIRST to SB_SUITE_LAST do
	Server.CipherSuites[I] := false;

// Enabling DHE-RSA-AES128-SHA and DHE-RSA-AES256-SHA ciphers
Server.CipherSuites[SB_SUITE_DHE_RSA_AES128_SHA] := true;
Server.CipherSuites[SB_SUITE_DHE_RSA_AES256_SHA] := true;

// Assigning a higher priority to AES256-based cipher
Server.CipherSuitePriorities[SB_SUITE_DHE_RSA_AES128_SHA] := 50;
Server.CipherSuitePriorities[SB_SUITE_DHE_RSA_AES256_SHA] := 100;

or

 


// Disabling all cipher suites
for (int i = SBSSLConstants.Unit.SB_SUITE_FIRST; i <= SBSSLConstants.Unit.SB_SUITE_LAST; i++)
{
	client.set_CipherSuites(i, false);
}

// Enabling DHE-RSA-AES128-SHA and DHE-RSA-AES256-SHA ciphers
client.set_CipherSuites(SBSSLConstants.Unit.SB_SUITE_DHE_RSA_AES128_SHA, true);
client.set_CipherSuites(SBSSLConstants.Unit.SB_SUITE_DHE_RSA_AES256_SHA, true);

// Assigning a higher priority to AES256-based cipher
Client.set_CipherSuitePriorities(SBSSLConstants.Unit.SB_SUITE_DHE_RSA_AES128_SHA, 50);
Client.set_CipherSuitePriorities(SBSSLConstants.Unit.SB_SUITE_DHE_RSA_AES256_SHA, 100);

Server certificates

 

Server certificate is one of the key factors which affect security of all SSL connections negotiated by the server. Improper certificate management procedures might compromise the security of the entire environment. What is worse, a security flaw caused by mishandling of a server certificate will really likely be hardly noticeable until it is too late.

 

The private key associated with the certificate should be kept safe. The recommended option is to use a cryptographic hardware device for storing the key. Alternatively, protected areas of the operating environment (e.g. CryptoAPI certificate stores) may be used. In either case, the key should be imported to its permanent place of storage with a non-exportability option.

 

If you became an unlucky victim of private key theft, or if you are just suspecting that the key might have been accessed by a third party, report the key loss to the CA immediately. Stop the server until you receive the replacement certificate and key. Do not hesitate to contact the CA. There is nothing shameful in becoming a victim of theft. By reporting the key compromise you show that you are a responsible administrator of the SSL server and that you care about the safety of your customers' private data.

 

In order for your server certificate to be validated correctly by the clients, they will often need to have the entire chain of certificates from your server's end-entity certificate up to the root CA certificate available. A chain typically consists of three or four certificates: server's certificate, one or two intermediate CA certificates, and an explicitly trusted root certificate. Major CAs have their root and CA certificates included into the distributions of popular operating systems and can be easily retrieved should the client need to validate the chain they are part of. The others only ship the root certificate, which means that the intermediate certificates have to be provided by other means. That's why a good practice for an SSL server is to send the entire certificate chain to its clients. In case a client doesn't have intermediate certificates locally, it can use certificates provided by the server to reconstruct the chain.

 

Setting up a SecureBlackbox-driven SSL server to send out the entire chain is fairly easy. Just put all the certificates comprising the chain to the certificate storage component assigned to the CertStorage property of the server, and then set the ForceCertificateChain property to true. The server will do the rest of the job for you.

 

Client authentication and certificates

 

Client authentication is optional and is typically used for identifying or authorizing clients and restricting access to certain '˜protected' areas of the web site. A typical validation of a client certificate therefore involves two major steps: (1) recognizing the certificate owner and acquiring their access rights details from a local user database, and (2) checking certificate integrity and validity. While the first step is clearly outside the scope of SSL, the second step should be performed within the SSL module. Depending on the specifics of the environment, different validation approaches can be used. In the simplest case the certificate received from the client is compared toits original copy stored locally. More complicated scenarios involve the use of certificate chains and fully-fledged PKI procedures.

 

SecureBlackbox server components return user certificates via the OnCertificateValidate event. It is the task of the user to perform the validation and return its outcome via the Valid parameter of the event. Switch the ClientAuthentication property on to make the server request a certificate from the client. The AuthenticationLevel property controls whether the server should require the certificate (and close the connection if the certificate was not provided) or request it.

 

Note that server and client authentication are completely independent to each other. The peers are not required to use the same approach for client- and server-side validation; neither are they required to use certificates from the same CA or holding keys of the same type.

 

Session pooling

 

Session pooling is a convenient protocol mechanism most effective in environments where the same client needs to establish multiple secure connections to the same server. For multi-channel scenarios SSL comes up with a technique known as '˜abbreviated handshake' which ultimately reduces the number of cryptographic operations the peers need to perform for every new negotiation. Only the first negotiation is performed in full; encryption keys for all subsequent negotiations are simply '˜cloned' from that of the first connection.

 

In order to support abbreviated handshakes the server needs to maintain a persistent database of negotiated SSL connections. In SecureBlackbox such database is implemented in the TElSessionPool class. A single instance of TElSessionPool class should be shared among all SSL server objects (e.g. TElSSLServer) to promote database information to them.

 

Renegotiation

 

The ins and outs of session renegotiation topic were discussed above. Please read the client-side '˜Renegotiation' section for the details. SecureBlackbox server components throw the OnRenegotiationStart event which lets the developer be aware of a renegotiation initiated by the client and whether it is '˜safe' (protected from the renegotiation issue) or not. The event also allows the developer to cancel the renegotiation if they are unhappy with it.

 

Note that in most cases there is no sense for the client to initiate session renegotiation, so disallowing client-originated renegotiations completely might make sense.

Handling errors

 

Complexity of SSL protocol and its dependency on external certificate validation routines might occasionally lead to negotiation failures. Properly implemented error handling procedures might serve you really well in finding out the reason if something doesn't work or stops working.

SecureBlackbox SSL components report errors via the OnError (in certain cases OnSSLError) event.The event passes three parameters to the developer: ErrorCode reports an identifier of the error, Fatal tells whether the error is a show-stopper for the current session, and Remote specifies whether it was local or remote side which recognized and reported the error. It is a good idea to keep track of all invocations of the OnError event, as this may simplify the task of pinpointing the underlying reasons and speed up the investigation.

Error code

Reason and steps to take

ERROR_SSL_UNEXPECTED_MESSAGE

Connection is made to/from a service that doesn't talk proper SSL (e.g. a plain HTTP connection is made to an HTTPS port). Re-check that both client and server services are talking SSL.

Unsupported version of the protocol. Try to play with Versions property of the SSL component and check if any of the combination helps.

ERROR_SSL_BAD_RECORD_MAC ,

ERROR_SSL_DECRYPTION_FAILED,

ERROR_SSL_DECODE_ERROR ,

ERROR_SSL_DECRYPT_ERROR

 

The peers failed to negotiate a shared key material. Try connecting with different cipher suites one-by-one and check if any of them helps. If neither does, try to use a different protocol version.

ERROR_SSL_RECORD_OVERFLOW

Packet size too large. Try to decrease the maximal size of the packet by adjusting the MaxFragmentLength extension.

ERROR_SSL_DECOMPRESSION_FAILURE

Compression or decompression failure. Switch off compression (CompressionAlgorithms property)

ERROR_SSL_HANDSHAKE_FAILURE ,

ERROR_SSL_ILLEGAL_PARAMETER

 

Incompatible versions or cipher suite lists. Try to play with version and cipher suite sets. Check that the server certificate is provided and has an associated private key.

ERROR_SSL_NO_CERTIFICATE ,

ERROR_SSL_BAD_CERTIFICATE,

ERROR_SSL_UNSUPPORTED_CERTIFICATE,

ERROR_SSL_CERTIFICATE_REVOKED,

ERROR_SSL_CERTIFICATE_EXPIRED,

ERROR_SSL_CERTIFICATE_UNKNOWN,

ERROR_SSL_UNKNOWN_CA

The certificate provided by the peer is not valid

ERROR_SSL_ACCESS_DENIED

The requested application-layer resource cannot be accessed by the requestor. Check with the administrator of the remote resource.

ERROR_SSL_EXPORT_RESTRICTION

The peer is only configured to use exportable cipher suites. Switch on support for '˜EXPORT' cipher suites.

ERROR_SSL_PROTOCOL_VERSION

ERROR_SSL_INSUFFICIENT_SECURITY

ERROR_SSL_INTERNAL_ERROR

ERROR_SSL_USER_CANCELED

ERROR_SSL_NO_RENEGOTIATION

ERROR_SSL_CLOSE_NOTIFY

An SSL connection was closed gracefully and can be restored or cloned in future. This is actually a notification, not an error.

 

Synchronous SSL-capable components, such as TElHTTPSClient, also use exceptions to report protocol issues. These should also be taken into account when investigating a problem. Please note that the issue mentioned in the exception might serve either as a reason or as a consequence of an SSL layer problem.

* * *

Sticking to the rules given above will help you bring your SSL endpoint to the maximal level of security provided by SSL/TLS family. Still, it is important to remember that security is not something that can be easily plugged in (as an SSL module for example). You should always keep monitoring your operating environment as a whole to be sure that every single piece of it is protected appropriately.

Return to the list

|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!