/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 intro.xml

  • 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:
intro.xml
1
1
<?xml version="1.0" encoding="UTF-8"?>
2
2
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3
3
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4
 
<!ENTITY TIMESTAMP "2011-10-03">
 
4
<!ENTITY TIMESTAMP "2015-03-08">
5
5
<!ENTITY % common SYSTEM "common.ent">
6
6
%common;
7
7
]>
31
31
    </authorgroup>
32
32
    <copyright>
33
33
      <year>2011</year>
 
34
      <year>2012</year>
34
35
      <holder>Teddy Hogeborn</holder>
35
36
      <holder>Björn Påhlsson</holder>
36
37
    </copyright>
196
197
      </para>
197
198
    </refsect2>
198
199
    
 
200
    <refsect2 id="sniff">
 
201
      <title>How about sniffing the network traffic and decrypting it
 
202
      later by physically grabbing the Mandos client and using its
 
203
      key?</title>
 
204
      <para>
 
205
        We only use <acronym>PFS</acronym> (Perfect Forward Security)
 
206
        key exchange algorithms in TLS, which protects against this.
 
207
      </para>
 
208
    </refsect2>
 
209
    
199
210
    <refsect2 id="physgrab">
200
211
      <title>Physically grabbing the Mandos server computer?</title>
201
212
      <para>
214
225
      </para>
215
226
    </refsect2>
216
227
    
217
 
    <refsect2 id="fakeping">
218
 
      <title>Faking ping replies?</title>
 
228
    <refsect2 id="fakecheck">
 
229
      <title>Faking checker results?</title>
219
230
      <para>
220
 
        The default for the server is to use
 
231
        If the Mandos client does not have an SSH server, the default
 
232
        is for the Mandos server to use
221
233
        <quote><literal>fping</literal></quote>, the replies to which
222
234
        could be faked to eliminate the timeout.  But this could
223
235
        easily be changed to any shell command, with any security
224
 
        measures you like.  It could, for instance, be changed to an
225
 
        SSH command with strict keychecking, which could not be faked.
226
 
        Or IPsec could be used for the ping packets, making them
227
 
        secure.
 
236
        measures you like.  If the Mandos client
 
237
        <emphasis>has</emphasis> an SSH server, the default
 
238
        configuration (as generated by
 
239
        <command>mandos-keygen</command> with the
 
240
        <option>--password</option> option) is for the Mandos server
 
241
        to use an <command>ssh-keyscan</command> command with strict
 
242
        keychecking, which can not be faked.  Alternatively, IPsec
 
243
        could be used for the ping packets, making them secure.
228
244
      </para>
229
245
    </refsect2>
230
246
  </refsect1>