1 TLS Pool and Anoymising Precursors
2 ==================================
4 > *The “Anonymising Precursor” is a new idea introduced by the TLS Pool. It
5 > works just as the rest though, encapsulating the knowledge into the pool and
6 > making decisions on rather straightforward information (namely, service
7 > name and the role that is being played).*
9 What is an Anonymising Precursor?
10 ---------------------------------
12 While setting up a TLS connection, a lot of information is exchanged without
13 encryption. This includes credentials such as certificates, containing not only
14 names but also public keys (which are excellent long-term identifiers) for their
15 owners. An anonymising precursor is a phase preceding the "normal"
16 TLS handshake to setup a layer of encryption without authentication.
18 Once established, secure renegotiation can be initiated to authenticate parties
19 as would "normally" be expected, and return the TLS connection with the same
20 security, but without having revealed all the identifying information needed
21 for the "normal" TLS handshake.
23 What does this add to TLS security?
24 -----------------------------------
26 The first phase is an ANON-ECDH exchange. This is known to be open to
27 man-in-the-middle attacks, so a third party might be sitting in between the end
28 points that setup the TLS connection. The properties of secure renegiation
29 however, ensure that such a situation will be detected in retrospect. This
30 means that an attacker will be noticed, and that no silent observation of
31 identifying information is possible.
33 Why is this not usable for all protocols?
34 -----------------------------------------
36 The TLS Pool will always followup on an ANON-ECDH phase with whatever
37 authenticating cipher suite it deems necessary, but the remote party may
38 use another implementation, and return control to the application after
39 the ANON-ECDH handshake alone; it would still support renegotiation though.
41 As soon as the application gains control, information may be passed around
42 that shows up as TLS-protected, but is in fact not authenticated. This happens
43 in the above situation on remote party that happily accepts ANON-ECDH, but it
44 depends on the application protocol whether this leads to security problems.
46 Consider SMTP; the server sends a banner to welcome and greet the recipient,
47 but without formal meaning (except an "OK" code). If this got modified by an
48 intermediate it could not do harm. After the banner, the local party must act,
49 and if it requires authentication before sending anything, as is the case with
50 the TLS Pool, then nothing harmful can happen. As a result, SMTP is completely
51 safe to initiate within unauthenticated ANON-ECDH.
53 Reasoning similar to SMTP applies to POP3.
55 IMAP is more interesting; it can still use ANON-ECDH, but requires some more
56 care and attention and it does show that not everything can be automatically
57 secured with an ANON-ECDH precursor. IMAP servers also send a banner to
58 welcome the client, but this time it includes a list of
59 features supported on the server, and an intermediary could modify this
60 information to establish a service degredation. Usually however, it is not
61 considered a privacy violation if this information is shown to this
62 intermediary. This means that we can permit ANON-ECDH, provided that either
63 (1) the banner is not sent before the second handshake is complete, or
64 (2) the TLS stack detects intermediate changes after the handshake is complete,
65 which requires the common RFC 7627 "extended master secret" and RFC 5746
66 "secure renegotiation" extensions.
68 For IMAP, the reasonable thing to do is to let the server refuse ANON-ECDH
69 if it does not provide these facilities, or when the client does not offer
70 them in its Client Hello. Alternatively, the server may offer ANON-ECDH in
71 either case, but always hold back on sending the banner before the second,
72 authenticated handshake
73 has completed (which is what the TLS Pool will do). The server thereby
74 protects the information that it sends. The client should validate that
75 both extensions are being used by the server *if* it received any data
76 before the second handshake is complete.
78 What this demonstrates, is that protocol-specific knowledge is needed to
79 decide whether and how to handle Anonymous Precursors. The TLS Pool is provided
80 with a service name so it is able to decide on that. This extends the view
81 that technical detail is ideally integrated into the TLS Pool to relieve the
82 application from such complications -- and the involved potential of being
83 subjected to security attacks.
85 Another interesting protocol is HTTP. As soon as the client has connected
86 to a server over TLS, it will send a request, revealing potentially private
87 information that also needs to be authenticated, so it needs better protection
88 than the IMAP banner which only needed authentication in hindsight.
89 This means that the reasoning from IMAP cannot be applied. Still, as it
90 turns out, HTTP can in practice make good use of ANON-ECDH.
92 For an HTTP client, the reasoning is quite simple; it should not offer ANON-ECDH
93 unless it is going to complete the second handshake before sending the HTTP
94 request. This can easily be enforced in the client code; the TLS Pool
95 handles the Anonymous Precursor in the same command as the customary
96 continuation into server authentication, so the potentially-sensitive
97 HTTP request is only sent to an authenticated server.
99 The HTTP server is another matter; it may assume that the client handles
100 its own privacy well enough by implementing the foregoing mechanism. However
101 when the server requires authentication, it should ensure the authenticity
102 of any request data sent before the second handshake is complete. It could
103 reason as for IMAP, leaving the privacy matter to the client, but that would
104 mean that extended master secrets are required for a protocol that is not
105 known for its willingness to mature towards new developments; HTTP is part
106 of many code bases and not all of them are easy to update. So in the specific
107 case of HTTP, we lean towards not supporting it on the server when the
108 client identity is required.
110 Note however, that any TLS endpoint that does not desire an authenticated
111 identity for its remote peer can accept ANON-DH without risk. This happens to
112 be true for the majority of HTTP servers; even when client identity is
113 requested or required, a common HTTP server would start without asking for
114 it and then, based on the path that the client sends in a request, renegotiate
115 TLS to ask for the client ID. Since ANON-DH only precedes the first
116 handshake, it will be common to find HTTP servers that can permit ANON-DH
117 prefixes for this general reason.
120 Registry for Protocols
121 ----------------------
123 By default, the TLS Pool will not offer to the ANON-ECDH precursor handshake.
124 Only when the service specified during the STARTTLS setup is known to work,
125 it may start in this vain. And even then, it will distinguish the choice
126 between client and server roles; and it will correctly handle connections that
129 Flags that may influence this decision are those that indicate that the remote
130 identity is ignored by the application; if this is the case, then
131 unauthenticated traffic from the remote does not matter either. Note that the
132 identity of clients is unknown in many TLS connections; the most common use
133 cases call for an authenticated server and an unauthenticated client, to provide
134 for situations with any clients coming from anywhere.
136 The code for the TLS Pool contains a registry for service, leading to their
137 support for client and/or server roles. This registry is openly discussed on
138 the mailing list, found on <http://lists.arpa2.org/mailman/listinfo/tls-pool> —
139 please go there to propose changes to the list, and be open for a discussion
140 before the change is accepted. Although security is an overriding concern,
141 the general intention is to arrive at consensus before things are changed
142 in the registry built into the TLS Pool.
144 One invalid service name (according to RFC 6335) has been created through the
145 use of an underscore. This name can be used to explicitly
146 permit an Anonymous Precursor to a generic protocol. The name is
147 `generic_anonpre`. Use this as a service name for generic protocols that
148 have no formally registered service name but that do permit the
149 Anonymous Precursor phase.
151 Implementation status
152 ---------------------
154 The current implementation holds the code for the anonymising precursor,
155 but the registry for supported applications is empty. The reason is that
156 the underlying GnuTLS library does not seem to implement it as we had
158 [read this](http://lists.gnutls.org/pipermail/gnutls-help/2015-November/003998.html)
159 for details. As soon as this is resolved, the anonymising Precursor
160 will be enabled, and automatically applied. The most probable cause is
161 with GnuTLS however, so there is an external dependency to make this
projects / tlspool / blob