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

Greg greg at kinostudios.com
Fri Nov 27 19:22:22 EST 2015

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.


> On Nov 27, 2015, at 4:04 PM, Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:
> On 27/11/15 23:43, Jeffrey Walton wrote:
>> On Fri, Nov 27, 2015 at 5:47 PM, Greg <greg at kinostudios.com> 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 <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 <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 pkix at ietf.org <mailto:pkix at 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 at randombit.net <mailto:cryptography at randombit.net>
>> http://lists.randombit.net/mailman/listinfo/cryptography <http://lists.randombit.net/mailman/listinfo/cryptography>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20151127/05505512/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20151127/05505512/attachment-0001.asc>

More information about the cryptography mailing list