[Proposal] SSL / TLS Replacement

HOPR DAO v0.3
1

By using the HOPR protocol for privacy and security, a new type of blockchain enabled certificate system/authority could be created to solve some of the issues with current SSL / TLS technologies which could improve online transaction security and reduce the maintenance and overhead on such things as certificates expiring, etc.

The intent for this proposal is to replace use-cases for TLS connections with connections over HOPR which would remove the reliance on a certificate authority and add metadata privacy. This could help alleviate certificate management and human error type issues which occur with the current standard.

Implementation of this proposal would likely require partnerships and/or grants to create the infrastructure necessary to mimic certificate authority functionality over the HOPR protocol.

The intention of this proposal may be best described with an example…Here is a real world example. The healthcare system in the USA relies on these certificates when passing healthcare data between systems, say you have 10k clients sending data to a middleware system and data center, then that middleware system prepares and sends the required data to a public health authority. Let’s say the data is patient immunization records during a pandemic. When there are numerous servers along that chain, simply managing the certificates can be a pain point and even a single point of failure if mismanaged. Sometimes these certificates are owned by government or other entities so managing them is not possible. Adding metadata privacy and decentralizing the role of Certificate Authority could better automate that process and remove some of the human error.

8 Likes
2

Great Idea!!

3

Hi @Emmerson_Biggins could you add some specific problems that you’re trying to solve here? I think this could work really nicely along with some anonymous credential schemes that others are working on. E.g. Panther Protocol.

4

Hey @SCBuergal sure, no problem! Here is a real world example. The healthcare system in the USA relies on these certificates when passing healthcare data between systems, say you have 10k clients sending data to a middleware system and data center, then that middleware system prepares and sends the required data to a public health authority. Let’s say the data is patient immunization records during a pandemic. When there are numerous servers along that chain, simply managing the certificates can be a pain point and even a single point of failure if mismanaged. Sometimes these certificates are owned by government or other entities so managing them is not possible. Adding metadata privacy and decentralizing the role of Certificate Authority could better automate that process and remove some of the human error.

Another example could simply be the tidal wave of new IoT devices coming to market. Effectively managing secure transactions with these devices seems like a bottleneck that this type of solution could solve.

Side note: I saw a pic of you at EthDenver with the Panther Protocol folks and looked them up. Could be an interesting collaboration. :)

1 Like
5

So you are proposing to replace use-cases for TLS connections with connections over HOPR which would remove the reliance on a certificate authority and add metadata privacy on top?

opportunistic cc @Lukas

6

Yep, I believe that’s it in a nutshell. Thanks for distilling that down to one sentence. ;)

4 Likes
7

I like your idea, but from the technical side it is not very clear how to implement it

8

Thanks for the suggestion @Emmerson_Biggins. If you wanted to make this a valid proposal, I’d suggest you add the information from your follow-up post with the specific usecase to flesh out your original proposal. Some implementation context would be helpful too. You can find more in the validity guidelines. Don’t forget to edit your post title to include “[Proposal]” when you’d like to make it official.

9

Thx for the proposal @Emmerson_Biggins

Re: CAs (Certificate Authorities)

As HOPR uses public keys to address peers, there is indeed no (central) CA necessary because the public key of the recipient is already known because it is equal to the address. So the publication of public keys is done.

In general CAs, also handle various other (human) tasks, such as revocations of public keys because users have lost them or they got compromised (= in control of some adversary). In case of HOPR, this turns into a problem because the sender of a message somehow needs to get notified that the recipient has migrated to a different address, hence HOPR nodes need to subscribe to service that spreads revocation announcements.

Another task of CAs is to create a link between hard-to-remember public keys and human-readable domain names.

To achieve both goals, I recommend to deeply integrate the ENS system and also address relays by their ENS name such that users can manage to which key the domain resolves.

Re: TLS / SSL

HOPR uses a specific packet format to encapsulate data that is sent through the network. Using this packet format makes sure that apart from the intended relay nodes and the recipient, no one else is able to process the packet. If a packet gets corrupted, the probability that any of them are able to “understand” the packet, is negligible (~= 0).

So, if the recipient of the packet is also the designated recipient of the message, then HOPR already fulfills the two main security goals of TLS, which are confidentiality and integrity.

Please note that this does not apply if the recipient of the packet acts as a gateway service (aka “exit node”) and forwards message to the outside of the HOPR network. In this case, sender and recipient of the message need to establish a secure channel elsewise. @Emmerson_Biggins if you consider this the main use case, then we should rephrase the description.

Hope that this description made things more clear. Please let me know if things remain unclear.

2 Likes
10

Hey! @robert Thanks for the insightful response. Any feedback you could give on modifying the description of the proposal would be helpful and appreciated. The intent here is to solve the real world problem of certificate management and expiration issues which can cause down-time with data flow between systems. Maybe someone just forgot to renew or update a certificate for example but if the certificate is managed by a different entity or even a different department within the same company, best-practices or a quick resolution may not be possible. With-in the healthcare system in the US, this type of disruption can cause quality of care issues so removing some of the human error from this equation is worth exploring.

11

The idea is attractive, but I don’t understand how HOPR could solve it.

@Emmerson_Biggins How is currently HOPR data encrypted? Does it use the same Diffie-Hellman symmetric key exchange mechanism as TLS does?
How will you make sure that data comes from the right server, and the right domain name? This is solved using certificate today.
Which of the HOPR feature could represent an alternative to these certificates? Say differently, how would we be able to generate those certificates using the HOPR protocol?