free
/
freedomboneeee
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

keyserver documentation

This commit is contained in:
Bob Mottram 2017-07-30 18:13:18 +01:00
parent 81be48d180
commit 241ccb9803
2 changed files with 106 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/EN/app_keyserver.org
View File

@ -20,7 +20,7 @@
[[file:images/keyserver.jpg]] [[file:images/keyserver.jpg]]
#+END_CENTER #+END_CENTER
The /web of trust/ is a nice idea, but how trustable is it? If you take a look at how many OpenPGP key servers are out there then there are a two or three main ones and not much else. Can you trust those servers? Who is maintaining them and how often? Is any censorship going on? How hard would they be for adversaries to implant? In terms of technology this infrastructure is quite old and it could have been neglected for a long time. Once vigilant maintainers might have turned lazy and gotten lax with server security, or been recruited over to the dark side. The /web of trust/ is a nice idea, but how trustable is it? If you take a look at how many OpenPGP key servers are out there then there are a two or three main ones and not much else. Can you trust those servers? Who is maintaining them and how often? Is any censorship going on? How hard would it be for adversaries to get implants onto them? In terms of technology this infrastructure is quite old and it could have been neglected for a long time. Once vigilant maintainers might have turned lazy and gotten lax with server security, or been recruited over to the dark side.
For these kinds of reasons you might prefer to run your own web of trust infrastructure. In simple terms it's a database of GPG public keys which provides a way for users to /find out how to communicate with others securely via email/. You can meet in person and exchange public keys via sneakernet on USB drives, but most users of GPG don't do that. Instead they just download the public key for a given email address from one of the key servers. For these kinds of reasons you might prefer to run your own web of trust infrastructure. In simple terms it's a database of GPG public keys which provides a way for users to /find out how to communicate with others securely via email/. You can meet in person and exchange public keys via sneakernet on USB drives, but most users of GPG don't do that. Instead they just download the public key for a given email address from one of the key servers.
@ -37,8 +37,31 @@ Select *Add/Remove Apps* then *keyserver*. You will then be asked for a domain n
After the install has completed go to *Security settings* and select *Create a new Let's Encrypt certificate* and enter the domain name that you are using for the Key server. If the certificate is obtained successfully then you will see a congratulations message. After the install has completed go to *Security settings* and select *Create a new Let's Encrypt certificate* and enter the domain name that you are using for the Key server. If the certificate is obtained successfully then you will see a congratulations message.
* How to use it * How to use it
Interaction with the web user interface is pretty minimal and obvious, but most likely you will also want to be able to use your keyserver from the commandline. To do that use the *--keyserver* option: Interaction with the web user interface is pretty minimal and obvious, but most likely you will also want to be able to use your keyserver from the commandline. To do that use the *--keyserver* option. For example to search for a key on your server:
#+begin_src bash #+begin_src bash
gpg --keyserver [your keyserver domain] --search-keys [email address] gpg --keyserver [your keyserver domain] --search-keys [email address]
#+end_src #+end_src
Or to send a key to it:
#+begin_src bash
gpg --keyserver [your keyserver domain] --send-keys [email address or key ID]
#+end_src
Or to get a key:
#+begin_src bash
gpg --keyserver [your keyserver domain] --recv-keys [email address or key ID]
#+end_src
* Sync with other keyservers
Key servers avoid censorship or errors by gossiping between each other and cross referencing the data. You can define which other servers your key server will gossip with by going to the *Administrator control panel*, selecting *App Settings* then *keyserver* then *Sync with other keyserver*.
It's a good idea not to try to sync with the popular OpenPGP key servers, because those have gigantic databases which may make your server unstable and certainly would make it hard to create backups within a tractable amount of time. This option is mainly intended to sync with other Freedombone systems or small home servers within a particular community.
* Possible problems
OpenPGP key servers are not very well defended from flooding attacks. This means that an adversary could just upload a billion keys to destabilize the server and fill it with nonsense to make it unusable. Since key servers are /fully open to the public/ there isn't anything to prevent that from happening.
Within the Freedombone system there is a watchdog script which keeps track of the key server database size, and disables the key server if that gets too large. Apart from the usual firewall and web server traffic rate limits, this is a crude but probably practical way of defending against flooding.
If a flood attack does happen then really the only way to recover is to restore from the last known good backup, which can be done from the *Administrator control panel*.

84
website/EN/app_keyserver.html
View File

