Update blog #2 to version 3.2.0.13.
This commit is contained in:
commit
63db90350b
@ -5,7 +5,7 @@
|
||||
<!-- Copyright 2022-2023 Jake Winters -->
|
||||
<!-- SPDX-License-Identifier: BSD-3-Clause-Clear -->
|
||||
|
||||
<!-- Version: 2.0.0.10 -->
|
||||
<!-- Version: 3.2.0.13 -->
|
||||
|
||||
|
||||
<html>
|
||||
@ -33,13 +33,38 @@
|
||||
<body>
|
||||
<h1>Blog - #2</h1>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<h2>Untrusted: The Issue with Decentralisation</h2>
|
||||
<br>
|
||||
<p class="update_date">Posted: 2022-06-30 (UTC+00:00)</p>
|
||||
<p class="update_date">Updated: 2022-10-29 (UTC+00:00)</p>
|
||||
<br>
|
||||
|
||||
<h4>Introduction</h4>
|
||||
<!-- Table of contents. -->
|
||||
<h2 id="toc"><a href="#toc" class="h2"
|
||||
>Table of Contents<a/></h2>
|
||||
<ul>
|
||||
<li><a href="#introduction" class="body-link"
|
||||
>Introduction</a></li>
|
||||
<li><a href="#examples" class="body-link"
|
||||
>Examples</a></li>
|
||||
<ul>
|
||||
<li><a href="#examples-messaging" class="body-link"
|
||||
>Messaging</a></li>
|
||||
</ul>
|
||||
<li><a href="#solution" class="body-link"
|
||||
>Solution</a></li>
|
||||
<li><a href="#conclusion" class="body-link"
|
||||
>Conclusion</a></li>
|
||||
</ul>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
<h2 id="introduction"><a href="#introduction" class="h2"
|
||||
>Introduction</a></h2>
|
||||
<p>A recent trend is seeing people move towards decentralised services and platforms. While this is
|
||||
reasonable and I can understand why they are doing such a thing, they are seemingly doing it without
|
||||
thinking about the possible consequences of doing so. The issue with decentralisation is trust;
|
||||
@ -47,7 +72,12 @@ there is no way to pin a key to a specific person, to ensure that you are commun
|
||||
same person you are supposed to be communicating with. In this article, I will discuss some of the
|
||||
security issues with the decentralised model.</p>
|
||||
<br>
|
||||
<h4>Example: Messaging</h4>
|
||||
<br>
|
||||
|
||||
<h2 id="examples"><a href="#examples" class="h2"
|
||||
>Examples</a></h2>
|
||||
<h3 id="examples-messaging"><a href="#examples-messaging" class="h3"
|
||||
>Messaging</a></h3>
|
||||
<p>When it comes to messaging your contacts on a centralised platform, such as Twitter or Facebook,
|
||||
the keys are pinned to that user account, using the user's password as the method of identification.
|
||||
This approach makes it impossible to log in as a specific user without their password, should it be
|
||||
@ -71,7 +101,10 @@ literally no way to know if the person you are communicating with is the real pe
|
||||
there is no root of trust. This point is fatal; game over. The only way to establish trust again
|
||||
would be to physically meet and exchange keys.</p>
|
||||
<br>
|
||||
<h4>Solution</h4>
|
||||
<br>
|
||||
|
||||
<h2 id="solution"><a href="#solution" class="h2"
|
||||
>Solution</a></h2>
|
||||
<p>I'll cut to the chase; there isn't a definitive solution. The best way to handle this situation
|
||||
is to design your threat model and think about your reasoning for avoiding centralised platforms. Is
|
||||
it lack of trust of a specific company? Is it the possibility of centralised platforms going
|
||||
@ -90,27 +123,29 @@ is who is controlling the location; trust is still present and required.</p>
|
||||
<p>In order to have a root of trust, I have posted my keys to my website, which is protected by
|
||||
multiple layers of security:<br>
|
||||
<br>
|
||||
0. I have provided identification to my domain name registrar, to ensure I can access the website I
|
||||
<ol>
|
||||
<li>I have provided identification to my domain name registrar, to ensure I can access the website I
|
||||
rightfully own, should it be compromised, by providing identification to the domain name
|
||||
registrar.<br>
|
||||
<br>
|
||||
1. I have provided identification to my virtual private server host, to ensure I can access the
|
||||
registrar.</li>
|
||||
<li>I have provided identification to my virtual private server host, to ensure I can access the
|
||||
virtual private servers I rightfully rent, should they be compromised, by providing identification
|
||||
to the virtual private server host.<br>
|
||||
<br>
|
||||
2. I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a
|
||||
to the virtual private server host.</li>
|
||||
<li>I have pinned my website to a globally trusted certificate authority, Let's Encrypt, which is a
|
||||
trusted party to manage TLS certificates and ensure ownership of the domain when connecting to
|
||||
it.<br>
|
||||
it.</li>
|
||||
<li>I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you
|
||||
believe you're connecting to it when you're actually connecting to someone else's.</li>
|
||||
</ol>
|
||||
<br>
|
||||
3. I have enabled DNSSEC on my domain, so it is extremely difficult to spoof my domain to make you
|
||||
believe you're connecting to it when you're actually connecting to someone else's.<br>
|
||||
<br>
|
||||
While not the most secure implementation of a root of trust, it is the most secure implementation
|
||||
<p>While not the most secure implementation of a root of trust, it is the most secure implementation
|
||||
currently available to me. While the domain name registrar or virtual private server host could
|
||||
tamper with my domain and data, they are the most trustworthy parties available. In its current
|
||||
form, decentralisation would make this impossible to implement in any form.</p>
|
||||
<br>
|
||||
<h4>Conclusion</h4>
|
||||
<br>
|
||||
|
||||
<h2 id="conclusion"><a href="#conclusion" class="h2"
|
||||
>Conclusion</a></h2>
|
||||
<p>Do not demand anonymity; demand privacy and control of your own data. Complete anonymity makes it
|
||||
impossible to have a root of trust, and is typically never necessary. It is possible for someone
|
||||
else to hold your keys, without them taking control of them and dictating what you can and cannot do
|
||||
|
Loading…
x
Reference in New Issue
Block a user