W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

RE: New Version Notification for draft-nottingham-http2-encryption-02.txt

From: Yoav Nir <synp71@live.com>
Date: Mon, 16 Dec 2013 14:02:20 +0200
Message-ID: <DUB124-W33DF872F301A86B35F9940B1D80@phx.gbl>
To: Christian Huitema <huitema@huitema.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>


> From: huitema@huitema.net
> To: synp71@live.com; ietf-http-wg@w3.org
> Date: Sun, 15 Dec 2013 16:37:16 -0800
> Subject: RE: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt
> 
> From: Yoav Nir [mailto:synp71@live.com], Sunday, December 15, 2013 3:53 AM
> 
> > No scary UI means that a MitM or someone who has compromised the DNS can 
> > hijack your connection, show a self-signed cert, and get no indication 
> > to the user that something is wrong.  So (let's use hotmail, because not 
> > all examples have to be gmail):
> >
> > http://hotmail.com  redirects to https://selfsigned.live.com  which has 
> > a self-signed certificate, and everything looks fine.  Except it's an 
> > attacker.
> 
> The problem is really the insecure redirect, not the use of a self-signed certificate. We could have: http://hotmail.com  redirects to https://recorder.dgse.fr  which has  a CA-signed certificate, and everything looks fine. The only protection against that one is to connect to "https://hotmail.com," and get an authentic redirect if needed. 
> 

But how can you get an authentic redirect, if hotmail.com does not have a CA-issued certificate? And if it does, why not use that rather than a self-signed certificate? 		 	   		  
Received on Monday, 16 December 2013 12:02:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC