mirror of
https://github.com/freedombox/FreedomBox.git
synced 2026-01-28 08:03:36 +00:00
Removed generated documentation.
This commit is contained in:
Nick Daly
parent
9bdc867375
commit
6bfe88596e
@ -1,625 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<meta name="generator" content="Docutils 0.7: http://docutils.sourceforge.net/" />
|
||||
<title>Santiago</title>
|
||||
<style type="text/css">
|
||||
|
||||
/*
|
||||
:Author: David Goodger (goodger@python.org)
|
||||
:Id: $Id: html4css1.css 6253 2010-03-02 00:24:53Z milde $
|
||||
:Copyright: This stylesheet has been placed in the public domain.
|
||||
|
||||
Default cascading style sheet for the HTML output of Docutils.
|
||||
|
||||
See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
|
||||
customize this style sheet.
|
||||
*/
|
||||
|
||||
/* used to remove borders from tables and images */
|
||||
.borderless, table.borderless td, table.borderless th {
|
||||
border: 0 }
|
||||
|
||||
table.borderless td, table.borderless th {
|
||||
/* Override padding for "table.docutils td" with "! important".
|
||||
The right padding separates the table cells. */
|
||||
padding: 0 0.5em 0 0 ! important }
|
||||
|
||||
.first {
|
||||
/* Override more specific margin styles with "! important". */
|
||||
margin-top: 0 ! important }
|
||||
|
||||
.last, .with-subtitle {
|
||||
margin-bottom: 0 ! important }
|
||||
|
||||
.hidden {
|
||||
display: none }
|
||||
|
||||
a.toc-backref {
|
||||
text-decoration: none ;
|
||||
color: black }
|
||||
|
||||
blockquote.epigraph {
|
||||
margin: 2em 5em ; }
|
||||
|
||||
dl.docutils dd {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
/* Uncomment (and remove this text!) to get bold-faced definition list terms
|
||||
dl.docutils dt {
|
||||
font-weight: bold }
|
||||
*/
|
||||
|
||||
div.abstract {
|
||||
margin: 2em 5em }
|
||||
|
||||
div.abstract p.topic-title {
|
||||
font-weight: bold ;
|
||||
text-align: center }
|
||||
|
||||
div.admonition, div.attention, div.caution, div.danger, div.error,
|
||||
div.hint, div.important, div.note, div.tip, div.warning {
|
||||
margin: 2em ;
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.admonition p.admonition-title, div.hint p.admonition-title,
|
||||
div.important p.admonition-title, div.note p.admonition-title,
|
||||
div.tip p.admonition-title {
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
div.attention p.admonition-title, div.caution p.admonition-title,
|
||||
div.danger p.admonition-title, div.error p.admonition-title,
|
||||
div.warning p.admonition-title {
|
||||
color: red ;
|
||||
font-weight: bold ;
|
||||
font-family: sans-serif }
|
||||
|
||||
/* Uncomment (and remove this text!) to get reduced vertical space in
|
||||
compound paragraphs.
|
||||
div.compound .compound-first, div.compound .compound-middle {
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
div.compound .compound-last, div.compound .compound-middle {
|
||||
margin-top: 0.5em }
|
||||
*/
|
||||
|
||||
div.dedication {
|
||||
margin: 2em 5em ;
|
||||
text-align: center ;
|
||||
font-style: italic }
|
||||
|
||||
div.dedication p.topic-title {
|
||||
font-weight: bold ;
|
||||
font-style: normal }
|
||||
|
||||
div.figure {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
div.footer, div.header {
|
||||
clear: both;
|
||||
font-size: smaller }
|
||||
|
||||
div.line-block {
|
||||
display: block ;
|
||||
margin-top: 1em ;
|
||||
margin-bottom: 1em }
|
||||
|
||||
div.line-block div.line-block {
|
||||
margin-top: 0 ;
|
||||
margin-bottom: 0 ;
|
||||
margin-left: 1.5em }
|
||||
|
||||
div.sidebar {
|
||||
margin: 0 0 0.5em 1em ;
|
||||
border: medium outset ;
|
||||
padding: 1em ;
|
||||
background-color: #ffffee ;
|
||||
width: 40% ;
|
||||
float: right ;
|
||||
clear: right }
|
||||
|
||||
div.sidebar p.rubric {
|
||||
font-family: sans-serif ;
|
||||
font-size: medium }
|
||||
|
||||
div.system-messages {
|
||||
margin: 5em }
|
||||
|
||||
div.system-messages h1 {
|
||||
color: red }
|
||||
|
||||
div.system-message {
|
||||
border: medium outset ;
|
||||
padding: 1em }
|
||||
|
||||
div.system-message p.system-message-title {
|
||||
color: red ;
|
||||
font-weight: bold }
|
||||
|
||||
div.topic {
|
||||
margin: 2em }
|
||||
|
||||
h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
|
||||
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
|
||||
margin-top: 0.4em }
|
||||
|
||||
h1.title {
|
||||
text-align: center }
|
||||
|
||||
h2.subtitle {
|
||||
text-align: center }
|
||||
|
||||
hr.docutils {
|
||||
width: 75% }
|
||||
|
||||
img.align-left, .figure.align-left, object.align-left {
|
||||
clear: left ;
|
||||
float: left ;
|
||||
margin-right: 1em }
|
||||
|
||||
img.align-right, .figure.align-right, object.align-right {
|
||||
clear: right ;
|
||||
float: right ;
|
||||
margin-left: 1em }
|
||||
|
||||
img.align-center, .figure.align-center, object.align-center {
|
||||
display: block;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
.align-left {
|
||||
text-align: left }
|
||||
|
||||
.align-center {
|
||||
clear: both ;
|
||||
text-align: center }
|
||||
|
||||
.align-right {
|
||||
text-align: right }
|
||||
|
||||
/* reset inner alignment in figures */
|
||||
div.align-right {
|
||||
text-align: left }
|
||||
|
||||
/* div.align-center * { */
|
||||
/* text-align: left } */
|
||||
|
||||
ol.simple, ul.simple {
|
||||
margin-bottom: 1em }
|
||||
|
||||
ol.arabic {
|
||||
list-style: decimal }
|
||||
|
||||
ol.loweralpha {
|
||||
list-style: lower-alpha }
|
||||
|
||||
ol.upperalpha {
|
||||
list-style: upper-alpha }
|
||||
|
||||
ol.lowerroman {
|
||||
list-style: lower-roman }
|
||||
|
||||
ol.upperroman {
|
||||
list-style: upper-roman }
|
||||
|
||||
p.attribution {
|
||||
text-align: right ;
|
||||
margin-left: 50% }
|
||||
|
||||
p.caption {
|
||||
font-style: italic }
|
||||
|
||||
p.credits {
|
||||
font-style: italic ;
|
||||
font-size: smaller }
|
||||
|
||||
p.label {
|
||||
white-space: nowrap }
|
||||
|
||||
p.rubric {
|
||||
font-weight: bold ;
|
||||
font-size: larger ;
|
||||
color: maroon ;
|
||||
text-align: center }
|
||||
|
||||
p.sidebar-title {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold ;
|
||||
font-size: larger }
|
||||
|
||||
p.sidebar-subtitle {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
p.topic-title {
|
||||
font-weight: bold }
|
||||
|
||||
pre.address {
|
||||
margin-bottom: 0 ;
|
||||
margin-top: 0 ;
|
||||
font: inherit }
|
||||
|
||||
pre.literal-block, pre.doctest-block {
|
||||
margin-left: 2em ;
|
||||
margin-right: 2em }
|
||||
|
||||
span.classifier {
|
||||
font-family: sans-serif ;
|
||||
font-style: oblique }
|
||||
|
||||
span.classifier-delimiter {
|
||||
font-family: sans-serif ;
|
||||
font-weight: bold }
|
||||
|
||||
span.interpreted {
|
||||
font-family: sans-serif }
|
||||
|
||||
span.option {
|
||||
white-space: nowrap }
|
||||
|
||||
span.pre {
|
||||
white-space: pre }
|
||||
|
||||
span.problematic {
|
||||
color: red }
|
||||
|
||||
span.section-subtitle {
|
||||
/* font-size relative to parent (h1..h6 element) */
|
||||
font-size: 80% }
|
||||
|
||||
table.citation {
|
||||
border-left: solid 1px gray;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docinfo {
|
||||
margin: 2em 4em }
|
||||
|
||||
table.docutils {
|
||||
margin-top: 0.5em ;
|
||||
margin-bottom: 0.5em }
|
||||
|
||||
table.footnote {
|
||||
border-left: solid 1px black;
|
||||
margin-left: 1px }
|
||||
|
||||
table.docutils td, table.docutils th,
|
||||
table.docinfo td, table.docinfo th {
|
||||
padding-left: 0.5em ;
|
||||
padding-right: 0.5em ;
|
||||
vertical-align: top }
|
||||
|
||||
table.docutils th.field-name, table.docinfo th.docinfo-name {
|
||||
font-weight: bold ;
|
||||
text-align: left ;
|
||||
white-space: nowrap ;
|
||||
padding-left: 0 }
|
||||
|
||||
h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
|
||||
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
|
||||
font-size: 100% }
|
||||
|
||||
ul.auto-toc {
|
||||
list-style-type: none }
|
||||
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="document" id="santiago">
|
||||
<h1 class="title">Santiago</h1>
|
||||
<h2 class="subtitle" id="less-discoverable-discovery">Less Discoverable Discovery?</h2>
|
||||
|
||||
<!-- -*- mode: rst; fill-column: 80; mode: auto-fill; -*- -->
|
||||
<div class="section" id="disclaimer">
|
||||
<h1>Disclaimer</h1>
|
||||
<p><strong>The following is an ugly hack. Beware!</strong></p>
|
||||
</div>
|
||||
<div class="section" id="santiago-s-map">
|
||||
<h1>Santiago's Map</h1>
|
||||
<p>Santiago manages service discovery between FreedomBoxen, coordinating
|
||||
connections between arbitrary servers and services. In essence, A requests a
|
||||
service from B, B replies with the service's location, and A uses that location
|
||||
for the service.</p>
|
||||
<ol class="arabic simple">
|
||||
<li>A sends a signed (and encrypted?) message to B's Santiago, requesting
|
||||
information, in the form of:<ul>
|
||||
<li>Will <em>X</em> do <em>Y</em> for me?</li>
|
||||
<li>Optional: Reply to my Santiago at <em>Z</em>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>If B does not recognize A or does not trust A, it stays silent.</li>
|
||||
<li>If B recognizes and trusts A, it replies with a signed (and encrypted?)
|
||||
message to A's Santiago, giving the location of A's usable service. If no
|
||||
service is available, it replies with a rejection.</li>
|
||||
</ol>
|
||||
<p>In a nutshell, that's the important part. There are additional details to
|
||||
manage, but they're implied and built on the system above.</p>
|
||||
<div class="section" id="our-cheats">
|
||||
<h2>Our Cheats</h2>
|
||||
<p>Right now, we're cheating. We start by pairing boxes, exchanging both
|
||||
box-specific PGP keys and Tor Hidden Service IDs. This allows boxes to trust
|
||||
and communicate with one another, regardless of any adverserial interference.
|
||||
Or, rather, any adverserial interference will be obvious and ignorable.</p>
|
||||
</div>
|
||||
<div class="section" id="message-exchange">
|
||||
<h2>Message Exchange</h2>
|
||||
<p>The Santiago service is running on <em>B</em>, waiting for connections. When it
|
||||
receives a request message, that message must be signed by a known and trusted
|
||||
party. If it is acceptably signed (with a known, and valid ID), <em>B</em> will
|
||||
reply to <em>A</em>'s Santiago with an acceptably signed message.</p>
|
||||
<p>The contents of the request message are as follows:</p>
|
||||
<ul class="simple">
|
||||
<li>I am requesting service <em>X</em>.</li>
|
||||
<li>I am requesting that the service be performed by <em>Y</em>.</li>
|
||||
<li>Optional: Reply to this message at <em>Z</em>.</li>
|
||||
</ul>
|
||||
<p>The message is signed by <em>A</em>, and optionally encrypted (if the message is
|
||||
proxied, it must contain a "To" header). If <em>A</em> includes a location stanza,
|
||||
<em>B</em> MUST respect that location in its response and update that location for
|
||||
its Santiago service from <em>A</em> going forward.</p>
|
||||
<p>In this document, I elide the Santiago acknowledgements (because they add a lot
|
||||
of unnecessary noise - we can assume communication failures are failures of
|
||||
acknolwedgement receipt). But, after each message that needs a response, an
|
||||
acceptably signed acknowledgement message is returned. Otherwise the sender
|
||||
preferentially moves on to the recipient's next Santiago address after a
|
||||
sufficient amount of time has passed. An example of this communication, with
|
||||
these details specified, follows:</p>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">I'll gladly serve <em>X</em> for you, at <em>Z</em>, my good fellow.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">(No response)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body"><em>(using a different Santiago address)</em> I'm serving <em>X</em> for <em>A</em> at <em>Z</em>.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">(Acknowledgment)</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="storing-service-data-and-network-structure">
|
||||
<h2>Storing Service Data and Network Structure</h2>
|
||||
<p>How are these data stored, to prevent both A and B from having to dance the
|
||||
Santiago for each and every request?</p>
|
||||
<p>Each node contains two dictionaries/hash-tables listing (1) what they serve and
|
||||
who they serve it to, and (2) what services they use, who from, and where that
|
||||
service is located.</p>
|
||||
<div class="section" id="what-i-host-and-serve">
|
||||
<h3>What I Host and Serve</h3>
|
||||
<p>I offer these services to others.</p>
|
||||
<p>These data are stored as pair of dictionaries:</p>
|
||||
<ul>
|
||||
<li><p class="first">The GPG ID to Service dictionary. This lists which service each user is
|
||||
authorized for:</p>
|
||||
<pre class="literal-block">
|
||||
0x0928: [ "proxy": "proxy", "wiki": "wiki",
|
||||
"drinking buddy": "drinking buddy" ]
|
||||
0x7747: [ "wiki": "wiki", "proxy": "restricted_proxy" ]
|
||||
</pre>
|
||||
</li>
|
||||
<li><p class="first">The Service to Location dictionary. This lists the locations each service
|
||||
runs on:</p>
|
||||
<pre class="literal-block">
|
||||
"wiki": [ 192.168.1.1, "superduperwiki.onion" ]
|
||||
"proxy": [ 8.8.8.8 ]
|
||||
"restricted_proxy": [ 4.4.4.4 ]
|
||||
</pre>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="others-services-i-know-of">
|
||||
<h3>Others' Services I Know Of</h3>
|
||||
<p>I consume these services, they are offered by others.</p>
|
||||
<p>These data are stored as a triple-key dictionary, with the following mappings:</p>
|
||||
<pre class="literal-block">
|
||||
Service X: { GPG ID1: [ location, location, location ],
|
||||
GPG ID2: [ location, location ], }
|
||||
Service Y: { GPG ID2: [ location, location, location ],
|
||||
GPG ID3: [ location, location ], }
|
||||
</pre>
|
||||
<p>This allows fast lookup from the service desired to the users that host the
|
||||
service, to the actual locations that service is offered. This allows the user
|
||||
to quickly decide which service provider to use and to try all locations
|
||||
controlled by that service provider very quickly and easily.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="data-use">
|
||||
<h2>Data Use</h2>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">TODO:</th><td class="field-body">Revise to reduce communication to logical minimum number of connections,
|
||||
exchanges, and communications.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>When <em>A</em> is connecting to <em>B</em>'s service, it will attempt to connect to that
|
||||
service, which B will validate before permitting the connection. If the service
|
||||
is non-responsive, <em>A</em> will query <em>B</em> for the service. If <em>B</em> is generally
|
||||
non-responsive, <em>A</em> will move on to <em>C</em>. <em>A</em> will ask <em>C</em> for the service. If
|
||||
<em>C</em> cannot provide the service, <em>A</em> will ask <em>C</em> to request the service from
|
||||
<em>B</em>. If <em>C</em> can reach <em>B</em> and <em>B</em> authorizes <em>A</em>, <em>B</em> will respond
|
||||
affirmatively to <em>A</em> with the service's location.</p>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">(Connecting to Service!)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B:</th><td class="field-body">(Validating Service and rejecting for some reason, e.x., A hasn't been
|
||||
reauthorized for this service recently enough, and because it's Wednesday.)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">(No response)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">Will you serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">(No response, A can't reach B's Santiago.)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> C:</th><td class="field-body">Will you serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> A:</th><td class="field-body">No!</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> C:</th><td class="field-body">Will B serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> B:</th><td class="field-body">Will you serve X for A?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">Hey, buddy, here's X!</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="proxied-service-requesting">
|
||||
<h2>Proxied service requesting</h2>
|
||||
<div class="section" id="the-simple-case">
|
||||
<h3>The Simple Case</h3>
|
||||
<p>I'm looking for somebody to provide a service, <em>X</em>.</p>
|
||||
<p><em>A</em> sends a request to <em>C</em>, and <em>C</em> doesn't respond. <em>A</em> requests the
|
||||
service from <em>B</em> and <em>B</em> NBKs. <em>A</em> requests that <em>B</em> proxy my request
|
||||
to <em>C</em>, in case <em>B</em> can reach <em>C</em>. <em>C</em> replies directly to <em>A</em>, and
|
||||
we begin communicating on that service:</p>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">A -> C:</th><td class="field-body">Will you serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> A:</th><td class="field-body">(No response)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">Will you serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">No!</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">Will C serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> C:</th><td class="field-body">Will you serve X for A?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> A:</th><td class="field-body">Hey, buddy, here's X! Let's go out for beer later.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="more-complicated-cases">
|
||||
<h3>More Complicated Cases</h3>
|
||||
<p>I know <em>D</em> offers a service, <em>X</em>, but I can't get in touch with it.</p>
|
||||
<p><em>A</em> requests <em>X</em> from <em>D</em>, and <em>D</em> never responds. <em>A</em> requests that <em>B</em> find
|
||||
<em>D</em>. <em>B</em> doesn't know <em>D</em> and forwards the request to a friend <em>C</em>. <em>C</em> knows
|
||||
<em>D</em> and sends the message along. <em>D</em> tries to respond directly to <em>A</em>, but
|
||||
can't, so it sends replies back up the chain.</p>
|
||||
<table class="docutils field-list" frame="void" rules="none">
|
||||
<col class="field-name" />
|
||||
<col class="field-body" />
|
||||
<tbody valign="top">
|
||||
<tr class="field"><th class="field-name">A -> D:</th><td class="field-body">Will you serve X?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">D -> A:</th><td class="field-body">(No response)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> B:</th><td class="field-body">Will D serve X for me?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> C:</th><td class="field-body">Will D serve X for A?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> D:</th><td class="field-body">Will you serve X for A?</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">D -> A:</th><td class="field-body">Hey, buddy, here's X!</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">A -> D:</th><td class="field-body">(No response)</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">D -> C:</th><td class="field-body">I'm serving X for A.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">C -> B:</th><td class="field-body">D's serving X for A.</td>
|
||||
</tr>
|
||||
<tr class="field"><th class="field-name">B -> A:</th><td class="field-body">D's serving X for you.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Each message is signed, but only the first message (A's message) is inviolable.
|
||||
Each client then passes the message, stripping off intermediary signatures, and
|
||||
then signing the message for each of its friends.</p>
|
||||
<p>A message looks like:</p>
|
||||
<pre class="literal-block">
|
||||
---- A's Signed Message Starts Here ----
|
||||
To: D's GPG key.
|
||||
---- D's Encrypted Message Starts Here ----
|
||||
Hey *D*, will you serve *X* for me?
|
||||
Please reply to 5.onion.
|
||||
---- D's Encrypted Message Ends Here ----
|
||||
---- A's Signed Message Ends Here ----
|
||||
</pre>
|
||||
<p>A forwarded message, from B to C, looks like:</p>
|
||||
<pre class="literal-block">
|
||||
---- B's Signed Message Starts Here ----
|
||||
---- A's Signed Message Starts Here ----
|
||||
To: D's GPG key.
|
||||
---- D's Encrypted Message Starts Here ----
|
||||
Hey *D*, will you serve *X* for me?
|
||||
Please reply to 5.onion.
|
||||
---- D's Encrypted Message Ends Here ----
|
||||
---- A's Signed Message Ends Here ----
|
||||
---- B's Signed Message Ends Here ----
|
||||
</pre>
|
||||
<p>When forwarded over again, from C to D, it looks like:</p>
|
||||
<pre class="literal-block">
|
||||
---- C's Signed Message Starts Here ----
|
||||
---- A's Signed Message Starts Here ----
|
||||
To: D's GPG key.
|
||||
---- D's Encrypted Message Starts Here ----
|
||||
Hey *D*, will you serve *X* for me?
|
||||
Please reply to 5.onion.
|
||||
---- D's Encrypted Message Ends Here ----
|
||||
---- A's Signed Message Ends Here ----
|
||||
---- C's Signed Message Ends Here ----
|
||||
</pre>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="unit-tests">
|
||||
<h1>Unit Tests</h1>
|
||||
<p>These buggers are neat. We need to fake known and pre-determined communications
|
||||
to verify the servers and clients are correctly and independently responding
|
||||
according to the protocol.</p>
|
||||
</div>
|
||||
<div class="section" id="attacks">
|
||||
<h1>Attacks</h1>
|
||||
<p>Of <em>course</em> this is vulnerable. It's on the internet, isn't it?</p>
|
||||
<div class="section" id="discovery">
|
||||
<h2>Discovery</h2>
|
||||
<p>A discovered box is shut down or compromised. It can lie to its requestors and
|
||||
not perform its functions. It can also allow connections and expose
|
||||
connecting clients. If the client is compromisable (within reach), it also can
|
||||
be compromised. We can try, but every service that isn't run directly over Tor
|
||||
identifies one user to another.</p>
|
||||
</div>
|
||||
<div class="section" id="deception">
|
||||
<h2>Deception</h2>
|
||||
<p>This is probably the largest worry, where B fakes A's responses.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="mitigations">
|
||||
<h1>Mitigations</h1>
|
||||
<p>We gain a lot by relying on the WOT, and only direct links in the WOT. We also
|
||||
gain a lot by requiring every communication to be signed (and maximally
|
||||
encrypted).</p>
|
||||
<p>Once a key is compromised, we're vulnerable, but to what exactly? What attacks
|
||||
can an adversary who's compromised a secret key perform? As long as you don't
|
||||
have any publicly identifiable (or public-facing) services in your Santiago,
|
||||
then not much. If you're identifiable by your Santiago, and you've permitted
|
||||
the attacker to see an identifiable service (including your Santiago instances),
|
||||
that service and all co-located services could be shut down. If the service
|
||||
identifies you (and not just your box), you're vulnerable. An attacker will
|
||||
shortly identify all the services you've given it access to.</p>
|
||||
<p>An attacker can try to identify your friends, though will have trouble if you
|
||||
send your proxied requests with non-public methods, or you don't proxy at all.</p>
|
||||
</div>
|
||||
<div class="section" id="outstanding-questions">
|
||||
<h1>Outstanding Questions</h1>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Loading…
x
Reference in New Issue
Block a user