Facts about SSL

SSL stands for Secure Socket Layer, and all HTTPS communications are essentially based on SSL tunnel established per SSL certificates. SSL certificates are issued by CAs (Certificate Authorities like GoDaddy) for specific web site (like www.Intelicosmos.com which we are hosting in IIS).

With a SSL certificate will be installed in a web site and with SSL certificate, there is a Private and Public keys which are generated by a CA. When a service in a web site is requested by a user in a form of HTTPS, the browser seeks for a SSL certificate from the web site and if available, requests a verification to the CA issued the certificate and if verified, then browser shows a green padlock on the tab and starts establishing a SSL tunnel between its Tab and the web site.

Also a green padlock is shown in Tab indicating the Web Site and certificates are trustable. If Private Key is stolen or a hacker generated it through very complex math calculations (very hard for sure but not impossible), then SSL tunnel is no longer secure and hacker can sniff whatever data moving through the tunnel.

SSL Architecture

It starts with a Tab hit by a user, then:

1- Browser requests for SSL certificate from the web site

2- Once received the certificates, browser requests  to CA to verify

3 – If verified, browser shows a green padlock on the Tab , then generates a static Symmetric key for that Tab, encrypts it with web site’s Public key and shares it with web site. Web site will decrypt it by its Private key

4- Once Symmetric Key handshaking is completed, SSL tunnel is essentially established between a Tab and web site

Problems with SSL

Vulnerability

While SSL is the world’s current most secure HTTP communication pattern and all browsers are heavily relying on SSL certificates, SSL certificates are vulnerable, due to a simple reason: they (SSL certificates) are static!

• Here is an article from Venafi: “By using forged or compromised keys and certificates, attackers create malicious tunnels into your network where they hide while they conduct surveillance, install malware and ultimately exfiltrate valuable data”
• Another article explains SSL certificates have been hacked: like ‘Hackers stole Google SSL certificate, Dutch firm admits’
• And will be under more attacks according to studies and technology trends (“The threat landscape is evolving, with tried and true phishing attacks leading to an increase in cyber business fraud and compromised privileged cloud credentials” according to Oracle and KPMG Cloud Threat Report 2020)

Wrong Scope

SSL tunnel is a secure tunnel between a browser’s Tab and a web site, no matter how many web services (like Intelicosmos website, RSSL demo web API, RSSL demo web APP etc) are running under that web site. That means, a compromised SSL certificate is a big issue for all web services running under that web site.

Scalability Issue

SSL certificates are not fit to scale or are not a good fit for some industry use cases, like:

• By end of 2021, 161 million domain registered, but only 1.9% of companies are on the cloud. That indicates that a big number of SSL certificates have to be issued, renewed and monitored.
• IoT devices are emerging everywhere, 22 billion connected IoT devices by 2018. SSL certificate is a big challenge for small IoT devices while even small IoT devices may send very sensetive data.
• API calls are rapidly growing, 4.7 billion API requests by 2019. Another example of how SSL Certificates are goingto be bottleneck for security while expanding API industry.
• Blockchains are stretching into more businesses than just Cryptocurrencies and they heavily reliant on encryption and API calls.

What is RSSL?

Before we explain the RSSL, let's strat with definition of Endpoint. An Endpoint is one of below:

• Web APP
• Mobile APP
• Web API
• IoT/Hardware Device
• Desktop Thin Client

Unlike SSL tunnel which established between a browser's Tab and a web site, RSSL tunnel is established between two Endpoints.

More about RSSL:

• RSSL is a rolling certificate which is generated in real-time by an Endpoint and is valid for a short period of time (like 2 minutes but configurable) and is automatically shared to the  Endpoint is trying to communicate
• Unlike SSL which is static certificate and symmetric key, RSSL is dynamic, in-memory and rolling certificate and symmetric key. An Endpoint may have multiple RSSL certificates during its lifetime, but each is valid for a specific period of time and will be expired automatically. The expiry period of a RSSL will be setup for each Endpoint individually. Any two Endpoints, which are going to communicate, will transfer their RSSL certificates and Symmetric key automatically and periodically
• Unlike SSL certificate where browser is responsible for acquiring certificate from web site, validating it with CA, generating a Symmetric key and sharing back to the web site, responsibilities are up to Endpoints (applications) themselves and not browser
• Whether SSL tunnels are already established between browser’s Tab and web site or not, RSSL tunnel can exist regardless. However, when SSL tunnel is established, RSSL is sort of acting inside the SSL tunnel, resulting ultimate security
• In order two Endpoints to communicate under RSSL tunnels, they need to import/reference RSSL SDKs (in JavaScript, C#, Java, Node.JS, Python etc), then two SDKs will be automatically establishing RSSL tunnels between them
• Endpoints can be programmed in different languages (and use the equivalent RSSL SDK), for example, one in JavaScript and another in C#, but SDKs are compatible and are able to work with each other

RSSL Architecture

Bear in mind that, RSSL tunnels can be established with or without SSL tunnels, but when SSL tunnels are available which is our recommendation also, you will get an ultimate security.

If we imported/referenced SDKs into two endpoints, as soon as two endpoints are up (like a webpage is requested by a user), they will automatically generate certificates and symmetric key and handshake. With simple as this, RSSL tunnel is established

Benefits of RSSL

Spotless

RSSL certificates are not static and instead, they are real-time, rotating and in-memory generated, therefore the chance of being hacked is near to zero

Versatility

Endpoints can be programmed in different languages (and use their equivalent RSSL SDK), for example, one in JavaScript and another in C#, and SDKs are compatible and are able to work with each other, so existing apps as well as new apps are all supported

No Key Store

As RSSL certificates (therefore Public, Private & Symmetric keys) are all dynamic, have a short lifecycle and are circulated between two Endpoints only, a lot of dependencies to expensive HSM or Key Management can be easily replaced by RSSL

How To Use RSSL

Here is the instruction on how to use RSSL:

• Any application, existing or new, must import/reference RSSL SDK (The type of SDK which matches with their programming language)
• RSSL SDK’s “rssl(context)” method must be called in start-up
• RSSL SDk’s “rsslencrypt(data)” must be called before sending data to other Endpoint
• RSSL SDk’s “rssldecrypt(data)” must be called after receiving data from the other Endpoint

And here is a video that explains all above with a real demo of RSSL implementation:

Intelicosmos® has already developed RSSL SDKs for common languages like JavaScript, C#, Java, Python and Node.JS to help organizations in improving security of their current endpoints or producing new highly secure endpoints. For more details, refer to RSSL Plans