Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

[Daniel Holbert]

Heads-up, from a user-complaint/ support / "keep an eye out for this"
perspective:
* Starting January 1st 2016 (a few days ago), Firefox rejects
recently-issued SSL certs that use the (obsolete) SHA1 hash algorithm.[1]

* For users who unknowingly have a local SSL proxy on their machine
from spyware/adware/antivirus (stuff like superfish), this may cause
*all* HTTPS pages to fail in Firefox, if their spyware uses SHA1 in its
autogenerated certificates. (Every cert that gets sent to Firefox will
use SHA1 and will have an issued date of "just now", which is after
January 1 2016; hence, the cert is untrusted, even if the spyware put
its root in our root store.)

* I'm not sure what action we should (or can) take about this, but for
now we should be on the lookout for this, and perhaps consider writing a
support article about it if we haven't already. (Not sure there's much
help we can offer, since removing spyware correctly/completely can be
tricky and varies on a case by case basis.)

(Context: I received a family-friend-Firefox-support phone call today,
who this had this exact problem. Every HTTPS site was broken for her in
Firefox, since January 1st. IE worked as expected (that is, it happily
accepts the spyware's SHA1 certs, for now at least). I wasn't able to
remotely figure out what the piece of spyware was or how to remove it --
but the rejected certs reported their issuer as being "Digital Marketing
Research App" (instead of e.g. Digicert or Verisign). Googling didn't
turn up anything useful, unfortunately; so I suspect this is "niche"
spyware, or perhaps the name is dynamically generated.)

Anyway -- I have a feeling this will be somewhat-widespread problem,
among users who have spyware (and perhaps crufty "secure browsing"
antivirus tools) installed.

~Daniel

[1]
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

[Richard Barnes]

Hey Daniel,

Thanks for the heads-up. This is a useful thing to keep in mind as we work
through the SHA-1 deprecation.

To be honest, this seems like a net positive to me, since it gives users a
clear incentive to uninstall this sort of software.

--Richard

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Bobby Holley]

On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes <rba...@mozilla.com> wrote:

> Hey Daniel,
>
> Thanks for the heads-up. This is a useful thing to keep in mind as we work
> through the SHA-1 deprecation.
>
> To be honest, this seems like a net positive to me, since it gives users a
> clear incentive to uninstall this sort of software.
>

By "this sort of software" do you mean "Firefox"? Because that's what 95%
of our users experiencing this are going to do absent anything clever on
our end.

We clearly need to determine the scale of the problem to determine how much
time it's worth investing into this. But I think we should assume that an
affected user is a lost use in this case.

bholley

[Mike Hoye]

On 2016-01-04 12:31 PM, Bobby Holley wrote:
> By "this sort of software" do you mean "Firefox"? Because that's what
> 95% of our users experiencing this are going to do absent anything
> clever on our end. We clearly need to determine the scale of the
> problem to determine how much time it's worth investing into this. But
> I think we should assume that an affected user is a lost use in this case

Is consumer-grade home networking gear on our radar here? Many, many
home APs will self-generate SHA-1 certificates on their first boot after
a reset.


- mhoye

[Eric Rescorla]

On Mon, Jan 4, 2016 at 9:31 AM, Bobby Holley <bobby...@gmail.com> wrote:

> On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes <rba...@mozilla.com>
> wrote:
>
> > Hey Daniel,
> >
> > Thanks for the heads-up. This is a useful thing to keep in mind as we
> work
> > through the SHA-1 deprecation.
> >
> > To be honest, this seems like a net positive to me, since it gives users
> a
> > clear incentive to uninstall this sort of software.
> >
>

> By "this sort of software" do you mean "Firefox"? Because that's what 95%
> of our users experiencing this are going to do absent anything clever on
> our end.
>
> We clearly need to determine the scale of the problem to determine how much
> time it's worth investing into this. But I think we should assume that an

> affected user is a lost use in this case.
>

I believe that Chrome will be making a similar change at a similar time

-Ekr

[Eric Rescorla]

On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye <mh...@mozilla.com> wrote:

> On 2016-01-04 12:31 PM, Bobby Holley wrote:
>

>> By "this sort of software" do you mean "Firefox"? Because that's what 95%
>> of our users experiencing this are going to do absent anything clever on
>> our end. We clearly need to determine the scale of the problem to determine
>> how much time it's worth investing into this. But I think we should assume

