No. Codavel Mobile CDN has built-in, at its core, a resilient fallback mechanism, where, if the Codavel SDK fails to connect to Codavel Mobile CDN, for any reason, it will transfer the intended requests using regular HTTP/HTTPS to your desired endpoints. With this mechanism, the application or service will keep working as if nothing was out of normal and you will see no performance regressions.
Yes. Codavel Mobile CDN, via the Codavel SDK, allows remote control when the Codavel Mobile CDN is working. To stop an application from using the service, you can use one of the following strategies:
• Via the Codavel SDK, make use of the A/B testing percentage variable to 0, which would cause all traffic to go through regular HTTP. This is the recommended way of achieving the desired intent.
• Wrap the Codavel SDK start over a remotely configured variable, which would cause Codavel Mobile CDN to not start, thus all traffic to go through regular HTTP.
No. Codavel Mobile CDN can be deployed in front of your current CDN deployment. You will not incur in double traffic charge (except for initial requests), because Codavel Mobile CDN behaves as a regular CDN and therefore, it will cache the content, instead of fetching it every time from your current CDN.
Nevertheless, to leverage the full potential of Codavel Mobile CDN while maintaining our current CDN deployment, we recommend taking a look into our multi-CDN strategy section.
Yes. Codavel Mobile CDN can be easily seen as a regular CDN and all its route control can be made in the Codavel SDK. There, you can indicate another CDN as the single content origin, which will be used for all requests.
More complex strategies can be implemented. For example, you can very easily set a source for the content origin that Codavel Mobile CDN must use and set an alternative CDN as a fallback, in case Codavel Mobile CDN fails.
On top of that, you can also specify which requests should be transferred by Codavel Mobile CDN, giving you even more control. For example, you can specify that only image and video requests shall be optimized by Codavel Mobile CDN, leaving all the remaining requests, as for example those related to login or payment, going through your existing method without modifications.
Yes. By default, when Codavel Mobile CDN is enabled on the Codavel SDK, all requests are transferred via the Codavel Mobile CDN. However, with Codavel SDK, you can specify which requests should be transferred via Codavel Mobile CDN. This mechanism is done in the Codavel SDK interceptor, where only requests that match a specific pattern are transferred via Codavel Mobile CDN, with requests that do not match the pattern being transferred using your existing HTTP flow.
Codavel Mobile CDN integrates with your app by intercepting HTTP requests at the HTTP library via the Codavel SDK. The intercepted HTTPS (or HTTP) requests are then sent to the Codavel Mobile CDN cloud servers using an end-to-end encrypted Bolina connection. In the Codavel Mobile CDN cloud servers, if data is not cached, then Codavel Mobile CDN will perform a request to the original URL, as if it was a regular client, using HTTPS (or HTTP if that is the case). Thus, HTTPS requests are always encrypted between all entities when they are passed through the wire.
No. Even though Codavel SDK integrates into your app by attaching an interceptor to the HTTP libraries, it is not required to be the only interceptor enabled. In fact, you can make use of Codavel SDK helper methods to integrate the Codavel SDK interceptor as the last interceptor of the interceptor’s chain. This way, all your existing interceptors, that manage for example your sessions or cookies, will continue to work, while Codavel Mobile CDN is still capable of receiving and managing the transfer itself.
Yes. When properly configured, Codavel SDK will not interfere with your existing monitoring and debugging tools. To achieve this, we recommend that you integrate the Codavel SDK interceptor as the last interceptor in the HTTP library interceptor chain, by using the provided helper methods.
Codavel Mobile CDN cache component relies on the HTTP cache headers, such as Cache-Control, Expires, and Access-Control-Max-Age headers. If no such headers are present, or if those headers indicate that the request should not be cached, then the cache component will not cache those requests.
No. Even though Codavel Mobile CDN acts as an HTTP proxy, the added latency that it introduces is negligible when compared to the benefit it brings by overcoming the issues found on the connection to the client. Moreover, by deploying a caching mechanism, depending on the service, most requests can be cached on the Codavel Mobile CDN cloud servers, meaning that there is a reduced need to fetch data from the content origin.
If your DRM or authentication scheme is based on HTTP headers, then Codavel Mobile CDN will not have any impact on our service. However, if your DRM or authentication scheme consists of creating a unique object for each client, even if they request the same URL, then Codavel Mobile CDN will not be able to cache the object and will need to fetch data directly from your existing endpoint. Still, Codavel Mobile CDN will provide an increase to your network transfer speed, therefore improving your business KPIs, given that it will still improve upon the issues present in the wireless last mile.
Yes. Codavel Mobile CDN 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.
No one, literally no one, not even Codavel. The privacy of your users are Codavel’s top priority. Every byte transferred using Codavel Mobile CDN 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.
No. Servers are more protected with Codavel Mobile CDN due to the new protection layer provided by the service:
Following the recommended architecture, you should block all the requests to your servers except the ones from Codavel Mobile CDN. Doing that, only Codavel Mobile CDN 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 Mobile CDN 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 Mobile CDN 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 Mobile CDN is capable of serving them directly without performing calls to your servers, thus without the intervention of your servers.
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:
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:
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:
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.
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).