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