>> that an affected user is a lost use in this case
>>
> Is consumer-grade home networking gear on our radar here? Many, many home
> APs will self-generate SHA-1 certificates on their first boot after a reset.
>

The certificates from those devices aren't valid in any case, because
they do not chain to a trust anchor.

-Ekr


>
> - mhoye

[Daniel Holbert]

On 01/04/2016 09:47 AM, Eric Rescorla wrote:
> I believe that Chrome will be making a similar change at a similar time
>
> -Ekr

In contrast, it looks like IE & Edge will continue accepting SHA1 certs
on the web for another full year, until 2017. [1][2]

~Daniel

[1] https://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/
[2]
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/973/102/important-change-announcement---deprecation-of-sha-1

[Eric Rescorla]

I believe you are confusing two different things.

1. Whether the browser supports SHA-1 certificates at all.
2. Whether the browser supports SHA-1 certificates signed after Jan 1 2016
(The CA/BF Baseline Requirements forbid this, so no publicly valid
certificate
should fall into this category).

It's not clear to me how IE/Edge are behaving with respect to #2.

-Ekr



On Mon, Jan 4, 2016 at 10:14 AM, Daniel Holbert <dhol...@mozilla.com>
wrote:

[Mike Hoye]

On 2016-01-04 12:48 PM, Eric Rescorla wrote:
> On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye <mh...@mozilla.com
> <mailto:mh...@mozilla.com>> wrote:
>
> On 2016-01-04 12:31 PM, Bobby Holley wrote:
>
> By "this sort of software" do you mean "Firefox"? Because
> that's what 95% of our users experiencing this are going to do
> absent anything clever on our end. We clearly need to
> determine the scale of the problem to determine how much time
> it's worth investing into this. But I think we should assume
> that an affected user is a lost use in this case
>
> Is consumer-grade home networking gear on our radar here? Many,
> many home APs will self-generate SHA-1 certificates on their first
> boot after a reset.
>
>
> The certificates from those devices aren't valid in any case, because
> they do not chain to a trust anchor.

I'm really asking about the user experience. If it's the same "add an
exception and proceed" process, that's not great, but we're no worse off
and my concerns are unfounded.


- mhoye

[Adam Roach]

On 1/4/16 2:19 AM, Daniel Holbert wrote:
> I'm not sure what action we should (or can) take about this, but for
> now we should be on the lookout for this, and perhaps consider writing a
> support article about it if we haven't already.

I propose that we minimally should collect telemetry around this
condition. It should be pretty easy to detect: look for cases where we
reject very young SHA-1 certs that chain back to a CA we don't ship.
Once we know the scope of the problem, we can make informed decisions
about how urgent our subsequent actions should be.

It would also be potentially useful to know the cert issuer in these
cases, since that might allow us to make some guesses about whether the
failures are caused by malware, well-intentioned but kludgy malware
detectors, or enterprise gateways. Working out how to do that in a way
that respects privacy and user agency may be tricky, so I'd propose we
go for the simple count first.

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

[Daniel Holbert]

On 01/04/2016 10:21 AM, Adam Roach wrote:
> I propose that we minimally should collect telemetry around this
> condition. It should be pretty easy to detect: look for cases where we
> reject very young SHA-1 certs that chain back to a CA we don't ship.
> Once we know the scope of the problem, we can make informed decisions
> about how urgent our subsequent actions should be.

I had a similar thought, but I think it's too late for such telemetry to
be effective. The vast majority of users who are affected will have
already stopped using Firefox, or will immediately do so, as soon as
they discover that their webmail, bank, google, facebook, etc. don't work.

(We could have used this sort of telemetry before Jan 1 if we'd forseen
this potential problem. I don't blame us for not forseeing this, though.)

~Daniel

[Daniel Holbert]

On 01/04/2016 10:18 AM, Eric Rescorla wrote:
> I believe you are confusing two different things.
>
> 1. Whether the browser supports SHA-1 certificates at all.
> 2. Whether the browser supports SHA-1 certificates signed after Jan 1 2016
> (The CA/BF Baseline Requirements forbid this, so no publicly valid
> certificate
> should fall into this category).
>
> It's not clear to me how IE/Edge are behaving with respect to #2.

Sorry, I wasn't clear.

What I was saying was
* The definitive statements I've found from/about MS about SHA1 on the
web *only* mention your point #1 (and do not mention anything about #2).
* My one data point, from this affected user, indicates that IE still
works just fine with freshly-minted SHA1 certs.

So, in the absence of statements about #2 (and in the presence of proof
otherwise), I see no reason to think Microsoft is taking action on that
point.

