Table of Contents


Security is a topic that we take very seriously and we have utilized many best practices, reliable proven technology and latest ideas to keep everything safe.

We have compiled a top-level abstract list on how we do some things. This document is purposely kept brief in order to limit the exposure of our underlying systems, but please feel free to contact us if you have any specific questions about anything here.

SSL Certificates

For all our HTTPS traffic we use short-lived SHA256bit certificates with 2048bit keys. Reject downgrade attacks such as SSL2,3. We use HSTS, Perfect Forward Secrecy, and OCSP Stapling. You are welcome to see our servers SSL test results here:

Inter-zone Communication

All internal traffic travelling between zones traverses our mesh VPN protected by 4096 bit keys and managed by our internal CA Servers.


Our system uses an exponentially increasing delay on failed attempts and centralised reporting.


All passwords are hashed in our system. The ones required for HTTP login are encrypted by Argon2, the winner of the Password Hashing Competition (PHC)

On every hash we use: - Random Per Password Salt (With email hashed seasoning) - Off-database site-pepper - High Time, Memory Cost, Parallelism Cost


All admins are required to use Two-factor authentication when signing into the system. Two Factor Authentication is also available for any user accounts using RFC 6238 ( style TOTP (Time Based One-time Passwords) using applications such as Google Authenticator or Microsoft Authenticator.

Server Keys

Anyone who has direct access to any servers is required to use SSH Keys. All systems where keys are not possible, long multi-symbol passwords are used.


We DON'T consider the following items insecure. We completely understand the consequences of enabling these systems but we believe that their benefits outweigh the security implications.

This does NOT mean that we don't monitor activity on either of these, nor does it mean that we don't have automatic reactive systems in place to help ensure uptime in the event of attacks.

IMCP Pings

IMCP (Internet Message Control Protocol) Ping messages (e.g ping There once was a time when IMCP Ping attacks were common, this was related to the packet size vs available bandwidth. Although IMCP Ping attacks may still happen, it is far more useful to enable IMCP replies to correctly establish the status of a server.

SIP / RTP Firewall Block on Default.

Our SIP Servers only run SIP, nothing else. Our RTP Servers run RTP, nothing else.

This means that you WILL see unauthorized traffic hitting your switch, however you will note that the call was blocked because of authentication reasons. This is normal as it is important to see failed traffic as it may be misconfiguration authentication.

5060 is not firewalled, nor are any of our RTP Ports on our RTP Servers.


We have application level logic that identifies malicious activity that will escalate issues upwards through to our IDS systems which will in return feedback firewall rules.

Data Usage

Connex Carrier Services Worldwide LTD is an independent company, not owned by a parent company or affiliates. All data is retained in ConnexCS on ConnexCS servers and is never passed to any 3rd parties. All staff have to abide by company non-disclosure policies and it is made clear that any data breach would be treated with the utmost severity.

Deploying SSL Certificates

The SSL certificate can be deployed on your customer portal with a single click.

  1. Click on Setup> Integrations
  2. Click on Domains
  3. Click on Deploy Certificate

alt text