hg.mozilla.org certificate fingerprint changed?

[ISHIKAWA,chiaki]

In the last few days, hg.mozilla.org certificate fingerprint seems to
have changed.
I noticed this because the trial to update local copy of mozilla-central
repository within C-C repository failed due to

m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/']
pulling from https://hg.mozilla.org/mozilla-central/
abort: certificate for hg.mozilla.org has unexpected fingerprint
73:7f:ef:ab:68:0f:49:3f:88:91:f0:b7:06:69:fd:8f:f2:55:c9:56
(check hostfingerprint configuration)

But I did not see any announcement of this change.
(It is possible that I missed it during a hectic schedule during a trip).

However, it is great to see a posting of such major infra change in
advace, especially security-related one.

Finally, I bit the bullet and changed it, but checked bugzilla
just in case, and found
https://bugzilla.mozilla.org/show_bug.cgi?id=1305909
which seems to be related.

Automation is nice, but I still would like to see an announcement of
server certificate change in advance.

TIA

[Ralph Giles]

The change was announced here and on firefox-dev a few weeks ago. See
for example https://groups.google.com/d/msg/mozilla.dev.platform/LOC83qKUPfk/cZtmaEbOAwAJ

It might be nice if `mach mercurial-setup` did this kind of update?

-r

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

[Gregory Szorc]

`mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the
version-control-tools repository, which is where most of the logic for
`mach mercurial-setup` lives (because we have a nice testing harness in
version-control-tools). `mach mercurial-setup` doesn't pin the hash when
invoking `hg pull` because to do so would require vendoring the hash in the
repo and that means if you ran `mach mercurial-setup` on an old revision,
the pinned hash would be guaranteed to be incorrect and the connection
would always fail. We /could/ hardcode the certificate expiration date and
refuse to pin when it is known expired. But if we rotate the cert early,
you're back to a pinned cert failure. Security is hard.

As of a week ago, `mach mercurial-setup` doesn't pin certs if Python +
Mercurial is secure, where "secure" means Mercurial 3.9 and a Python that
can speak modern TLS foo (which sadly many Python installations do not
support, including the system Python on OS X). So unless you are the super
paranoid type who doesn't trust your trusted CA bundle, you can delete the
pinned fingerprints from your hgrc. If `mach mercurial-setup` thinks your
Python+Mercurial is insecure, it will re-add them.

[Ralph Giles]

On Fri, Sep 30, 2016 at 12:33 PM, Gregory Szorc <g...@mozilla.com> wrote:
> `mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the
> version-control-tools repository, which is where most of the logic for `mach
> mercurial-setup` lives (because we have a nice testing harness in
> version-control-tools). `mach mercurial-setup` doesn't pin the hash when
> invoking `hg pull` because to do so would require vendoring the hash in the

> ... that means if you ran `mach mercurial-setup` on an old revision,

> the pinned hash would be guaranteed to be incorrect and the connection would
> always fail.

Hmm. We should be able to use the fact that keys aren't reused. What
if mercurial-setup had a vendored list of keys it knows have been
rotated out in the past and another list which will be rotated in in
the future of that particular revision? It could safely remove the
former if it finds them in .hgrc because if you were able to pull a
revision with that key marked expired, that should still be true when
it's invoked later. Since mercurial 3.8 and later support multiple
fingerprints, it would be safe to add any expected-to-be-used keys, as
long as they aren't later compromised. Setting some kind of time
window beyond which mercurial-setup doesn't attempt to install new
keys would limit the potential damage. No worse that trusting a
particular TLS config?

-r

[ISHIKAWA,chiaki]

On 2016/10/01 4:23, Ralph Giles wrote:
> The change was announced here and on firefox-dev a few weeks ago. See
> for example https://groups.google.com/d/msg/mozilla.dev.platform/LOC83qKUPfk/cZtmaEbOAwAJ
>

Obviously I missed it during a busy trip. Thank you.
(It would be nice to have the announcement on dev-apps-thunderbird and
dev-builds ML as well. I would have noticed this if all these MLs have
the announcement...)

> It might be nice if `mach mercurial-setup` did this kind of update?

As Gregory Szorc <g...@mozilla.com> already noted, it is an egg and
chicken problem. As a matter of fact, I tried "mach mercurial-setup"
just in case, and bumped into the already outdated cert issue since
the data/code used by mach mercurial-setup is taken from hg.mozilla.org.

My |hg| is 3.9.1, but I am not sure if my Python is new enough so that
the security handling mentioned by Gregory works or not.

Short of automation and one-time announcement,
it may be a good idea to have a secure web page that lists the latest
fingerprint of certs used by major mozilla servers that users interact
DIRECTLY (bugzilla and hg come to my mind.)
Then many of us can calmly check the fingerprints for the servers when
some mismatch is reported by tools like ssh/https-related tools, and
decide to update the local check/verification data assuming that they
have missed the update announcements.

TIA