Re: [cryptography] "There is something Google can do. So they should do it."

[Greg]

There’s two types of people in security:

1. Those that believe in security.
2. Those that don’t.

The ones who say “nothing can be done”, or “it’s impossible” (when the fact is 
the opposite), and the ones looking for “exceptions to security” without 
considering ways to mitigate collateral damage on the order of hundreds of 
thousands of users, fit in the latter camp.

Cheers,
Greg

> On Nov 27, 2015, at 4:04 PM, Stephen Farrell  
> wrote:
> 
> 
> On 27/11/15 23:43, Jeffrey Walton wrote:
>> On Fri, Nov 27, 2015 at 5:47 PM, Greg  wrote:
>>> Thought this list would be interested in reading about the roll that Google 
>>> played in compromising 100k+ users (in addition to Dell):
>>> 
>>> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y
>> 
>> They seem to be missing the issue (if I am parsing it correctly):
>> 
>>  REDDIT > So you are saying that Chrome should roll out its own
>>  REDDIT > cert store because relying on Windows 10's cert store is
>>  REDDIT > insecure?
>>  REDDIT >
>>  REDDIT > Sorry your argument seems very weak and odd to me.
>>  REDDIT > It also detracts away from the severity of what Dell has done.
>> 
>> That's not Chrome or Windows per se. Rather, that it is a feature of
>> the Web/Browser security model. In the security model, proxying and
>> interception is a valid use case. You can thank the browser
>> (in)security engineers for that.
>> 
>> It not just limited to W3C participants. The IETF just jumped on the
>> "proxying and interception is a valid use case" bandwagon with RFC
>> 7469, "Public Key Pinning with Overrides"
> 
> That is not actually the title of that RFC.
> 
>> (https://tools.ietf.org/html/rfc7469 ). 
>> Checkout section 4, and then
>> try to find what the override is supposed to do, or additional
>> information or guidance on using it.
> 
> I'm not a fan of that override stuff myself (which is in 2.6 and
> not in section 4 btw) but weren't you yourself [1] a part of that
> discussion in the websec wg? While you may have joined in that part
> of the discussion too late to affect the outcome, I think
> characterising this is "just jumped on ... bandwagon" isn't fair
> nor accurate.
> 
>   [1] https://www.ietf.org/mail-archive/web/websec/current/maillist.html 
> 
> 
>> 
>> Finally, don't look to the IETF to help distinguish the "good" bad
>> guys from the "bad" bad guys when a conforming user agent does
>> override (or tries to decide if it should override). I've been trying
>> to discover that myself. See "How do we differentiate authentic
>> servers from proxies performing TLS interception",
>> https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html.
>> 
>> And finally (and either humorously or sadly, depending on your state
>> of mind), the PKIX's position is there's no difference between
>> authentic server authentication and an imposter pretending to be an
>> authentic server. They are happy to allow a CA to issue certificates
>> for either usage, even though they appear to be as diametrically
>> opposed as you can get.
> 
> IMO the above is a mis-characterisation of the situation and of the
> recent discussion on the p...@ietf.org  mailing list.
> 
> My read of that discussion is that a number of people stated a number
> of times that no matter how much one would like some bit in a protocol
> to distinguish real authentication vs. a MitM with a locally installed
> trust point, there's just no way that can work. I saw that you seemed
> to disagree with that, but tbh I've no idea how what you want could
> work.
> 
> What you're after can't be provided by the IETF. I do agree that
> implementations could handle overrides differently in ways that
> would make it harder do be a MitM.
> 
> I'd also point you at RFC2804 and BCP200 which are other relevant
> IETF publications.
> 
> Cheers,
> S.
> 
>> 
>> The NSA and GCHQ does not need to limit cryptography or algorithms.
>> They just need more browser (in)security engineers in more working
>> groups.
>> 
>> Jeff
>> ___
>> cryptography mailing list
>> cryptography@randombit.net 
>> http://lists.randombit.net/mailman/listinfo/cryptography 
>> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Jeffrey Walton]

On Fri, Nov 27, 2015 at 5:47 PM, Greg  wrote:
> Thought this list would be interested in reading about the roll that Google 
> played in compromising 100k+ users (in addition to Dell):
>
> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y

