- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 2 Jun 2016 11:51:53 +1000
- To: Erik Nygren <erik@nygren.org>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Mike Bishop <Michael.Bishop@microsoft.com>, awirth@akamai.com
I would be happy saying that you can't use client certs. That is, unless you were using them for HTTPS requests and the connection happened to be shared. On 2 June 2016 at 11:34, Erik Nygren <erik@nygren.org> wrote: > Another issue that came up from one of our security researchers which > is not covered in the doc is client certs. Do we need any guidance on them > in the doc? > Should we say that clients MUST NOT send them for connections being used for > HTTP-scheme > requests? Or only send them after an origin has opted-in with a > .well-known/http-encryption response > over a strongly authenticated connection? > > The risk comes from an unauthenticated active adversary Alt-Svc'ing a client > to a server > to which the client is sending client certs for HTTPS but where the server > is not > multi-scheme aware and hasn't opted in. There is the potential for the > server to > have a perception of HTTPS client-cert authenticated requests when the > client may > be thinking it is making HTTP requests which may have had some cookies > or other elements injected by the active MitM under the cleartext HTTP side. > > Erik > > > > On Wed, Jun 1, 2016 at 8:08 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> >> > On 2 Jun 2016, at 1:34 AM, Erik Nygren <erik@nygren.org> wrote: >> > >> > On Tue, May 31, 2016 at 2:02 AM, Mark Nottingham <mnot@mnot.net> wrote: >> > FYI; this incorporates the discussing in WGLC. >> > >> > Please have a look at it; if any issues remain unresolved, please bring >> > them to our attention ASAP. >> > >> > As we've been doing some detailed design of a server-side >> > implementation, as well as had some internal security folks looking more >> > closely, some additional items/questions have arisen: >> > >> > 1) Prohibit mixing scheme (HTTP vs HTTPS) on a connection without >> > authenticated server-side opt-in: >> > https://github.com/httpwg/http-extensions/issues/188 >> >> See separate thread. >> >> >> > 2) Is there anything that can trigger fall-back to clear-text HTTP? In >> > particular, what is client-side handling when a server returns a 421 (Not >> > Authoritative) over a strongly authenticated connection? Should clients >> > error, fall back to clear-text just once, or remove their cached commitment? >> >> As I read it, if there's no tls-commit, the client can always fall back. >> If there is, it can't while that commitment is in effect. >> >> >> > 3) The text is still a little unclear on whether commit then requires >> > subsequent connections to use "strong authentication" or just >> > "authentication". In particular, Section 3 seems to add some confusion >> > about whether "reasonable assurances" and "server authentication" are the >> > same thing or not but then 5.2 sometimes uses "authenticated without >> > "strongly authenticated". For example, this paragraph is not particularly >> > crisp on what the requirements are (strong authentication or something >> > else): >> > >> > A commitment is not bound to a particular alternative service. >> > Clients are able to use alternative services that they become aware >> > of. However, once a valid and authenticated commitment has been >> > received, clients SHOULD NOT use an unauthenticated alternative >> > service. Where there is an active commitment, clients SHOULD ignore >> > advertisements for unsecured alternative services. A client MAY send >> > requests to an unauthenticated origin in an attempt to discover >> > potential alternative services, but these requests SHOULD be entirely >> > generic and avoid including credentials. >> >> I had a similar reaction reading this earlier. Martin, do you want to do >> some tweaking, or should I have a go? >> >> Cheers, >> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >
Received on Thursday, 2 June 2016 01:52:23 UTC