Certificate pinning

Certificate pinning aims to close a trust problem that comes with PKI architecture: you trust the certificate authority (CA) and assume that the server is valid, because you trust the CA. Certificate pinning aims to ensure that you also can also trust the server. How is pinning going to achieve this? You know the certificates you are going to receive by the server, and validate those certificates with your local information. Sounds complicated, but it means that your client has all the certificates expected to receive from the server (CA certificate, intermediate certificate and server certificate) and when the server sends those certificates, they are all compared to the client’s locally stored ones. If one of those certificates do not match, client will not connect to server.

OWASP has some more useful information on this topic online available

Sometimes you are already using certificate pinning without knowing it. When you import the CA certificate of your enterprise CA into a keystore, you are already partly using certificate pinning. If you also import the certificate of the server to validate the complete chain, you are doing certificate pinning. iOS documentation contains little information on this topic, but with Google help you can find some projects that try to solve this on GitHub [1] [2] [3] [4]. Android developer guide contains a small section on pinning. Looking at the source code, you can see that a keystore containing only the expected certificates is created.

CertificateFactory cf = CertificateFactory.getInstance("X.509");
InputStream caInput = new BufferedInputStream(new FileInputStream("load-der.crt"));
Certificate ca = cf.generateCertificate(caInput);// Create a KeyStore containing our trusted CAsString keyStoreType = KeyStore.getDefaultType();
KeyStore keyStore = KeyStore.getInstance(keyStoreType);
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);

As you can see, certificate pinning is simple to do. A problem is that you need to be able to control the used keystore. This means that you cannot do real certificate pinning in a web only scenario. If your app is 100% HTML5 or a hybrid app, you won’t be able to use your own keystore. This is also true for Cordova apps, as here you are using the web browser to access the TLS secured service, and not a native client. The browser will trust those CAs that are configured for the browser. HTTP Public Key Pinning (HPKP) promises to gain back some of the trust of a native pinning implementation

HTTP Public Key Pinning

With HPKP, a server publishes a set of hashes of his certificates, and a client expects to receive certificates from the server that matches those hashes. In case a CA is compromised, or an attacker can create a false certificate, the fingerprint (hashes) of these certificates is expected to differ, and the client will then not open a connection to the server. Of course, in case the attacker can take of the web server (directly or indirectly), HPKP won’t help. The hashes for HPKP are communicated in a HTTP header: Public-Key-Pins.

There is a RFC for HPKP (RFC 7469), but don’t expect too much. IE/Edge don’t support it; Chromium browser don’t use HPKP for private root CAs. A weak point is the first request: Ensure that HPKP is only send by a secured connection (TLS). And to make HPKP make sense, on the first request, you must hope that the web server wasn’t compromised at that time. If so, you’ll already get an invalid hash. When the server certificate is updated, the hash must be recreated and included in the header. An article by Mozilla describes how to create the hash and how to set the header. Online tools to validate the generated hash are also available [1] [2]. Some tips on correct usage of HPKP can be found here.

Enable TLS in SMP3

SSL is out, TLS is the new kid in town (although already pretty old) and to keep security high on your SMP3 server, a question remains: how to enable TLS on SMP3? Easy: it is already configured!

By default, SMP3 comes with TLS enabled. The trick is to configure it how you want it to be. For once, there are the ciphers (not part of this blog) and the protocol. The protocol defines if a browser can use TLS v1, v1.1 or v1.2. The configuration is done on the server side, in the default-server.xml file located at:

/<SMP3 installation directory>/Server/config_master/org.eclipse.gemini.web.tomcat/default-server.xml

As SMP3 is using Tomcat as its web server, the usual Tomcat configuration parameters apply. To have a HTTPS connection on port 8081, the XML looks like this:

<Connector SSLEnabled=”true” ciphers=”TLS_RSA_WITH_AES_128_CBC_SHA” clientAuth=”false” keyAlias=”smp3″ maxThreads=”200″ port=”8081″ protocol=”com.sap.mobile.platform.coyote.http11.SapHttp11Protocol” scheme=”https” secure=”true” smpConnectorName=”oneWaySSL” sslEnabledProtocols=”TLSv1″ sslProtocol=”TLS”/>