They seem to be missing the issue (if I am parsing it correctly):

  REDDIT > So you are saying that Chrome should roll out its own
  REDDIT > cert store because relying on Windows 10's cert store is
  REDDIT > insecure?
  REDDIT >
  REDDIT > Sorry your argument seems very weak and odd to me.
  REDDIT > It also detracts away from the severity of what Dell has done.

That's not Chrome or Windows per se. Rather, that it is a feature of
the Web/Browser security model. In the security model, proxying and
interception is a valid use case. You can thank the browser
(in)security engineers for that.

It not just limited to W3C participants. The IETF just jumped on the
"proxying and interception is a valid use case" bandwagon with RFC
7469, "Public Key Pinning with Overrides"
(https://tools.ietf.org/html/rfc7469). Checkout section 4, and then
try to find what the override is supposed to do, or additional
information or guidance on using it.

Finally, don't look to the IETF to help distinguish the "good" bad
guys from the "bad" bad guys when a conforming user agent does
override (or tries to decide if it should override). I've been trying
to discover that myself. See "How do we differentiate authentic
servers from proxies performing TLS interception",
https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html.

And finally (and either humorously or sadly, depending on your state
of mind), the PKIX's position is there's no difference between
authentic server authentication and an imposter pretending to be an
authentic server. They are happy to allow a CA to issue certificates
for either usage, even though they appear to be as diametrically
opposed as you can get.

The NSA and GCHQ does not need to limit cryptography or algorithms.
They just need more browser (in)security engineers in more working
groups.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Stephen Farrell]

On 27/11/15 23:43, Jeffrey Walton wrote:
> On Fri, Nov 27, 2015 at 5:47 PM, Greg  wrote:
>> Thought this list would be interested in reading about the roll that Google 
>> played in compromising 100k+ users (in addition to Dell):
>>
>> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y
> 
> They seem to be missing the issue (if I am parsing it correctly):
> 
>   REDDIT > So you are saying that Chrome should roll out its own
>   REDDIT > cert store because relying on Windows 10's cert store is
>   REDDIT > insecure?
>   REDDIT >
>   REDDIT > Sorry your argument seems very weak and odd to me.
>   REDDIT > It also detracts away from the severity of what Dell has done.
> 
> That's not Chrome or Windows per se. Rather, that it is a feature of
> the Web/Browser security model. In the security model, proxying and
> interception is a valid use case. You can thank the browser
> (in)security engineers for that.
> 
> It not just limited to W3C participants. The IETF just jumped on the
> "proxying and interception is a valid use case" bandwagon with RFC
> 7469, "Public Key Pinning with Overrides"

That is not actually the title of that RFC.

> (https://tools.ietf.org/html/rfc7469). Checkout section 4, and then
> try to find what the override is supposed to do, or additional
> information or guidance on using it.

I'm not a fan of that override stuff myself (which is in 2.6 and
not in section 4 btw) but weren't you yourself [1] a part of that
discussion in the websec wg? While you may have joined in that part
of the discussion too late to affect the outcome, I think
characterising this is "just jumped on ... bandwagon" isn't fair
nor accurate.

   [1] https://www.ietf.org/mail-archive/web/websec/current/maillist.html

> 
> Finally, don't look to the IETF to help distinguish the "good" bad
> guys from the "bad" bad guys when a conforming user agent does
> override (or tries to decide if it should override). I've been trying
> to discover that myself. See "How do we differentiate authentic
> servers from proxies performing TLS interception",
> https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html.
> 
> And finally (and either humorously or sadly, depending on your state
> of mind), the PKIX's position is there's no difference between
> authentic server authentication and an imposter pretending to be an
> authentic server. They are happy to allow a CA to issue certificates
> for either usage, even though they appear to be as diametrically
> opposed as you can get.

IMO the above is a mis-characterisation of the situation and of the
recent discussion on the p...@ietf.org mailing list.

My read of that discussion is that a number of people stated a number
of times that no matter how much one would like some bit in a protocol
to distinguish real authentication vs. a MitM with a locally installed
trust point, there's just no way that can work. I saw that you seemed
to disagree with that, but tbh I've no idea how what you want could
work.

What you're after can't be provided by the IETF. I do agree that
implementations could handle overrides differently in ways that
would make it harder do be a MitM.

I'd also point you at RFC2804 and BCP200 which are other relevant
IETF publications.

Cheers,
S.

> 
> The NSA and GCHQ does not need to limit cryptography or algorithms.
> They just need more browser (in)security engineers in more working
> groups.
> 
> Jeff
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
> 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Tony Arcieri]

