/mandos/trunk

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/trunk

« back to all changes in this revision

Viewing changes to network-protocol.txt

  • Committer: Teddy Hogeborn
  • Date: 2008-08-04 23:38:26 UTC
  • mfrom: (24.1.20 mandos)
  • Revision ID: teddy@fukt.bsnet.se-20080804233826-idy7v8x36llseue0
* network-protocol.txt: New.

* server.py (daemon): Do the double fork thing.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
The Mandos server announces itself as a Zeroconf service of type
2
 
"_mandos._tcp". The Mandos client sends a line of text where the first
3
 
whitespace-separated field is the protocol version, which currently is
4
 
"1".  The client and server then start a TLS protocol handshake with a
5
 
slight quirk: the Mandos server program acts as a TLS "client" while
6
 
the connecting Mandos client acts as a TLS "server".  The Mandos
7
 
client must supply an OpenPGP certificate, and the fingerprint of this
8
 
certificate is used by the Mandos server to look up (in a list read
9
 
from a file at start time) which binary blob to give the client.  No
10
 
other authentication or authorization is done by the server.
 
1
Network Protocol Version 1
11
2
 
12
 
| Mandos Client                              |     | Mandos Server |
13
 
|--------------------------------------------+-----+---------------|
14
 
| Connect                                    |     |               |
15
 
| "1\r\n"                                    | ->  |               |
16
 
| TLS handshake                              | <-> | TLS handshake |
17
 
| OpenPGP public key (part of TLS handshake) | ->  |               |
18
 
|                                            | <-  | Binary blob   |
19
 
|                                            |     | Close         |
 
3
The server announces itself as an IPv6 Zeroconf service of type
 
4
"_mandos._tcp".  A connecting client sends a line of text where the
 
5
first whitespace-separated field is the protocol version, which
 
6
currently is "1".  The client and server then start a TLS handshake,
 
7
with the unusual property that the server program acts as a TLS
 
8
"client" and the connecting client acts as a TLS "server".  In this
 
9
TLS handshake the client must supply an OpenPGP certificate, and the
 
10
fingerprint of this certificate is used by the server to look up (in a
 
11
list read from file at start time) which binary blob to give the
 
12
client.  No other authentication or authorization is done by the
 
13
server.  After the binary blob is sent by the server to the client,
 
14
the server closes the connection.