/mandos/release

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

« back to all changes in this revision

Viewing changes to intro.xml

  • Committer: Björn Påhlsson
  • Date: 2011-10-02 13:45:45 UTC
  • mto: (237.7.53 trunk)
  • mto: This revision was merged to the branch mainline in revision 286.
  • Revision ID: belorn@fukt.bsnet.se-20111002134545-oytmfbl15r8lsm6p
working transition code for going between se.bsnet.fukt to se.recompile

Show diffs side-by-side

added added

removed removed

Lines of Context:
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 "2019-02-09">
 
4
<!ENTITY TIMESTAMP "2011-08-08">
5
5
<!ENTITY % common SYSTEM "common.ent">
6
6
%common;
7
7
]>
18
18
        <firstname>Björn</firstname>
19
19
        <surname>Påhlsson</surname>
20
20
        <address>
21
 
          <email>belorn@recompile.se</email>
 
21
          <email>belorn@fukt.bsnet.se</email>
22
22
        </address>
23
23
      </author>
24
24
      <author>
25
25
        <firstname>Teddy</firstname>
26
26
        <surname>Hogeborn</surname>
27
27
        <address>
28
 
          <email>teddy@recompile.se</email>
 
28
          <email>teddy@fukt.bsnet.se</email>
29
29
        </address>
30
30
      </author>
31
31
    </authorgroup>
32
32
    <copyright>
33
33
      <year>2011</year>
34
 
      <year>2012</year>
35
 
      <year>2013</year>
36
 
      <year>2014</year>
37
 
      <year>2015</year>
38
 
      <year>2016</year>
39
 
      <year>2017</year>
40
 
      <year>2018</year>
41
34
      <holder>Teddy Hogeborn</holder>
42
35
      <holder>Björn Påhlsson</holder>
43
36
    </copyright>
67
60
      The computers run a small client program in the initial RAM disk
68
61
      environment which will communicate with a server over a network.
69
62
      All network communication is encrypted using TLS.  The clients
70
 
      are identified by the server using a TLS public key; each client
 
63
      are identified by the server using an OpenPGP key; each client
71
64
      has one unique to it.  The server sends the clients an encrypted
72
65
      password.  The encrypted password is decrypted by the clients
73
 
      using a separate OpenPGP key, and the password is then used to
 
66
      using the same OpenPGP key, and the password is then used to
74
67
      unlock the root file system, whereupon the computers can
75
68
      continue booting normally.
76
69
    </para>
79
72
  <refsect1 id="introduction">
80
73
    <title>INTRODUCTION</title>
81
74
    <para>
82
 
      <!-- This paragraph is a combination and paraphrase of two
83
 
           quotes from the 1995 movie “The Usual Suspects”. -->
84
75
      You know how it is.  You’ve heard of it happening.  The Man
85
76
      comes and takes away your servers, your friends’ servers, the
86
77
      servers of everybody in the same hosting facility. The servers
200
191
      <para>
201
192
        No.  The server only gives out the passwords to clients which
202
193
        have <emphasis>in the TLS handshake</emphasis> proven that
203
 
        they do indeed hold the private key corresponding to that
204
 
        client.
205
 
      </para>
206
 
    </refsect2>
207
 
    
208
 
    <refsect2 id="sniff">
209
 
      <title>How about sniffing the network traffic and decrypting it
210
 
      later by physically grabbing the Mandos client and using its
211
 
      key?</title>
212
 
      <para>
213
 
        We only use <acronym>PFS</acronym> (Perfect Forward Security)
214
 
        key exchange algorithms in TLS, which protects against this.
 
194
        they do indeed hold the OpenPGP private key corresponding to
 
195
        that client.
215
196
      </para>
216
197
    </refsect2>
217
198
    
233
214
      </para>
234
215
    </refsect2>
235
216
    
236
 
    <refsect2 id="fakecheck">
237
 
      <title>Faking checker results?</title>
 
217
    <refsect2 id="fakeping">
 
218
      <title>Faking ping replies?</title>
238
219
      <para>
239
 
        If the Mandos client does not have an SSH server, the default
240
 
        is for the Mandos server to use
 
220
        The default for the server is to use
241
221
        <quote><literal>fping</literal></quote>, the replies to which
242
222
        could be faked to eliminate the timeout.  But this could
243
223
        easily be changed to any shell command, with any security
244
 
        measures you like.  If the Mandos client
245
 
        <emphasis>has</emphasis> an SSH server, the default
246
 
        configuration (as generated by
247
 
        <command>mandos-keygen</command> with the
248
 
        <option>--password</option> option) is for the Mandos server
249
 
        to use an <command>ssh-keyscan</command> command with strict
250
 
        keychecking, which can not be faked.  Alternatively, IPsec
251
 
        could be used for the ping packets, making them secure.
 
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.
252
228
      </para>
253
229
    </refsect2>
254
230
  </refsect1>
383
359
    </para>
384
360
  </refsect1>
385
361
  
386
 
  <refsect1 id="bugs">
387
 
    <title>BUGS</title>
388
 
    <xi:include href="bugs.xml"/>
389
 
  </refsect1>
390
 
  
391
362
  <refsect1 id="see_also">
392
363
    <title>SEE ALSO</title>
393
364
    <para>
421
392
    <variablelist>
422
393
      <varlistentry>
423
394
        <term>
424
 
          <ulink url="https://www.recompile.se/mandos">Mandos</ulink>
 
395
          <ulink url="http://www.fukt.bsnet.se/mandos">Mandos</ulink>
425
396
        </term>
426
397
        <listitem>
427
398
          <para>