Analysing the risk factor of buggy SSL validation system


 

Introduction

SSL (Secure Sockets Layer) is the most standard security technology used in internet communications between a server and a client. A client can be a browser based website or non-browser based client application. Based on the type of application, SSL enables a secured transmission of credit-card information, user personal information or login credentials and such data across network. SSL certificates are needed to create the secured connection between the parties [1].

How SSL Works

After a TCP connection, SSL handshake is initiated by the client. The client sends different specifications like SSL version, Cipher suites to be used, compression methods to be used etc. The server picks the highest SSL version supported by both the parties and optionally picks a cipher suite and compression method supported by the client.

 

After this, the server sends its certificate. This certificate has to be trusted by the client or by some third party trusted authority. After the certificate of the server is verified correctly, a key is exchanged. This key may be a public key based on the cipher suite selected. Now client and server computes the key for symmetric encryption. Followed by this, the client tells the server that further communication would be encrypted and then sends encrypted authentication message to the server.

 

Now the server verifies that the Message Authentication Code (MAC) is correct to decrypt the message. It then sends a message which is verified by the client.

 

Now the handshake is finished and the client can communicate to the server in a secured way. To close the connection after communication both the parties uses close_notify alert. During this time when an attacker tries to terminate the connection by injecting FIN bit, both client and server knows that the connection was improperly tear down. This just interrupts the secured connection for a while but does not compromise the security of the connection [2, 3].

 

Thus for a proper SSL connection, validation of computer hardware and software is required. Hence security experts has overcome with a concept called chain of trust for this verification purpose [4].

 

Essential parts of SSL validation

Chain of trust verification:

Each certificate must be issued by a trusted Certificate Authority (CA). Even if the issuer is not a trusted CA it should be issued by some other authorities which are chained all the way down to a trusted CA.

 

Hostname verification:

SubjectAltName (SAN) is an extension in the X.509 certificates which carries various host information like host-name, email etc.

According to RFC 2818 while checking the hostname one should check “SubjectAltName” primarily. One can check the “Common Name” field also but that has been deprecated and has been checked still for backward compatibility. But most of the SSL implementation checks it the other way round – which introduce bugs regarding host name verification.

 

CRL (Certificate revocation list) check and X.509 extension check:

Most application do not care about CRL checking. Different SSL library has different approach of doing this checking. For example OpenSSL implement the certificate revocation feature but the application need to supply the certificate revocation list to it which many applications ignore or forget. Other libraries like JSSE require the application to check the revocation list by its own and most application don’t bother about this.

Here we are going to place some example of some libraries and tools where SSL validation is done in a wrong way or has not been done at all.

SSL Libraries

OpenSSL.:
OpenSSL is one of the most used libraries for handling certificates and manage them. OpenSSL does not provide any host name verification itself; and this is logical because different application has different notions of hostname verification, for example some use a name, some use an IP or some use an email as verifying hostname. As openSSL does not provide a hard and fast rule for hostname verification most application misses to verify the hostname during implementation of this library.

Again by default openSSL does not provide any run-time exception for self-signed certificate or invalid chain of trust. SSL_connect is a function in openSSL to establish a secure connection. For some ssl validation error this function returns false but yet for some validation error this function returns true, but sets some flag. It is the applications responsibility to check those flags and complete the validation.

 

Example:

Trillian is a popular internet messenger client uses openSSL to establish secure connection. To get a secure connection it calls the SSL_connect function and based on the return value it establish the connection. It never calls the SSL_get_verify_result to verify other verification flags like SSL_VERIFY_PEER. Thus Trillian accepts the certificate that are not properly verified and vulnerable to the man-in-the-middle attack.

 

JSSE:

Java secure socket extension (JSSE) is a library that provides many interfaces through which all the java applications stablish SSL connection. This java applications includes android mobile apps also. A low level API is SSLSocketFactory which perform or may not perform host name verification depending on the implementation.

 

 


private void checkTrusted(X509Certificate[] chain, String authType, Socket socket, boolean isClient)
throws CertificateException {
...
// check endpoint identity
String identityAlg = sslSocket.getSSLParameters().
getEndpointIdentificationAlgorithm();

if (identityAlg != null && identityAlg.length != 0)
   {
      String hostname = session.getPeerHost();
      checkIdentity(hostname,chain[0], identityAlg);
   }
}

 

SSL clients that use raw SSLSocketFactory gets the algorithm field (identityAlg) null in the above checktrusted () function thus not performing hostname verification. The job of hostname verification is delegated to the application running on top of JSSE. This feature is not explain in the JSSE API documentation.

 

Example of bugs in SSL for non-browser software

