Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

On 01/10/2013, at 3:01 PM, Eliot Lear <lear@cisco.com> wrote:

> Hi Mark,

Hi Eliot,

> Section 3.3 of your draft does not properly characterize a substantial
> security consideration:
> 
> If a browser has a primitive that says, “relax your certificate
> inspection when you connect on port xyz”, then an insertion attack can
> be made not just against those sites that intend to use the header, but
> for any site on the Internet, including those sites that have valid
> certificates, thus substantially damaging the existing TLS deployment.
> 
> Consider the following snippet going into the MITM:
> 
> <a href="https://bankofeliot.com/login">Click Here To Login</a>
> 
> and coming out:
> 
> Alt-svc: http2-tls-relaxed=:443
> {...}
> 
> Worse, the server has no notion that the browser hasn't validated the
> certificate.


AIUI your concern is that when this is in place, it enables an attacking intermediary to redirect links in HTML content to a site that isn't encrypted without having that redirection show up in the browser, or noticed on the server. 

However, it *will* show up in the browser, in that the security "lock" won't be in place. Furthermore, note the item in "Next Steps":

"""
Indicating Chosen Service: It’s likely necessary for the server to know which protocol the client has chosen, and perhaps even the hostname (for load balancing). This could be conveyed as part of the “magic”, or as a request header. There are also security implications here; for example, without this information, the server doesn’t know if the client has checked the certificate, leading to a situation where an intermediary can downgrade a HTTPS connection to relaxed HTTP.
"""

I fully expect that if we get momentum on this proposal, we'll need to look at modifying the protocol to carry this information from the UA to the origin.


>  The mitigations for this attack are, as far as I can tell:
> 
> 1.  Do not have the primitive in the browser;
> 2.  Only upgrade on the existing connection;
> 3.  Use a DNS record instead that is signed and can be validated (I
> don't know if this is a complete mitigation).
> 
> My suggestion is (2) or (3) if you're looking for OE.
> 
> Finally, using port 443 in the example conflicts with TLS and the
> assignment as articulated in RFC 2818.


The registry does not reference RFC2818:
  <http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=443>

It merely says "http protocol over TLS/SSL." That's what's happening here.

More to the point, this draft is proposing a pretty fundamental change to how URI schemes map to protocols and ports, and so some adjustment of scheme and port semantics ought to be expected. 

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 1 October 2013 05:44:05 UTC