Re: Expectations for TLS session reuse

On 22/12/2016 15:39, Patrick McManus wrote:
> On Thu, Dec 22, 2016 at 7:25 AM, Richard Bradbury wrote:
>
>     the position is the same for HTTP/1.1 as it is for HTTP/2
>
>
> I don't think this is true. H1 is governed by 7230 section 9.. in 
> practice it is a connection per origin:
>   The "https" scheme (Section 2.7.2 <https://tools.ietf.org/html/rfc7230#section-2.7.2>) is intended to prevent (or at
>     least reveal) many of these potential attacks on establishing
>     authority, provided that the negotiated TLS connection is secured and
>     the client properly verifies that the communicating server's identity
>     matches the target URI's authority component (see [RFC2818 <https://tools.ietf.org/html/rfc2818>]).
> whereas H2 loosens that a little bit for coalescing in 7540.

Hmm... The statement in the above quotation seems inconclusive to me. 
Surely a client could verify the server's identity simply by checking 
that the target authority appears in the server's certificate (and that 
the certificate is valid too, of course...). Wouldn't that satisfy the 
security consideration on establishing authority described in section 9.1?

In search of something more explicit, I found this paragraph in section 
5.5 (Effective request URI):

    "Once the effective request URI has been constructed, an origin
    server needs to decide whether or not to provide service for that
    URI via the connection in which the request was received. For
    example, the request might have been misdirected, deliberately or
    accidentally, such that the information within a received
    request-target or Host header field differs from the host or port
    upon which the connection has been made. If the connection is from a
    trusted gateway, that inconsistency might be expected; otherwise, it
    might indicate an attempt to bypass security filters, trick the
    server into delivering non-public content, or poison a cache. See
    Section 9 <https://tools.ietf.org/html/rfc7230#section-9> for
    security considerations regarding message routing."

but that also doesn't seem very clear cut.

-- 
Richard Bradbury | Lead Research Engineer
BBC Research & Development
Centre House, 56 Wood Lane, London  W12 7SB.
T: 0303 040 9672  F: 020 8811 8815