@ -3,7 +3,7 @@
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head> <head>
<!-- 2017-07-28 Fri 22:40 --> <!-- 2017-07-30 Sun 18:12 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="viewport" content="width=device-width, initial-scale=1" />
<title></title> <title></title>
@ -245,13 +245,28 @@ for the JavaScript code in this tag.
</div> </div>
<center> <center>
<h1>Key Server</h1> <h1>OpenPGP Key Server</h1>
</center> </center>
<div class="org-center">
<div class="figure">
<p><img src="images/keyserver.jpg" alt="keyserver.jpg" />
</p>
</div>
</div>
<p> <p>
The usual way in which you obtain GPG public keys for email encryption or other purposes is via a key server. There are a few common ones out there, but it's also possible to run your own key server. The <i>web of trust</i> is a nice idea, but how trustable is it? If you take a look at how many OpenPGP key servers are out there then there are a two or three main ones and not much else. Can you trust those servers? Who is maintaining them and how often? Is any censorship going on? How hard would it be for adversaries to get implants onto them? In terms of technology this infrastructure is quite old and it could have been neglected for a long time. Once vigilant maintainers might have turned lazy and gotten lax with server security, or been recruited over to the dark side.
</p> </p>
<p>
For these kinds of reasons you might prefer to run your own web of trust infrastructure. In simple terms it's a database of GPG public keys which provides a way for users to <i>find out how to communicate with others securely via email</i>. You can meet in person and exchange public keys via sneakernet on USB drives, but most users of GPG don't do that. Instead they just download the public key for a given email address from one of the key servers.
</p>
<div id="outline-container-org9a238e8" class="outline-2">
<h2 id="org9a238e8">Installation</h2>
<div class="outline-text-2" id="text-org9a238e8">
<p> <p>
ssh into the system with: ssh into the system with:
</p> </p>
@ -269,6 +284,69 @@ Select <b>Add/Remove Apps</b> then <b>keyserver</b>. You will then be asked for
After the install has completed go to <b>Security settings</b> and select <b>Create a new Let's Encrypt certificate</b> and enter the domain name that you are using for the Key server. If the certificate is obtained successfully then you will see a congratulations message. After the install has completed go to <b>Security settings</b> and select <b>Create a new Let's Encrypt certificate</b> and enter the domain name that you are using for the Key server. If the certificate is obtained successfully then you will see a congratulations message.
</p> </p>
</div> </div>
</div>
<div id="outline-container-org671d1b4" class="outline-2">
<h2 id="org671d1b4">How to use it</h2>
<div class="outline-text-2" id="text-org671d1b4">
<p>
Interaction with the web user interface is pretty minimal and obvious, but most likely you will also want to be able to use your keyserver from the commandline. To do that use the <b>&#x2013;keyserver</b> option. For example to search for a key on your server:
</p>
<div class="org-src-container">
<pre><code class="src src-bash">gpg --keyserver [your keyserver domain] --search-keys [email address]
</code></pre>
</div>
<p>
Or to send a key to it:
</p>
<div class="org-src-container">
<pre><code class="src src-bash">gpg --keyserver [your keyserver domain] --send-keys [email address or key ID]
</code></pre>
</div>
<p>
Or to get a key:
</p>
<div class="org-src-container">
<pre><code class="src src-bash">gpg --keyserver [your keyserver domain] --recv-keys [email address or key ID]
</code></pre>
</div>
</div>
</div>
<div id="outline-container-org8a015fc" class="outline-2">
<h2 id="org8a015fc">Sync with other keyservers</h2>
<div class="outline-text-2" id="text-org8a015fc">
<p>
Key servers avoid censorship or errors by gossiping between each other and cross referencing the data. You can define which other servers your key server will gossip with by going to the <b>Administrator control panel</b>, selecting <b>App Settings</b> then <b>keyserver</b> then <b>Sync with other keyserver</b>.
</p>
<p>
It's a good idea not to try to sync with the popular OpenPGP key servers, because those have gigantic databases which may make your server unstable and certainly would make it hard to create backups within a tractable amount of time. This option is mainly intended to sync with other Freedombone systems or small home servers within a particular community.
</p>
</div>
</div>
<div id="outline-container-orge9e564a" class="outline-2">
<h2 id="orge9e564a">Possible problems</h2>
<div class="outline-text-2" id="text-orge9e564a">
<p>
OpenPGP key servers are not very well defended from flooding attacks. This means that an adversary could just upload a billion keys to destabilize the server and fill it with nonsense to make it unusable. Since key servers are <i>fully open to the public</i> there isn't anything to prevent that from happening.
</p>
<p>
Within the Freedombone system there is a watchdog script which keeps track of the key server database size, and disables the key server if that gets too large. Apart from the usual firewall and web server traffic rate limits, this is a crude but probably practical way of defending against flooding.
</p>
<p>
If a flood attack does happen then really the only way to recover is to restore from the last known good backup, which can be done from the <b>Administrator control panel</b>.
</p>
</div>
</div>
</div>
<div id="postamble" class="status"> <div id="postamble" class="status">
<style type="text/css"> <style type="text/css">