~Daniel

[Josh Matthews]

Wouldn't the SSL cert failures also prevent submitting the telemetry
payload to Mozilla's servers?

Cheers,
Josh

[Richard Barnes]

On Mon, Jan 4, 2016 at 12:31 PM, Bobby Holley <bobby...@gmail.com> wrote:

> On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes <rba...@mozilla.com>
> wrote:
>
>> Hey Daniel,
>>
>> Thanks for the heads-up. This is a useful thing to keep in mind as we
>> work
>> through the SHA-1 deprecation.
>>
>> To be honest, this seems like a net positive to me, since it gives users a
>> clear incentive to uninstall this sort of software.
>>
>

> By "this sort of software" do you mean "Firefox"? Because that's what 95%
> of our users experiencing this are going to do absent anything clever on
> our end.
>
> We clearly need to determine the scale of the problem to determine how
> much time it's worth investing into this. But I think we should assume that

> an affected user is a lost use in this case.
>

I was being a bit glib because I think in a lot of cases, it won't be just
Firefox that's affected -- all of the user's HTTPS will quit working,
across all browsers.

I agree that it would be good to get more data here. I think Adam is on
the right track.

--Richard


>
> bholley
>
>
>
>>
>> --Richard

>>
>> On Mon, Jan 4, 2016 at 3:19 AM, Daniel Holbert <dhol...@mozilla.com>
>> wrote:
>>
>> > Heads-up, from a user-complaint/ support / "keep an eye out for this"
>> > perspective:
>> > * Starting January 1st 2016 (a few days ago), Firefox rejects
>> > recently-issued SSL certs that use the (obsolete) SHA1 hash
>> algorithm.[1]
>> >
>> > * For users who unknowingly have a local SSL proxy on their machine
>> > from spyware/adware/antivirus (stuff like superfish), this may cause
>> > *all* HTTPS pages to fail in Firefox, if their spyware uses SHA1 in its
>> > autogenerated certificates. (Every cert that gets sent to Firefox will
>> > use SHA1 and will have an issued date of "just now", which is after
>> > January 1 2016; hence, the cert is untrusted, even if the spyware put
>> > its root in our root store.)
>> >

>> > * I'm not sure what action we should (or can) take about this, but for

>> > now we should be on the lookout for this, and perhaps consider writing a

