<h1>Sensitive .onion Services: Self-Host or Host Remotely ? </h1>
</div>
</div><!-- /row -->
</div><!-- /container -->
</div><!-- /grey -->
<!-- +++++ Second Post +++++ -->
<divid="anon3">
<divclass="container">
<divclass="row">
<divclass="col-lg-8 col-lg-offset-2">
<h2><b>The Context </b></h2>
<p>A popular debate that keeps reoccuring, is where exactly can you run sensitive .onion services.</p>
<p>It comes with 2 challenges:</p>
<ol>
<li><p>Running the service, with as much uptime as possible (making sure it keeps running in case of takedowns)</p></li>
<li><p>Making sure you can't be traced back as the owner/administrator of the server</p></li>
</ol>
<p>Out of those requirements, we have 2 possibilities as to where you can run a sensitive service.</p>
</div>
</div><!-- /row -->
</div><!-- /container -->
</div><!-- /white -->
<divid="anon2">
<divclass="container">
<divclass="row">
<divclass="col-lg-8 col-lg-offset-2">
<h2><b>Self Hosting : Full Physical Control but Risky!</b></h2></br></br>
<imgsrc="1.png"class="imgRz">
<b>Pros:</b>
<p>Everyone has an internet connection, and if you live in a country that does not actively sensor the tor network, it can be interesting to host your own physical server which runs your hidden .onion service</p>
<p>If you have your own physical server at home, it means you have complete control over the physical proximity of the server itself. as i detailed in <ahref="../physicalsecurity/index.html">my tutorial on physical security</a> there are many things you can do to detect if an adversary is breaking into your home to try and find if you host a hidden service (such as movement detection, unauthorized ssh detection, unauthorized USB interaction detection, etc.)</p>
<p>In short, it's ideal if the technology is perfect and never has any flaws, but you can't ever be sure of that, (for example: <ahref="https://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-against-tor-users-42e566defce8">Tor had security flaws in the past</a>)</p>
</br>
</br>
<b>Cons:</b>
<p>Almost everyone has an internet connection at home, that is tied to your real name. Due to that fact alone, most people refuse to host anything sensitive locally.</p>
<p>The strategy here is <b>"I use secure technology, come at me!"</b>, if there is any undisclosed flaw/ 0day vulnerability in anything related to the technology used (tor, veracrypt, etc), an adversary could reveal the location of the server, and try to get their hands on the server.</p>
<p> If the adversary has the ability to crack open the security of the technology used (very unlikely but possible), you're screwed, because the server sits at your home, and they 100% know it is yours in case if the technology fails to protect your service along the way.</p>
</div>
</div><!-- /row -->
</div><!-- /container -->
</div><!-- /white -->
<!-- +++++ Second Post +++++ -->
<divid="anon1">
<divclass="container">
<divclass="row">
<divclass="col-lg-8 col-lg-offset-2">
<h2><b>Remote Hosting: No Physical Control but Safer!</b></h2></br></br>
<imgsrc="2.png"class="imgRz">
<b>Cons:</b>
<p>Since the Idea here is to run the sensitive service (and most of the time, it's not allowed by the cloud provider), <b>If there is no redundancy / high availability, The longevity of the service would depend on how long the service remains unnoticed by the cloud provider.</b></p>
<p>If the longevity of the service is of concern, you have to take into account that the service is very likely to get taken down regularly. So to avoid downtimes, <b>you will have to scale up and implement high availability, this is multiplying the costs per new server</b></p>
<p>Since the goal is for a service to remain undetected for as long as possible on each server, you will have to stay away from VPSes as their kernels often come with monitoring modules, <b>you will need a dedicated server, with the ability to upload your custom ISO</b></p>
<p>You will also need to monitor for any physical interaction with the server, in order to protect the plausible deniability inside the server, <b>for any unauthorized change or interaction by the cloud provider, there must be an immediate emergency shutdown to be triggered.</b></p>
<p>And you will need to perform integrity checks after each unauthorized server maintenance to make sure that there are no spyware installed on your server, that may compromise the confidentialtiy from the cloud provider itself.</p>
<p>In theory, since the server is not there physically with you, you can't fully protect it physically, <b>you can't just encrypt all of the contents of the RAM to protect against cold boot attacks</b>.</p>
</br>
</br><b>Pros:</b>
<p>As i have detailed in my tutorial on <ahref="../anonymousremoteserver/index.html">how to acquire remote servers anonymously</a>, if you make sure that you anonymously:</p>
<ol>
<li>Create an account on the cloud provider (via TOR)</li>
<li>Pay for the server (via Monero)</li>
<li>Access the server (ssh through tor)</li>
</ol>
<p>You will be safe to assume that whatever happens on that server, it won't get tied back to you</p>
<p>The strategy here is <b>"Whatever I do, I do it as far away from my real identity!"</b>, this anonymity safeguard is what many consider worth all the trouble mentionned before. </p>
