Re: [FORGED] Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 29/05/16 11:48, Peter Gutmann wrote:
> Are you really trying to claim that the sad farce that is current browser PKI
> is absolutely the very best that browser vendors can do in terms of protecting
> users online?

I'm sure things can always be better. My point was that the current
system, for all its flaws, prevents a great deal of evil in a way which
is pretty much totally transparent to users. And that's a big benefit.
We may find, like people find when they analyse passwords and the
alternatives to them, that actually what we have now has some important
features it's hard to replicate in other systems.

>> Whatever the disadvantages of the current system, it must be recognised that
>> it provides the ability for every single Internet user to have their
>> communications with any website that opts-in encrypted on the wire without
>> them having to do, know or configure _anything_. That's huge.
> 
> So would straight anon-DH.  In fact it's interesting to compare the two: Anon-
> DH provides encryption on the wire, as does browser PKI.  Anon-DH has no
> effect on phishing, but then neither does browser PKI.  The one thing that
> anon-DH doesn't handle is MITM 

Oh, a tiny and trivial difference. After all, the one thing we've
learned over the past 3 years or so is that the network is generally
secure and trustworthy, right?

> In terms of "configuration-free idiot-proof secure communications technology",
> the answer is "pretty much anything but browser PKI".  Skype, WhatsApp,
> Signal, Silent Circle (just off the top of my head, I can google several pages
> worth of others if you like) all do a pretty good job of providing secure,
> mutually authenticated communications (which browser PKI still can't do thanks
> to the failure to launch of client certs) without needing any PKI.

And all have a single point of failure. It's much easier, I agree, to do
what WhatsApp did and deploy encryption to every single user if there's
a central controlling entity. (And Signal is moving that way for
precisely that reason, as perhaps you know.) Doing it in a mechanism
over which no party has total control is much harder - but yet, this is
a key and non-negotiable value of the web.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Gervase Markham  writes:

>It depends what alternative configuration-free idiot-proof secure
>communications technology you have invented in your fantasy world to take its
>place.

Are you really trying to claim that the sad farce that is current browser PKI
is absolutely the very best that browser vendors can do in terms of protecting
users online?

>Whatever the disadvantages of the current system, it must be recognised that
>it provides the ability for every single Internet user to have their
>communications with any website that opts-in encrypted on the wire without
>them having to do, know or configure _anything_. That's huge.

So would straight anon-DH.  In fact it's interesting to compare the two: Anon-
DH provides encryption on the wire, as does browser PKI.  Anon-DH has no
effect on phishing, but then neither does browser PKI.  The one thing that
anon-DH doesn't handle is MITM while browser PKI often does, but then again
anon-DH allows automatic, transparent crypto everywhere without having to mess
around with certificates while browser PKI requires it, so let's call that one
a draw depending on which one you consider more important.

In terms of "configuration-free idiot-proof secure communications technology",
the answer is "pretty much anything but browser PKI".  Skype, WhatsApp,
Signal, Silent Circle (just off the top of my head, I can google several pages
worth of others if you like) all do a pretty good job of providing secure,
mutually authenticated communications (which browser PKI still can't do thanks
to the failure to launch of client certs) without needing any PKI.  Just for
one single example, WhatsApp, about a billion or so nontechnical users have no
problems with secure communications.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 27/05/16 13:20, Peter Gutmann wrote:
> Apart from the lucky CAs who have been given government-
> mandated monopolies, would any CA still exist today if there weren't a need to
> pay someone to turn off the browser warnings?

It depends what alternative configuration-free idiot-proof secure
communications technology you have invented in your fantasy world to
take its place.

Whatever the disadvantages of the current system, it must be recognised
that it provides the ability for every single Internet user to have
their communications with any website that opts-in encrypted on the wire
without them having to do, know or configure _anything_. That's huge.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Ryan Sleevi  writes:

>This seems both off-topic and not productively addressing the topic at hand.

Yeah, maybe it's best taken to another list like cypherpunks or the crypto
list.  It was intended as an honest, and probably pretty blunt, assessment of
the state of HTTPS: It was introduced to build consumer, and merchant,
confidence in using the Internet for business, killing the competing SET in
the process, and it's succeeded in doing that.  Once that was done, which
happened about 15-20 years ago, its main role became perpetuating the
existence of CAs.  Apart from the lucky CAs who have been given government-
mandated monopolies, would any CA still exist today if there weren't a need to
pay someone to turn off the browser warnings?

Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: SSL Certs for Malicious Websites

[Hubert Kario]

On Thursday 26 May 2016 05:13:43 Peter Gutmann wrote:
> Richard Z  writes:
> >If any criminal can easily get EV certificates what is the point of
> >https?
> The point of HTTPS is twofold:
> 
> 1. Convince users that the Internet is safe to do business on
> (financial transfers, medical data).
> 
> 2. Provide a steady revenue stream for CAs.
> 
> There's also something about privacy from NSA snooping, but that's a
> recent thing, and mostly only geeks care about it.  In addition
> depending on how paranoid the geeks are, HTTPS may not provide the
> privacy they want).

people don't care only if you are asking the wrong questions[1], if you 
frame the question in the way they do understand, they do care: 
https://www.youtube.com/watch?v=XEVlyP4_11M

 1 - https://www.youtube.com/watch?v=G0ZZJXw4MTA
 
> Finally, point 1 doesn't really need HTTPS, you could just slap a
> padlock into the UI and not bother with encryption.  So it's mostly
> point 2.

I don't think that this level of cynicism is helping...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Richard Z  writes:

>If any criminal can easily get EV certificates what is the point of https?

The point of HTTPS is twofold:

1. Convince users that the Internet is safe to do business on (financial 
   transfers, medical data).

2. Provide a steady revenue stream for CAs.

There's also something about privacy from NSA snooping, but that's a recent 
thing, and mostly only geeks care about it.  In addition depending on how 
paranoid the geeks are, HTTPS may not provide the privacy they want).

Finally, point 1 doesn't really need HTTPS, you could just slap a padlock 
into the UI and not bother with encryption.  So it's mostly point 2.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy