Page: Using SSL with Akula
Page: Working With the Request
Page: Getting HTTP Query String Parameters
Page: Getting Request Path Parameters
Page: Getting HTTP Headers
Page: Connecting to a Custom Realm
Page: REST API Permissions
Page: Handling Exceptions and Errors
Page: Forced Logout
Page: Allow Cross Origin Requests in a Browser App
Page: Working with Form Data
Using SSL with Akula
SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a client, such as a client browser or other type of client app. An encrypted link ensures that all data passed between the web server and client remains private.
When a client makes a secure request to the web server using SSL, the client specifies the protocol of the request as
https://, instead of the unsecured
This document contains the following sections:
SSL and the Akula Server
Because SSL is configured at the web server level, there is no configuration required on the Akula Server to support SSL. For example, you deploy the Akula Server on Tomcat, and also use Tomcat as your web server. Therefore, all SSL configuration is done in Tomcat. For more information on configuring SSL for Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html.
If you are not using Tomcat as your web server, then see the documentation on your web server for information and instructions on how to configure SSL.
Make sure that your web server uses an SSL protocol of "SSLv3+TLSv1", "SSLv3", or "TLSv1". For strong strong encryption, do not use "SSLv2".
SSL and Akula client apps
An Akula client app accesses the Akula Server by making requests to the REST endpoints exposed by the app scopes deployed on the Akula Server. An endpoint exposed by an Akula app scope consists of a URL and an HTTP access method, such as GET or POST. However, the protocol of the request,
http://, is controlled by the web server through which you access the Akula Server.
as https://. There is not other client configuration necessary to make SSL requests to the Akula Server.
The Akula clients only support SSL certificates from a Certificate Authority (CA) such as VeriSign or Thawte. Such certificates can be electronically verified by the CA. However, the Akula clients do not support self-signed certificates. Self-signed certificates are user generated and have not been registered with a CA and, therefore, cannot be verified.
Make sure that you choose a CA that is supported on all client devices, client device versions, client browsers, and client browser versions required by your client app. If a client does not support the CA used by the server, then the client will not be able to communicate with the server.
Choosing a cipher suite
Ciphers are the algorithms used to encrypt or hash data when communicating over SSL. A cipher suite is the set of ciphers that are used for all parts of communicating over SSL.
Characteristics of weak ciphers
Verivo recommends that you only use strong ciphers with SSL. To differentiate strong ciphers from weak, Verivo used the following criteria to identify weak ciphers:
- All anonymous versions
- All Export versions - Export versions of ciphers are often deliberately weak.
- All ciphers with null encryption
- Weak hash algorithms for the HMAC - However, ciphers using these weak algorithms might be needed to support older versions of Microsoft Windows.
- All ciphers using DES for symmetric encryption - The key size for DES is too small.
- All Kerberos ciphers - While Kerberos is secure, and can be used, most people do not run the server in a Kerberos environment.
- All ciphers using RC4 for symmetric encryption - RC4 is considered a weak cipher. However, ciphers using this algorithm might be needed to support older versions of Microsoft Windows.
- All non TLSv1 or SSLv3 ciphers -Any version prior to these are weak.
- All ciphers using 3DES for symmetric encryption - While it is considered secure, it is weaker and slower than RSA.
Recommended Cipher Suites
Verivo recommends the following asymmetric ciphers, in order from strongest to weakest:
- Elliptic Curve Diffie-Hellman Ephemeral with Elliptic Curve Digital Signature Algorithm (**)
- Elliptic Curve Diffie-Hellman Ephemeral with RSA (**)
- Elliptic Curve Diffie-Hellman with Elliptic Curve Digital Signature Algorithm (**)
- Elliptic Curve Diffie-Hellman with RSA (**)
- Diffie-Hellman Exchange with Digital Signature Standard
- Diffie-Hellman Exchange with RSA
- Plain RSA with a 512 bit or larger key
Verivo recommends the following symmetric ciphers:
- AES with 128 bit keys - Some servers may have 256 bit AES support. If your system supports it, replace 128 with 256 in the cipher suites identifier.
Verivo recommends the following hashing algorithms, in order from strongest to weakest:
Verivo recommends the following ciphers, in order from strongest to weakest:
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (**)
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (**)
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (**)
- TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (**)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (**)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (**)
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (**)
- TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (**)
- TLS_EMPTY_RENEGOTIATION_INFO_SCSV (Required to support TLS renegotiation fix for vulnerability, as described here: http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html)
** No CA currently uses Elliptic Curve encryption. However it is included because CAs will use them in the future.
Supporting Microsoft Windows XP and older Windows versions
Some older versions of Windows might require RC4 symmetric encryption or MD5 hashing, both of which are considered weak. If so, then you can use the following ciphers:
Best practices for using SSL with Akula
In a typical deployment environment, clients make all requests to the Akula Server using SSL. This is because all requests to the Akula Server, other than a login request, pass the user's session ID as part of the request to identify the user to the Akula Server. A login request does not pass a session ID but does pass user credentials, such as username and password, and therefore should also use SSL.
Also, many requests either pass data to the Akula Server, or receive data back from the server in the server response. To ensure that all data transactions are secure, make the requests by using SSL and the