Re: Fwd: IAB Statement on Internet Confidentiality

On Mon, Nov 17, 2014 at 09:56:39AM -0500, Phillip Hallam-Baker wrote:
> On Mon, Nov 17, 2014 at 9:16 AM, Roland Zink <roland@zinks.de> wrote:
> > On 17.11.2014 13:56, Poul-Henning Kamp wrote:
> >>
> >> --------
> >> In message <5469EE2F.2020108@zinks.de>, Roland Zink writes:
> >>
> >> Actually I think the most important part is this:
> >>
> >>>>> Encryption
> >>>>> should be authenticated where possible, but even protocols providing
> >>>>> confidentiality without authentication are useful in the face of
> >>>>> pervasive surveillance as described in RFC 7258.
> >>
> >> Will browsers finally stop treating self-signed-certs as if they
> >> were highly radioaktive ?
> >>
> > Good question. One example is my home router. When I change the name it
> > automatically generates a new self-signed certificate. However when
> > accessing the UI the browser gives an error message and only brave people
> > will probably continue. Others may just fall back to unencrypted http.
> 
> It gets worse.
> 
> The next stage is when the router manufacturer decides to eliminate
> the repeat of the problem by creating a self signed CA cert.
> 
> Alice goes to Bob's router and merrily clicks OK to accept the root
> cert. Congratulations, in the service of 'protecting' Alice, the
> browser has persuaded her to give Bob the ability to sign certs for
> any domain whatsoever.
> 
> People get very excited about the 50 or so audited CAs in the browsers
> and completely ignore the ease of installing a root from an attacker.
> The only controls we get is that these roots can't create EV certs and
> pinning can prevent attacks.
> 
> Out in China, Chu wants to get on a train. To do this she has to use
> the state railway authority Web site. And that requires her to install
> the state railway authority root.
> 
> 
> The solutions to this would be to (1) accept self signed certs with no
> security indicator at all instead of the current practice of giving a
> conflicted security indicator, first signaling the user is 'safe' with
> the padlock, then telling them that they are not state with an idiot
> box (the idiot here being the programmer).
> 
> (2) when a self signed cert signing cert is installed, the browser
> MUST impose a policy constraint on it to only allow it to sign certs
> in the domain for which is was presented. So going to
> https://www.china-railway.com.cn/ does not cause the browser to be
> configured to accept a cert that can sign certs for cnn.com (some
> browsers have been fixed, but I don't know they all have).

That's exactly what I hate in the "tls everywhere" model : all the
case where no security is expected nor desired will train users to
click on various warning boxes all the day, just like it was a few
years ago. And in order to avoid this, browser vendors will make
their lifes easier and will remove the warning, just play with the
background color of the URL bar. Next step will be that in order to
spoof any HTTPS web site, you'll simply have to emit a self-signed
cert that most users will not even understand as something insecure
provided that it works.

I'm sorry guys, but I *want* to be able to use insecure devices without
my browser pretending that I'm doing something securely when that's not
the case, and I don't want to have to support the hassle of clicking
various warnings to confirm that I really want to connect to my newly
unboxed DSL router.

I've already stated it here a few times, he only way I'm seeing something
reasonable is for browsers to behave like this :
  - no access to a website whose cert is not properly signed, with no
    way to bypass this (eg: no "I accept the risks").
  - self-signed (and only self-signed) allowed for plain IP addresses
    without warning.

As a result, we'll see that devices which need to be configured locally,
or developers machines will run on plain IP addresses. Regular web sites
will deploy https only if they feel capable of dealing with what it implies
(ie: pay for supporting a multi-host cert etc). And after this we'll know
whether the current TLS model really is sustainable for each and every web
site or not. Until this is done, we'll continue to see web sites where
improper certs are delivered such as the main site's cert on various
sub-sites.

Willy

Received on Monday, 17 November 2014 16:39:43 UTC