Security FAQs

1. Is it safe to use Codavel Performance Service to transfer my customer’s data?

Yes. Codavel Performance Service uses a proprietary network protocol named Bolina to transfer data. This protocol includes end to end encryption, meaning every byte transferred between your app and the Servers are encrypted. Bolina ensures secure communication through two well known and tested open source libraries (OpenSSL for Server Authentication and Libsodium for Key Exchange Protocol and Data Encryption), through algorithms that are used as described in TLS 1.3. It is worth noting that cipher suites, signature algorithms and other parameters that are usually negotiated between client and server during TLS handshake, are pre-selected in Bolina Security Layer. From all the cipher suites available in TLS 1.3, Bolina Security Layer uses the most efficient, fastest and secure algorithms, ChaCha20 for encryption and Poly1303 for authentication.

2. Who can access the data transferred via Codavel Performance Service?

No one, literally no one, not even Codavel. The privacy of your users are Codavel’s top priority. Every byte transferred using Codavel Performance Service is encrypted, meaning no one has access to it. Bolina, our network protocol, uses authenticated encryption with ChaCha20 for encryption and Poly1303 for authentication. 

Bolina uses an Authenticated Encryption with Associated Data (AEAD) algorithm ensuring that all messages are encrypted with the secret key agreed in the previous step and that forged messages are rejected. Using a shared secret of 256 bits, a nonce of 64 bits, and an additional data of 64 bits, Bolina uses stream cipher ChaCha20 for encryption and Poly1305 for message authentication, for all the communications end to end.

ChaCha20 is a high-speed cipher designed to provide 256-bit security. It is considerably faster than AES in software-only implementations (e.g., three times faster on platforms without specific AES hardware). On the other hand, Poly1305 is a high-speed message  authentication code, used to make sure that the transmitted messages have not been tampered. The combination of the ChaCha20 stream cipher with the Poly1305 authenticator (ChaCha20-Poly1305) was selected by Google to secure traffic between the Chrome browser on Android phones and Google’s websites, and is now included in the final version of  TLS 1.3, released on August 2018.

3. My servers are more exposed to attacks when using Bolina?

No. Servers are more protected with Codavel Performance Service due to the new protection layer provided by the service:

  • Only Codavel Performance Service servers access your servers
  • Codavel Performance Service has a dedicated intelligent shield that detects attacks and blocks potential attackers
  • Cached objects are served directly from the Codavel Performance Service


Following the recommended architecture, you should block all the requests to your servers except the ones from Codavel Performance Service. Doing that, only Codavel Performance Service servers have direct access to your servers, so risk of attack to your servers is reduced dramatically, with your servers becoming invisible to the world. 

Notice, you can expose your servers to any other service, such as regular CDNs, which can be used in a fallback event, providing similar levels of exposure.

Dedicated intelligent shield


Codavel Performance Service offers an advanced, intelligent shield component that detects and blocks attackers by analysing their flow. This shield component applies firewall rules, identifies DDoS attacks and applies WAF rules to further identify an attacker. Moreover, the shield component continuously monitors Bolina packets to identify potential protocol attacks.

Once an attacker is detected, he is added to a suspicious list and future attack attempts are rejected applying rate limiting. Moreover, Codavel Performance Service scales to adapt to the current needs, therefore, it will scale to absorb a potential attack.

The only way to send traffic to your servers is being a legitimate end-user app, using Bolina correctly and not belonging to any Codavel’s block list. 

Serving cached objects


When objects requested are cached, Codavel Performance Service is capable of serving them directly without performing calls to your servers, thus without the intervention of your servers.

4. Does Bolina follow TLS1.3 guidelines and how does Codavel Performance 0-RTT work?

Yes. Bolina protocol uses standard open-source cryptographic libraries, namely OpenSSL and Libsodium, which are used unmodified. Bolina security follows the TLS 1.3 guidelines for establishing secure connections, using cryptographic algorithms covered by the FIPS 140-2 recommendations.


Bolina provides two handshake modes, which are based on TLS 1.3:


  • A full 1-RTT handshake in which the client is able to send protected application data after one round trip time;
  • A 0-RTT handshake in which the client is able to send protected application data immediately, using information learned from a prior connection established with a full handshake.

In both modes, the server is authenticated, but the client remains anonymous.


1-RTT Handshake


In 1-RTT handshake mode, client starts by sending a ClientHello message to server, containing key shares. Server replies to the client with a ServerHello message, containing key shares and a certificate chain, signed with server’s RSA/ECDSA Private key. After this message exchange, client verifies server identity, ensuring that:

  • Certificates are not expired;
  • Chain of trust is valid and signed by a trusted certificate authority;
  • Certificates are valid for the domain;
  • Signature on ServerHello message matches server RSA/ECDSA Public Key.

Using their own X25519 Private Key and the other peer’s X25519 Public Key, both client and server compute a shared secret, aborting the negotiation if it is the all-zero value. From the shared secret, and from X25519 Public Keys, both peers derive a symmetric key to send and receive encrypted application data over the connection. In 1-RTT mode, client and server can start sending protected application data after 1-RTT and 1.5-RTT, respectively. 

0-RTT Handshake


When a client is establishing a connection to a known server (i.e. a server to which the client has already connected in the past), it can establish a secure connection in a 0-RTT handshake. To achieve this, the client adds 0-RTT data (data that allows the server to map a symmetric key) to the ClientHello message and uses a shared secret, obtained in a previous handshake, to authenticate the server and to encrypt the application data, that is sent at the same time as the ClientHello message. The server can decrypt the received data using the symmetric key that is identified in the 0-RTT data, and encrypt messages to the client with the same key. Client and server also send to each other a new key share to use in a future 0-RTT handshake.

In Bolina, 0-RTT handshake ensures equivalent security guarantees to those achieved with 1-RTT handshake. Specifically:

  • For each new connection, a new ephemeral session key is generated through a new run of the Diffie-Hellman key exchange algorithm. This means that if a session key is compromised, it cannot be used to decrypt messages from prior or future sessions. 
  • The guarantees against a replay attack on the 0-RTT handshake messages is provided by a unique value, which is encrypted and sent by the server in a prior connection, and which a client can use only once in a 0-RTT handshake message. Messages sent by a client that reuse this value will be ignored by the server.

5. I am currently using HTTP with SSL, how does it compare with Bolina from a security perspective?

With Bolina you get the same level of privacy and encryption as HTTP with SSL. Moreover, the Bolina handshake is optimized, pre selecting the cipher suites, signature algorithms and other parameters. This optimization enables the reduction of the number of messages transmitted between the mobile device and the Service and, by selecting the most efficient parameters for mobile, provides a significantly faster encryption and decryption maintaining the strong security.

6. Does Codavel Performance Service replace HTTP+TLS+SSL?

Codavel’s proprietary protocol – Bolina – does not replace HTTP. Bolina is integrated with HTTP, with no required changes to HTTP requests. Bolina can be seen as a transport tunnel that can be used to accelerate every type of data (irrespective of the protocol, being HTTP, FTP, DNS or other).