Parameters

  • Port: defines the port Tomcat will listen on. Here it is 8081
  • sslEnabledProtocols: “The comma separated list of SSL protocols to support for HTTPS connections. If specified, only the protocols that are listed and supported by the SSL implementation will be enabled.” [1]
  • sslProtocol: “The SSL protocol(s) to use (a single value may enable multiple protocols – see the JVM documentation for details). If not specified, the default is TLS” [1]

Connecting to the port results in a TLSv1 connection:

The parameters that define which protocol can be used are sslEnabledProtocols and sslProtocol. Now, which one does what? I found [2] and [3] explaining this:

  1. setProtocol=”TLS” will enable SSLv3 and TLSv1
  2. setProtocol=”TLSv1.2″ will enable SSLv3, TLSv1, TLSv1.1 and TLS v1.2
  3. setProtocol=”TLSv1.1″ will enable SSLv3, TLSv1, and TLSv1.1
  4. setProtocol=”TLSv1″ will enable SSLv3 and TLSv1

In the above example, sslProtocol = TLS, therefore TLSv1 and SSLv3 is available. To limit the connection to TLSv1, sslEnabledProtocol must be set to TLSv1. To have a connection that allows for TLSv1, TLSv1.1 and TLSv1.2 (and let the browser decide which one to use), set sslEnabledProtocols to TLSv1,TLSv1.1,TLSv1.2.

Example

<Connector SSLEnabled=”true” ciphers=”TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA” clientAuth=”false” keyAlias=”tobias” maxThreads=”200″ port=”8081″ protocol=”com.sap.mobile.platform.coyote.http11.SapHttp11Protocol” scheme=”https” secure=”true” smpConnectorName=”oneWaySSL” sslEnabledProtocols=”TLSv1,TLSv1.1,TLSv1.2″ sslProtocol=”TLS”/>

If I now connect on port 8081, my browser should use the highest protocol available.

[1] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

[2] http://mail-archives.apache.org/mod_mbox/tomcat-users/201303.mbox/%3C13A085B2E018374C813676301AED0EE412D87457C3@BLR0EXC00.us.sonicwall.com%3E

[3] http://wiki.apache.org/tomcat/Security/POODLE

Afaria Setup 7: Configure SSL for web application

Having a SSL certificate installed and available in IIS, access to web sites / applications can be secured using SSL. Next step is to secure the access to the Afaria Web Application. This will be done by activating SSL for the entire web site, that is: all resources under the default web site can be accessed using SSL. The SAP Afaria web application is not installed yet, but after it is installed, it will be run beneath the default web site by IIS. As the default web site is configured for IIS, all resources underneath it will be too.

Configuration

  1. Open IIS Manager
  2. Select Default Web Site

  1. Select bindings

  1. Select https and click Edit …

  1. Select SSL certificate afaria from list. Afaria is the friendly name / alias given the the IIS certificate in the previous step: installing SSL to IIS.
  • Assign this binding to all IP address and port 443.

Result

IIS default web site now accessible using SSL.

Security validation of SCAs by SUM

Updating a system with SUM is as easy as walking into Mordor. Upgrading a SPS needs you to have a stack XML and when you put SCAs that are signed into a folder, you still have to ensure that SUM can verify the validity of the files. To do so, SUM must be able to have access to the certification revocation list (CRL). This list informs SUM if the certificate used to sign the SCA file is valid or not. Short: if the file can be trusted and therefore be installed or not.

To be able to do so, the CRL file must be downloaded and placed in the same directory as the SCA files. If this is not done before running SUM, you’ll get this screen:

SUM can continue without verifying the files, but that’s some kind of security breach you will commit. Therefore it is better to do as the message text tells you: download the file and place it into the foler. Download the CRL from here: https://tcs.mysap.com/crl/crlbag.p7s. Copy the file to the directory that contains the SCA files


Select repeat and continue.


Now SUM can verify the files and will know when a certificate was revoked and tell you that it is not secure to install that file.