You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another post-WGLC feedback item 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.
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.
The text was updated successfully, but these errors were encountered:
mnot
changed the title
Prohibit client certs from being used with Opp-Sec [opp-sec]
Prohibit client certs from being used with Opp-Sec
Jun 3, 2016
Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT present them. Established connections with client certificates MAY be reused, however.
Another post-WGLC feedback item 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.
From @martinthomson on http-wg discussion:
The text was updated successfully, but these errors were encountered: