scope moved into the disclaimer chapter. They are too similar. --> Merge
[ach-master.git] / src / disclaimer.tex
1 \section{Disclaimer and scope}
2 \label{section:disclaimer}
3
4 \epigraph{``A chain is no stronger than its weakest link, and life is after all a chain``}{-- William James}
5
6
7 This guide specifically does not address physical security, protecting software
8 and hardware against exploits, basic IT security housekeeping, complete
9 information assurance, issues with key-roll over and key management, securing client PCs and mobile devices, 
10 anti-tempest\cite{Wikipedia:Tempest} attack techniques,
11 protecting against different side-channel attacks (timing--, cache timing--,
12 differential fault analysis or power monitoring attacks), downgrade attacks,
13 jamming the encrypted channel or other similar attacks which are typically
14 employed to circumvent strong encryption.  The authors can not overstate the
15 importance of these other techniques.  Interested readers are advised to read
16 about these attacks in detail since they give a lot of insight into other parts
17 of cryptography engineering which need to be dealt with.\footnote{An easy to
18 read yet very insightful recent example is the "FLUSH+RELOAD" technique \cite{yarom2013flush+} for
19 leaking cryptographic keys from one virtual machine to another via L3 cache
20 timing attacks.}
21
22 This guide does not talk about the well-known insecurities of trusting a
23 public-key infrastructure (PKI)\footnote{Interested readers are referred to
24 \url{https://bugzilla.mozilla.org/show_bug.cgi?id=647959} or
25 \url{http://www.heise.de/security/meldung/Der-ehrliche-Achmed-bittet-um-Vertrauen-1231083.html}
26 (german) which brings the problem of trusting PKIs right to the point}. Nor
27 does this text explain how to run your own Certificate Authority (CA). 
28
29
30 For some experts in cryptography this text might seem too informal. However, we
31 strive to keep the language as non-technical as possible and fitting for our
32 target audience: system administrators who can collectively improve the
33 security level for all of their users. 
34
35
36
37 \epigraph{``Security is a process, not a product.``}{Bruce Schneier}
38
39 A note on the contents: this guide can only describe what the authors currently
40 \emph{believe} to be the best settings based on their personal experience and
41 after intensive cross checking with literature and experts. For a complete list
42 of people who reviewed this paper, see the section \ref{section:Reviewers}.
43 Even though, multiple specialists reviewed the guide, the authors can give
44 \emph{no guarantee whatsover} that they made the right recommendations. Keep in
45 mind that tomorrow there might be new attacks on some ciphers and many of the
46 recommendations in this guide might turn out to be wrong. Security is a
47 process.
48
49
50 We therefore recommend that system administrators keep up to date with recent
51 topics in IT security and cryptography. 
52
53
54 In this sense, this guide is very focused on getting the cipher strings done
55 right even though there is much more to do in order to make a system more
56 secure.  We the authors, need this document as much as the reader needs it.
57
58 \paragraph{Scope:}
59 \label{section:Scope}
60
61 In this guide, we restricted ourselves to:
62 \begin{itemize}
63 \item Internet-facing services
64 \item Commonly used services
65 \item Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
66 \item OpenSSL 
67 \end{itemize}
68
69 We explicitly excluded:
70 \begin{itemize}
71 \item Specialized systems (such as medical devices, most embedded systems, etc.)
72 \item Wireless Access Points
73 \item Smart-cards/chip cards
74 \item Advice on running a PKI or a CA.
75 %\item Services which should be run only in an internal network and never face the Internet.
76 \end{itemize}
77
78 %% * whatsapp --> man kann nichts machen, out of scope
79 %* Lync: == SIP von M$.
80 %* Skype: man kann ncihts machen, out of scope.
81 %* Wi-Fi APs, 802.1X, ... ???? --> out of scope
82 %* Tomcats/...????
83 %* SIP   -> Klaus???
84 %* SRTP  -> Klaus???
85 %* DNSSec ?? Verweis auf BCPxxx  --> out of scope
86 %   - DANE
87 %What happens at the IETF at the moment?
88 %* TOR?? --> out of scope
89 %* S/Mime --> nachsehen, gibt es BCPs? (--> Ramin)
90 %* TrueCrypt, LUKS, FileVault, etc ---> out of scope
91 %* AFS -> out of scope
92 %* Kerberos --> out of scope
93 %* NNTP -> out of scope
94 %* NTPs tlsdate -> out of scope
95 %* BGP / OSPF --> out of scope
96 %* irc,silc --> out of scope
97 %* LDAP -> out of scope
98 %* Moxa , APC, und co... ICS . Ethernet to serial --> out of scope
99 %* telnet -> DON't!!!
100 %* rsyslog --> out of scope
101 %* ARP bei v6 spoofing -> out of scope
102 %* tinc?? -> out of scope
103 %* rsync -> nur ueber ssh fahren ausser public web mirrors
104 %* telnets -> out of scope
105 %* ftps -> out of scope
106 %seclayer-tcp    3495/udp    # securitylayer over tcp
107 %seclayer-tcp    3495/tcp    # securitylayer over tcp
108 %* webmin -> maybe
109 %* plesk -> out of scope
110 %* phpmyadmin --> haengt am apache, out of scope
111 %* DSL modems -> out of scope
112 %* UPnP, natPmp --> out of scope