On Fri, Nov 27, 2015 at 3:47 PM, Greg  wrote:

> Thought this list would be interested in reading about the roll that
> Google played in compromising 100k+ users (in addition to Dell)


Dell puts a malicious certificate in the local trust store and the
corresponding private key on all of these systems, and they're a mere
parenthetical in your concerns.

Your threat modeling priorities are, to put it bluntly, pretty fucked up
Greg.

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Greg]

> Dell puts a malicious certificate in the local trust store and the 
> corresponding private key on all of these systems, and they're a mere 
> parenthetical in your concerns.

I dedicated about a third of the blog post to Dell and basically called them 
liars. I hardly think that counts as a “ parenthetical”.

> Your threat modeling priorities are, to put it bluntly, pretty fucked up Greg.

Ditto, Tony!

Now let’s move on to real conversations, shall we?

- Greg



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Greg]

If you insist on wasting both our time…

> You are literally using it as a pretext to go after Google.

No, I talked about Dell, then I talked about Google. Both share blame.

>  Can you point to a single time in the past you've mentioned Dell's 
> involvement in this incident without mentioning Google?

Umm… that was my first time mentioning the incident.

And why focus on solely Dell when Google is to blame for breaking HPKP? Dell 
had nothing to do with that.

Your logic is nonexistent.

> Why do you never mention this? Your blog post doesn't mention Firefox once.

First you’re upset with me for going after more than one entity, now you’re 
upset with me for not going after three entities.

Make up your mind Tony.

FWIW, I didn’t mention Firefox in the post because:

1. The article was already long enough.
2. Google is responsible for the RFC.

I did mention Firefox on twitter:

https://twitter.com/taoeffect/status/670366573761138688

And I had the turtles mention Firefox as well:

https://twitter.com/okTurtles/status/670370569087352832

Now let me ask you: why are you not mentioning either Firefox or Google? 
Rhetorical question, I know your answer already, and it’s bullshit.

> Threat: an attacker with local system administrator privileges can override 
> HPKP.

This is Dell and Lenovo we’re talking about.

> This is what you're worried about. You are trying to defend against an 
> attacker with local system administrator privileges.

Dell and Lenovo and anyone who is capable of compromising Dell or Lenovo or any 
other computer manufacturer.

Let’s see, over one hundred THOUSAND people have been compromised, and if I’m 
not mistaken, they are still compromised because of that second cert? And I’m 
guessing 90% probably haven’t applied the fix for the first.

That’s the world’s infrastructure being compromised right there—open for ANYONE 
to exploit.

And you don’t give two shits? F*ck off. You’ve lost your infosec club 
membership.

As the subject says: "There is something Google can do. So they should do it."

- Greg


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Kevin]

On 11/27/2015 5:47 PM, Greg wrote:

Thought this list would be interested in reading about the roll that Google 
played in compromising 100k+ users (in addition to Dell):

https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y

- Greg


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Google is acting strange lately.  I can't help but take note of all of 
the security threats that seem to follow them.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] "There is something Google can do. So they should do it."

[Tony Arcieri]

On Fri, Nov 27, 2015 at 7:34 PM, Greg  wrote:

> I dedicated about a third of the blog post to Dell and basically called
> them liars. I hardly think that counts as a “ parenthetical”.
>

You are literally using it as a pretext to go after Google. Can you point
to a single time in the past you've mentioned Dell's involvement in this
incident without mentioning Google?

Firefox has the same behavior for HPKP:

https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning

"Allow User MITM (pinning not enforced if the trust anchor is a user
inserted CA, default)"

Why do you never mention this? Your blog post doesn't mention Firefox once.


>
> > Your threat modeling priorities are, to put it bluntly, pretty fucked up
> Greg.
>
> Ditto, Tony!


Threat: an attacker with local system administrator privileges can override
HPKP.

This is what you're worried about. You are trying to defend against an
attacker with local system administrator privileges.

If your local truststore is compromised, your system is compromised. Your
best bets are to reinstall the entire operating system or get a new
computer.

You are worried the door lock is pickable when the house is on fire.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] "There is something Google can do. So they should do it."

[Greg]

Thought this list would be interested in reading about the roll that Google 
played in compromising 100k+ users (in addition to Dell):

https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y

- Greg


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography