/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: 2015-07-20 03:03:33 UTC
  • Revision ID: teddy@recompile.se-20150720030333-203m2aeblypcsfte
Bug fix for GnuTLS 3: be compatible with old 2048-bit DSA keys.

The mandos-keygen program in Mandos version 1.6.0 and older generated
2048-bit DSA keys, and when GnuTLS uses these it has trouble
connecting using the Mandos default priority string.  This was
previously fixed in Mandos 1.6.2, but the bug reappeared when using
GnuTLS 3, so the default priority string has to change again; this
time also the Mandos client has to change its default, so now the
server and the client should use the same default priority string:

SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP:!RSA:+SIGN-DSA-SHA256

* mandos (main/server_defaults): Changed default priority string.
* mandos-options.xml (/section/para[id="priority_compat"]): Removed.
  (/section/para[id="priority"]): Changed default priority string.
* mandos.conf ([DEFAULT]/priority): - '' -
* mandos.conf.xml (OPTIONS/priority): Refer to the id "priority"
                                      instead of "priority_compat".
* mandos.xml (OPTIONS/--priority): - '' -
* plugins.d/mandos-client.c (main): Changed default priority string.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Network Protocol Version 1
2
 
 
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.