April changes in the client code
As a result of our Core team’s work, today Universa network no longer depends on ICANN or third-party SSL certification centers. Moreover, we brought all our security-related findings together and realized that domain names are not needed to keep the network running, as nodes do not use them for ordinary work and communication.
A little intro
As we wrote earlier, our domain, universa.io, was taken away by a US court ruling (https://medium.com/universablockchain/universablockchain-com-new-home-a1fc5092fbdd). A company with a similar name filed an objection to our trademark application, which we submitted in January 2018. The company is in the US, the court is in the US, and ICANN is also in the US — this is why they were able to take away our domain name, even though that company was six months behind us in trademark filing! And neither our company nor .IO domain have nothing to do with the US either. Even our domain registrar in New Zealand was surprised, as they were never notified about domain owner change. That’s why we now reside at universablockchain.com. But we learned our lesson and we realize that a domain name can be taken away by a registrar or by ICANN at any time. Besides, HTTPS protocol uses SSL/TLS certificates, which are issued by third-party organizations and can easily be recalled as well. We had been thinking for some time on how our network communicates, and when we got into this situation, our team was finally motivated to put all these findings together.
The Internet and the browsers have recently declared a big war on unsecured connections. (https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/). For example, it is impossible to send a JSON RPC request from an https page to an http address. Here, an interesting logical paradox emerges:
1. For a client working inside a browser to send a request, the target node must respond using HTTPS.
2. To respond using HTTPS, the node must have a certificate issued by a third-party certification authority. You could go with a self-signed certificate, of course, but browsers do not like this due to extra risk.
3. To get a certificate from the certification authority, you must supply the domain name for which the certificate is issued. You cannot get an SSL certificate with just an IP address.
4. And domains are under central control by ICANN. Which can take away a domain name without even notifying the registrar.
Turns out the entire system needs to be changed.
What we did
We modified the code so that our nodes can now talk to each other by IP addresses, without any HTTPS. You might think this is insecure, but that’s not true. We originally encrypted the connection and authenticated using Universa’s own encryption mechanisms. Our network and all client interaction have long been using in-house signing and encryption algorithms independent from SSL.
Version 3.9.9 of our code base in Java, including node software, uniclient, Java API and updated UMI library, includes all the latest developments related to establishing and maintaining network connection — this logic has been working for some time in the nodes and tested under load; now it is time to upgrade all the clients.
● There are no more dependencies and domain names for the nodes, which could be substituted via DNS hijacking, lost by the domain registrar or even withdrawn by ICANN;
● Similarly, no more dependencies on SSL/TLS certificates or third-party certification authorities — the system relies on Universa’s own keys. And no more resources wasted due to double encryption, when Universa traffic was first encrypted or signed at Universa level, than at TLS layer.
Network topology
In addition to all of the above measures, network topology identification is now consensus-based (in case some of the nodes are maliciously overrun), and the topology is maintained and regenerated for all subsequent client sessions (again relying solely on Universa cryptographic keys). We made the nodes report network topology using the IP address and host name at the same time. Or rather, the nodes have been doing this for a long time, now ordinary clients can work with this advanced topology.
The topology is now stored on the hard drive in ~/.universa/topologies/ folder. If you need to create your own test network, it will have its own topology, which can be stored in a separate file inside the ~/.universa/topologies/ folder.
The “starting topology” for our network comes by default, even in the API, and there is no need to update even the github files when 20 or more new nodes appear — on the next launch the client working via Java API will contact any node from the starting topology, discover the current network status and update it in ~/.universa/topologies.
What it all comes down to
Our team have been working to prevent any [theoretical possibility] (https://medium.com/@universa_blockchain/%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD%D1%83-universa-%D0%BD%D0%B5-%D1%81%D1%82%D1%80%D0%B0%D1%88%D0%BD%D0%B0-%D0%B0%D1%82%D0%B0%D0%BA%D0%B0-51-6a2e68f3c43d) of blocking or otherwise interfering with the work of Universa network and our nodes. And that’s not all — you can expect more news regarding the development of the network and code base shortly.