Many bugs in SSL for non-browser software in the areas of Merchant SDKs, Cloud Services, Mobile Applications, Middleware Web services. [5]

Merchant SDKs: Amazon Flexible Payments Service

According to paper [5], The Amazon FPS provides SDK that server can include to carry the customers payment details to payment gateways.Within FPS part of establishing an SSL connection using libcurl library, there is a misunderstanding in setting cURL options to validate certification as follows,


curl_setopt($curlHandle, CURLOPT_SSL_VERIFYPEER, true);
curl_setopt($curlHandle, CURLOPT_SSL_VERIFYHOST, true);
...
//Execute the request
$response = curl_exec($curlHandle);

The default value for CURLOPT_SSL_VERIFYHOST is 2, but when the value is passed true as above, it in turn sets to value to 1. This value means validating against any common name that may or may not match the requested name and that was not the aim. Any code uses this SDK for service will be vulnerable for man-in-the-middle attack.

Cloud Services: Rackspace

Rackspace cloud services uses ASIHTTPRequest library (via OpenStack iOS cloud framework) to set secure connection.

 

This library provides a configuration variable ValidatesSecureCertificate, set to 1 by default. The value 0 means, it turns off, Chain-of-trust and Hostname verification. The Rackspace App does not present the user with option to switch validateSSLSwitch. Instead, it initializes the value to 0 by objective-c allocator. This leads to turning on ignoreSSLValidation in ASIHTTPRequest, which in return set the variable ValidatesSecureCertificate to 0, causing the disable of certificate validation.[5]

 

This, paper comes to conclusion that SSL connections established by the Rackspace

apps on iOS are insecure against a man-in-the-middle attack.

Middleware Web Services:
Apache Axis, Axis 2, Codehaus XFire

As described in paper [5], Apache Axis, Axis 2 and XFire applications rely on SSLSocketFactory to establish SSL connections (as they use HTTP Client).

 

SSLSocketFactory does not verify host name verification (fixed later in HTTP client 4).

 

This lead to vulnerability of validating only chain of trust without verifying host name.

Mobile Apps: APPLE mobile

As described in paper [6], Apple had a security flaw in their ssl certificates validation, which was due to containing an extra goto fail; sentence. This makes a skip in actual SSL validation. Refer the code snippet from Apple open source library[6] shares below,


SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,uint8_t *signature, UInt16 signatureLen)
{    	......   
......
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
       goto fail;
   	goto fail;
......
	err = sslRawVerify(ctx,
                      ctx->peerPubKey,
                      dataToSign,				/* plaintext */
                      dataToSignLen,			/*plaintext length*/
                      signature,
                      signatureLen);
   fail:
   SSLFreeBuffer(&signedHashes);

   SSLFreeBuffer(&hashCtx);

   return err;
}
.....
.....	

 

Recommendations and tips to avoid bugs

For application developers

  1. Developers need to verify the default settings of SSL libraries. In some cases the default values might disable certificate validation.
  2. When adopting and extending standard  SSL libraries, care needs to be taken by apps to verify that, all relevant steps of validation of certifications are followed
  3. Testing of software for SSL validation of certificates needs to include steps for testing Chain of trust, host name check, signature check and certificate expiry.
  4. Black-box and adversarial testing of software should include other wrong certificates to test validation of certifications for application apart from intended set of correct certificates.
  5. Developers should be aware of outdated libraries. SSLv3 is vulnerable to the POODLE Attack. During SSL handshake attacker can force client to use sslv3 or TLS 1.0 to exploit this vulnerability. For this reason, ebay has disabled the support of sslv3. [7]
  6. Developers, testers should not turn off the ssl validation during development or testing phase which could leave the code untested, thus leading to security vulnerabilities.

For SSL library developers

  1. SSL libraries need to be more explicit about the semantics of their APIs. It should have good javadoc with explanations on different options, parameters and some possible values along with some examples of use.
  2. Responsibility of managing SSL connections should be abstracted from application layer.
  3. SSL Libraries should set safer default values for options and parameters that ensures secure SSL connections.
  4. Runtime exceptions should be raised as and when important steps of validation are passed with NULL or Empty instead silently skipping the validation.

 

 

Conclusion:

A good design of APIs for SSL is important in ensuring that they are not misinterpreted during use. While designing API one should take to consideration all essential and critical parts of SSL connection. There should not be a room for overriding this critical part of security connection.

 

It is dangerous to rely on standard libraries for secured SSL connections without verifying the APIs for its options, parameters and variable values.

 

Man-in-the-middle attack should be part of testing strategy for non-browser based apps.

Co-Authors

  • Priti Swami
  • Karthik G Venkatesan

References:

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s