>> > support article about it if we haven't already. (Not sure there's much
>> > help we can offer, since removing spyware correctly/completely can be
>> > tricky and varies on a case by case basis.)
>> >
>> > (Context: I received a family-friend-Firefox-support phone call today,
>> > who this had this exact problem. Every HTTPS site was broken for her in
>> > Firefox, since January 1st. IE worked as expected (that is, it happily
>> > accepts the spyware's SHA1 certs, for now at least). I wasn't able to
>> > remotely figure out what the piece of spyware was or how to remove it --
>> > but the rejected certs reported their issuer as being "Digital Marketing
>> > Research App" (instead of e.g. Digicert or Verisign). Googling didn't
>> > turn up anything useful, unfortunately; so I suspect this is "niche"
>> > spyware, or perhaps the name is dynamically generated.)
>> >
>> > Anyway -- I have a feeling this will be somewhat-widespread problem,
>> > among users who have spyware (and perhaps crufty "secure browsing"
>> > antivirus tools) installed.
>> >
>> > ~Daniel
>> >
>> > [1]
>> >
>> >
>> https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/

[Daniel Holbert]

On 01/04/2016 10:33 AM, Josh Matthews wrote:
> Wouldn't the SSL cert failures also prevent submitting the telemetry
> payload to Mozilla's servers?

Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
for that matter! (I'm assuming the update-check is performed over HTTPS.)

So there might be literally nothing we can do to improve the situation
for these users, from a changes-to-Firefox perspective.

Even if we wanted to take the extreme measure of issuing an update to
delay our new-SHA1-certs-not-trusted-after date (extremely
hypothetical), this wouldn't help users who are affected by this
problem, because they couldn't receive the update (I think).

[Daniel Holbert]

On 01/04/2016 10:43 AM, Richard Barnes wrote:
> I was being a bit glib because I think in a lot of cases, it won't be
> just Firefox that's affected -- all of the user's HTTPS will quit
> working, across all browsers.

As noted else-thread, IE seems to be working just fine, and I'm not sure
it'll stop doing so until 2017.

~Daniel

[Chris Peterson]

On 1/4/16 10:45 AM, Daniel Holbert wrote:
> On 01/04/2016 10:33 AM, Josh Matthews wrote:
>> >Wouldn't the SSL cert failures also prevent submitting the telemetry
>> >payload to Mozilla's servers?
> Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
> for that matter! (I'm assuming the update-check is performed over HTTPS.)
>
> So there might be literally nothing we can do to improve the situation
> for these users, from a changes-to-Firefox perspective.

On Windows, Firefox is updated by a background service (the Mozilla
Maintenance Service). Will the SHA-1/spyware proxy breakage affect the
background service?

[Adam Roach]

On 1/4/16 12:29 PM, Daniel Holbert wrote:
> I had a similar thought, but I think it's too late for such telemetry to
> be effective. The vast majority of users who are affected will have
> already stopped using Firefox, or will immediately do so, as soon as
> they discover that their webmail, bank, google, facebook, etc. don't work.

That's a valid point for the first batch of users that is hit with the
issue on day one. (Aside: I wonder what the preponderant behavior will
be when Chrome also starts choking on those sites.) It'll be interesting
to see whether there's a detectable decline in user count that
correlates with the beginning of the year.

At the same time, I know that Google tends to measure quite a bit about
Chrome's behavior. Lacking our own numbers, perhaps we reach out to them
and ask if they're willing to share what they know.

In any case, people install new things all the time. While it is too
late to catch the large wave of users who are running into the problem
this week, it would be nice to have data about this problem on an
ongoing basis.

> (We could have used this sort of telemetry before Jan 1 if we'd forseen
> this potential problem. I don't blame us for not forseeing this, though.)

You're correct: given our current habits, it's understandable that no
one thought to measure this. I think there's an object lesson to be
learned here.

Mozilla has a clear and stated intention to be more data driven in how
we do things. One of the points that Benjamin Smedberg has been trying
to drive home is that data collection is everyone's job. In the same way
that we would never land code without thinking about how to test it, we
need to develop a mindset in which we don't land code without
considering whether and how to measure it. It's not a perfect analogy,
since many things won't need specific new metrics, but it should be part
of the mental checklist: "did I think about whether we need to measure
anything about this feature?"

If just asking that question were part of our culture, I'm certain we
would have thought of landing exactly this kind telemetry as part of the
same patch that disabled SHA-1; or, even better, in advance of it.

[Richard Barnes]

First a bit of good news: The overall trend line for SHA-1 errors is not
spiking (yet). Bin 6 of SSL_CERT_VERIFICATION_ERRORS corresponds to
ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED, which is what you get when you
reject a bad SHA-1 cert.

https://ipv.sx/telemetry/general-v2.html?channels=beta%20release&measure=SSL_CERT_VERIFICATION_ERRORS&target=6

Now for the bad news: Telemetry is actually useless for the specific case
we're talking about here. Telemetry is submitted over HTTPS (about:config
/ toolkit.telemetry.server), so measurements from affected clients will
never reach the server.

So we can't get any measurements unless we revert the SHA-1 intolerance.
Given this, I'm sort of inclined to do that, collect some data, then maybe
re-enable it in 45 or 46. What do others think?

--Richard

On Mon, Jan 4, 2016 at 1:43 PM, Richard Barnes <rba...@mozilla.com> wrote:

>
>
> On Mon, Jan 4, 2016 at 12:31 PM, Bobby Holley <bobby...@gmail.com>
> wrote:
>
>> On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes <rba...@mozilla.com>
>> wrote:
>>
>>> Hey Daniel,
>>>
>>> Thanks for the heads-up. This is a useful thing to keep in mind as we
>>> work
>>> through the SHA-1 deprecation.
>>>
>>> To be honest, this seems like a net positive to me, since it gives users
>>> a
>>> clear incentive to uninstall this sort of software.
>>>
>>
>> By "this sort of software" do you mean "Firefox"? Because that's what 95%
>> of our users experiencing this are going to do absent anything clever on
>> our end.
>>
>> We clearly need to determine the scale of the problem to determine how
>> much time it's worth investing into this. But I think we should assume that
>> an affected user is a lost use in this case.
>>
>

> I was being a bit glib because I think in a lot of cases, it won't be just
> Firefox that's affected -- all of the user's HTTPS will quit working,
> across all browsers.
>

[Tanvi Vyas]

On 1/4/16 11:20 AM, Richard Barnes wrote:
> First a bit of good news: The overall trend line for SHA-1 errors is not
> spiking (yet). Bin 6 of SSL_CERT_VERIFICATION_ERRORS corresponds to
> ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED, which is what you get when you
> reject a bad SHA-1 cert.
>
> https://ipv.sx/telemetry/general-v2.html?channels=beta%20release&measure=SSL_CERT_VERIFICATION_ERRORS&target=6
>
> Now for the bad news: Telemetry is actually useless for the specific case
> we're talking about here. Telemetry is submitted over HTTPS (about:config
> / toolkit.telemetry.server), so measurements from affected clients will
> never reach the server.
>
> So we can't get any measurements unless we revert the SHA-1 intolerance.
> Given this, I'm sort of inclined to do that, collect some data, then maybe
> re-enable it in 45 or 46. What do others think?

I agree that we should revert the change (assuming its not already too
late given updates are over HTTPS) until we figure out how widespread
this problem is and determine how to handle it.

[Adam Roach]

On 1/4/16 1:00 PM, Adam Roach wrote:
> One of the points that Benjamin Smedberg has been trying to drive home
> is that data collection is everyone's job.

After sending, I realized that this is a slight misquote. It should have
been "data is everyone's job" (i.e.: there's more to data than collection).

[Daniel Holbert]

On 01/04/2016 12:19 AM, Daniel Holbert wrote:
> I wasn't able to
> remotely figure out what the piece of spyware was or how to remove it --
> but the rejected certs reported their issuer as being "Digital Marketing
> Research App" (instead of e.g. Digicert or Verisign). Googling didn't
> turn up anything useful, unfortunately; so I suspect this is "niche"
> spyware, or perhaps the name is dynamically generated.)

UPDATE: in my family friend's case, the shoddy MITM spyware in question
was "Simmons Connect Research Application", a consumer profiling tool
that's tied to Experian which users can voluntarily install in exchange
for points that you can use to buy stuff.

She was able to fix the problem by uninstalling that program (simmons
connect research application).

~Daniel

[jve...@mozilla.com]

On Monday, January 4, 2016 at 2:27:57 PM UTC-5, Tanvi Vyas wrote:
> On 1/4/16 11:20 AM, Richard Barnes wrote:
> > So we can't get any measurements unless we revert the SHA-1 intolerance.
> > Given this, I'm sort of inclined to do that, collect some data, then maybe
> > re-enable it in 45 or 46. What do others think?
>
> I agree that we should revert the change (assuming its not already too
> late given updates are over HTTPS) until we figure out how widespread
> this problem is and determine how to handle it.
>

Updates are pulled from https://aus[2-5].mozilla.org/update/... They should be broken as well for those users.

- Julien

[Robert Strong]

On Mon, Jan 4, 2016 at 10:53 AM, Chris Peterson <cpet...@mozilla.com>
wrote:

The maintenance service does not have network access and the update check
and download occur within Firefox itself. The update check and download has
already been addressed via several bugs.

Robert

[Robert Strong]

On Mon, Jan 4, 2016 at 12:37 PM, Robert Strong <rst...@mozilla.com> wrote:

>
>
> On Mon, Jan 4, 2016 at 10:53 AM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>

> The maintenance service does not have network access and the update check
> and download occur within Firefox itself. The update check and download has
> already been addressed via several bugs.
>

I unintentionally made it seem that this would also handle the MITM case
which is not handled by any of these bugs since app update just utilizes
built-in Firefox networking.

[Daniel Holbert]

On 01/04/2016 12:07 PM, Daniel Holbert wrote:
> UPDATE: in my family friend's case, the shoddy MITM spyware in question
> was "Simmons Connect Research Application", a consumer profiling tool
> that's tied to Experian which users can voluntarily install in exchange
> for points that you can use to buy stuff.

I reached out to Experian on Twitter:
https://twitter.com/CodingExon/status/684105591288008704
...and also via a web form on one of their Simmons Connect pages.

I also sent the following to
http://www.digitalmarketresearchapps.com/contact.html , which seems to
be the HTTPS interception library that they're using:
======================
Hi,
I'm a software engineer at Mozilla, working on the Firefox web browser,
and I'm contacting you about something extremely urgent -- I'm hoping to
reach an engineer who works on your HTTPS interception library/tool.

As of January 1st (several days ago), your tool *entirely breaks* HTTPS
connections in Firefox, due to your tool's reliance on a deprecated
security algorithm called SHA1. The importance of this is hard to
overstate -- for users who have your tool installed, their internet
access is *completely* broken, including their ability to download
browser updates. Chrome users are (or will soon be) affected as well,
and Internet Explorer/Edge users will be affected at some point in the
next year -- all browsers are coordinating on phasing out SHA1
certificate support.

Specifically:
Based on a user report, it seems "Digital Market Research Apps" is
issuing certificates for a consumer profiling tool called "Simmons
Connect". As of January 1st, this user was unable to visit any HTTPS
site in Firefox, because the tool was providing newly-generated
certificates using the obsolete SHA1 algorithm. And per
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
, such certificates are treated as untrusted.

Please contact me as soon as possible. For users with your software
installed, it's of the utmost urgency that you issue an update, to make
your certificates use a newer algorithm than SHA1.

[Jesper Kristensen]

Den 04-01-2016 kl. 19:45 skrev Daniel Holbert:
> On 01/04/2016 10:33 AM, Josh Matthews wrote:
>> Wouldn't the SSL cert failures also prevent submitting the telemetry
>> payload to Mozilla's servers?
>
> Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
> for that matter! (I'm assuming the update-check is performed over HTTPS.)

If I remember correctly, update checks are pinned to a specific CA, so
updates for users with software that MITM AUS would already be broken?

[Robert Strong]

That was removed awhile ago in favor of using mar signing as an exploit
mitigation.

[Dave Townsend]

aus5 (the server the app updater checks) is still pinned:
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739

On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong <rst...@mozilla.com> wrote:
> On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
> moznew...@something.to.remove.jesperkristensen.dk> wrote:
>

[Daniel Holbert]

For reference, I've now filed a bug to cover outreach for the specific
tool that this user was using:
https://bugzilla.mozilla.org/show_bug.cgi?id=1236664

I'm also trying to get my hands on the software, but it's "invitation
only", so that may prove difficult.

~Daniel

[Robert Strong]

I was under the impression (perhaps falsely) that the params for those
entries made it so that aus4 and aus5 don't enforce pinning.

On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend <dtow...@mozilla.com> wrote:

> aus5 (the server the app updater checks) is still pinned:
>
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739
>
> On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong <rst...@mozilla.com>
> wrote:
> > On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
> > moznew...@something.to.remove.jesperkristensen.dk> wrote:
> >

[Robert Strong]

On Mon, Jan 4, 2016 at 1:11 PM, Robert Strong <rst...@mozilla.com> wrote:

> I was under the impression (perhaps falsely) that the params for those
> entries made it so that aus4 and aus5 don't enforce pinning.
>

and the pinning hack I added years ago was removed.

>
>
>
> On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend <dtow...@mozilla.com>
> wrote:
>
>> aus5 (the server the app updater checks) is still pinned:
>>
>> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739
>>
>> On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong <rst...@mozilla.com>
>> wrote:
>> > On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
>> > moznew...@something.to.remove.jesperkristensen.dk> wrote:
>> >

[David Keeler]

> { "aus5.mozilla.org", true, true, true, 7, &kPinset_mozilla },

Just for clarification and future reference, the second "true" means this
entry is in test mode, so it's not actually enforced by default.

On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend <dtow...@mozilla.com> wrote:

> aus5 (the server the app updater checks) is still pinned:
>
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739
>
> On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong <rst...@mozilla.com>
> wrote:
> > On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
> > moznew...@something.to.remove.jesperkristensen.dk> wrote:
> >

[Richard Barnes]

In any case, the pin check doesn't matter. The certificate verification
will have failed well before the pin checks are done.

On Mon, Jan 4, 2016 at 4:14 PM, David Keeler <dke...@mozilla.com> wrote:

> > { "aus5.mozilla.org", true, true, true, 7, &kPinset_mozilla },
>
> Just for clarification and future reference, the second "true" means this
> entry is in test mode, so it's not actually enforced by default.
>
> On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend <dtow...@mozilla.com>
> wrote:
>
> > aus5 (the server the app updater checks) is still pinned:
> >
> >
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739
> >
> > On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong <rst...@mozilla.com>
> > wrote:
> > > On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
> > > moznew...@something.to.remove.jesperkristensen.dk> wrote:
> > >