Private key corresponding to public key in trusted Cisco certificate embedded in executable

[Koen Rouwhorst]

Hi all,

Last weekend, in an attempt to get Sky's NOW TV video player (for Mac) to work on my machine, I noticed that one of the Cisco executables contains a private key that is associated with the public key in a trusted certificate for a cisco.com <http://cisco.com/> sub domain (drmlocal.cisco.com <http://drmlocal.cisco.com/>). This certificate is used in a local WebSocket server, presumably to allow secure Sky/NOW TV origins to communicate with the video player on the users' local machines.

I read the Baseline Requirements document (version 1.4.5, section 4.9.1.1), but I wasn't entirely sure whether this is considered a key compromise. I asked Hanno Böck on Twitter (https://twitter.com/koenrh/status/873869275529957376 <https://twitter.com/koenrh/status/873869275529957376>), and he advised me to post the matter to this mailing list.

The executable containing the private key is named 'CiscoVideoGuardMonitor', and is shipped as part of the NOW TV video player. In case you are interested, the installer can be found at https://web.static.nowtv.com/watch/NowTVPlayerInstaller.pkg <https://web.static.nowtv.com/watch/NowTVPlayerInstaller.pkg> (SHA-256: 56feeef4c3d141562900f9f0339b120d4db07ae2777cc73a31e3b830022241e6). I would recommend to run this installer in a virtual machine, because it drops files all over the place, and installs a few launch items (agents/daemons). The executable 'CiscoVideoGuardMonitor' can be found at '$HOME/Library/Cisco/VideoGuardPlayer/VideoGuardMonitor/VideoGuardMonitor.bundle/Contents/MacOS/CiscoVideoGuardMonitor'.

Certificate details:

Serial number: 66170CE2EC8B7D88B4E2EB732E738FE3A67CF672
DNS names: drmlocal.cisco.com <http://drmlocal.cisco.com/>
Issued by: HydrantID SSL ICA G2

Leaf certificate + HydrantID intermediate:
https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-certificates-pem <https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-certificates-pem>

As proof, I have published a verification message in a GitHub Gist, and signed the message using the compromised private key. See: https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-message-txt <https://gist.github.com/koenrh/bf2a7eee03c9100be37d30b92760f5ab#file-message-txt> (verify using: 'openssl dgst -sha256 -verify public-key.pem -signature message.txt.sig message.txt')

If this is indeed considered a key compromise, where do I go from here, and what are the recommended steps to take? Do I need to contact the subscriber (Cisco), and ask them to send a revocation request for this certificate to the issuer? Or do I need to notify the issuer (HydrantID), and ask them to revoke this certificate?

Thanks.

Best regards,
Koen Rouwhorst

[Daniel Cater]

This is now on crt.sh here: https://crt.sh/?id=156475584&opt=cablint,x509lint

This is indeed a key compromise event, thanks for the level of detail provided.

An attacker in control of a network could use this to impersonate https://drmlocal.cisco.com/ and leverage that to potentially steal a user's secure cookies from other Cisco subdomains if they were scoped to the whole cisco.com domain.

[Ryan Sleevi]

As Daniel noted, this is considered a key compromise event, and a violation
of the subscriber agreement that all CAs are required to adhere to, with
respect to the protection of the private key.

The issuing CA is obligated to revoke this certificate within 24 hours of
being made aware of this.

Thank you for bringing it to the community's attention.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Eric Mill]

One question though, is whether the key was compromised at the time of
intentionally shipping​ it in a distributed executable. That choice
knowingly exposed the key to arbitrary public users, even if they didn't
expect this to happen from doing so.

-- Eric

On Jun 18, 2017 10:24 AM, "Ryan Sleevi via dev-security-policy" <

[Stephen Davidson]

Hello:

Thank you for alerting us. The issuer HydrantID has communicated with the certificate holder Cisco, and the certificate has been revoked.

Kind regards, Stephen Davidson
QuoVadis


________________________________________
From: dev-security-policy [dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] on behalf of Koen Rouwhorst via dev-security-policy [dev-secur...@lists.mozilla.org]
Sent: Sunday, June 18, 2017 6:18 AM
To: Nick Lamb via dev-security-policy
Subject: Private key corresponding to public key in trusted Cisco certificate embedded in executable

[Nick Lamb]

On Sunday, 18 June 2017 16:37:13 UTC+1, Eric Mill wrote:
> One question though, is whether the key was compromised at the time of
> intentionally shipping​ it in a distributed executable. That choice
> knowingly exposed the key to arbitrary public users, even if they didn't
> expect this to happen from doing so.

Yes, the subscriber intentionally compromised this key when they implemented this decision. This was a foreseeable consequence. If they didn't foresee it, that's not because it wasn't foreseeable but because they're foolish. A reasonable person who understood what was going on here (public key cryptography, the purpose of certificates in the Web PKI) should have understood they were intentionally compromising their key.

[qwerty...@gmail.com]

You assume too much about a "reasonable person".
Yes, most developers understand PKI / key management to a point, but many (many) just don't, or do and simply make the mistake of not thinking it through, like many other software defects. Bottom line - could happen unintentionally.

[troy.f...@cisco.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen,

The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again.

If you should find such an issue again in a Cisco owned domain, please report it to ps...@cisco.com and we will ensure that prompt and proper actions are taken.

Regards,
- -Troy

- --
Troy Fridley, CISSP
Incident Manager, Cisco PSIRT
Phone: 614-336-4385
E-Mail: troy.fridleyATcisco.com
PGP Key ID: 0x7B31ED20
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAllGmSwACgkQ1ANYX3sx7SASCgCg/ABvJQZSZf+pIG16AMgMPwF8
z4oAnRrpx2I5NJizxg2H1aftlwyJ15fT
=ayil
-----END PGP SIGNATURE-----

[Ryan Sleevi]

Section 9.6.3, Items 2, 4, and 5, of Baseline Requirements 1.4.5 (current
version)

On Sun, Jun 18, 2017 at 11:36 AM, Eric Mill via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> One question though, is whether the key was compromised at the time of
> intentionally shipping​ it in a distributed executable. That choice
> knowingly exposed the key to arbitrary public users, even if they didn't
> expect this to happen from doing so.
>

> -- Eric
>
> On Jun 18, 2017 10:24 AM, "Ryan Sleevi via dev-security-policy" <
> dev-secur...@lists.mozilla.org> wrote:
>
> > As Daniel noted, this is considered a key compromise event, and a
> violation
> > of the subscriber agreement that all CAs are required to adhere to, with
> > respect to the protection of the private key.
> >
> > The issuing CA is obligated to revoke this certificate within 24 hours of
> > being made aware of this.
> >
> > Thank you for bringing it to the community's attention.
> >
> > On Sun, Jun 18, 2017 at 12:29 PM Daniel Cater via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > This is now on crt.sh here:
> > > https://crt.sh/?id=156475584&opt=cablint,x509lint
> > >
> > > This is indeed a key compromise event, thanks for the level of detail
> > > provided.
> > >
> > > An attacker in control of a network could use this to impersonate
> > > https://drmlocal.cisco.com/ and leverage that to potentially steal a
> > > user's secure cookies from other Cisco subdomains if they were scoped
> to
> > > the whole cisco.com domain.

[Nick Lamb]

On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote:
> The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again.

Troy, the name makes me suspicious, what - other than this trick which isn't a permissible use - was the drmlocal.cisco.com name ever for in the first place? If it doesn't have any legitimate use, there was no purpose in seeking a re-issue of the certificate.

The right way to approach this problem will be to issue unique keys and certificates to individual instances of the system, this both satisfies the BRs and (which is why) achieves the actual security goal of partitioning each customer so that they can't MitM each other.

It is a little surprising to me that (at least so far as I know) no manufacturer has an arrangement with a CA to issue them large volumes of per-device certificates in this way. I expect that Comodo (to name one which definitely has business issuing very large volumes) would be able to accommodate a deal to issue say, a million certificates per year with an agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted there would be some engineering work to be done in production and software for the system, but nothing truly novel and that work is re-usable for future products.

[Robin Alden]

Nick,
We do exactly that for some device producers already.

Robin Alden, Comodo. (Sent from my phone)

---- Nick Lamb via dev-security-policy wrote ----

>On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote:

>> The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again.
>

>Troy, the name makes me suspicious, what - other than this trick which isn't a permissible use - was the drmlocal.cisco.com name ever for in the first place? If it doesn't have any legitimate use, there was no purpose in seeking a re-issue of the certificate.
>
>The right way to approach this problem will be to issue unique keys and certificates to individual instances of the system, this both satisfies the BRs and (which is why) achieves the actual security goal of partitioning each customer so that they can't MitM each other.
>
>It is a little surprising to me that (at least so far as I know) no manufacturer has an arrangement with a CA to issue them large volumes of per-device certificates in this way. I expect that Comodo (to name one which definitely has business issuing very large volumes) would be able to accommodate a deal to issue say, a million certificates per year with an agreed suffix (say, .nowtv.cisco.com) for a fixed fee. The first time it's attempted there would be some engineering work to be done in production and software for the system, but nothing truly novel and that work is re-usable for future products.

[Robin Alden]

Nick,
We do exactly that for some device producers already.

Robin Alden, Comodo. (Sent from my phone)

---- Nick Lamb via dev-security-policy wrote ----

>On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote:

>> The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again.
>

[Samuel Pinder]

There's more than just a clue in the name drmlocal.cisco.com , if one
looks up this address in the DNS it returns the loopback IP 127.0.0.1
. http://dnstools.ws/tools/lookup.php?host=drmlocal.cisco.com&type=A
This can only mean that this address is fully intended to be referred
to only by one's own machine that the NowTV software is running on.
There's probably an architectural reason why a publicly trusted
certificate is used. But the way it's been implemented clearly does
mean that the private key ends up being shipped, which, even if it
didn't break the Baseline Requirements, it goes against the very
principle of PKI cryptography. Therefore the newly re-issued
certificate *will* end up with it's private key compromised *again*,
no matter how well it may be obfuscated in the application, it is
still against the very principle.
Is a publicly-trusted certificate even needed here? Another this could
have been done is what anti-virus programs often resort to doing:
installing a self-signed root into the OS (and other browser stores)
as part of the client installation process and generating certificates
on-the-fly directly off of it. But then that would mean that if anyone
compromised the key for that, it could potentially put many users whom
use NowTV at risk unless that self-signed root was constrained in some
way. *However* this would mean at least, it no longer breaks the
Baseline Requirements as it would no longer be within it's scope. I'm
no expert here at all, and I do dislike the idea of this kind of
behaviour completely (and I could be completely wrong about why
drmlocal.cisco.com is used). NowTV might want to consider their
options here, but shipping a private key and trusted certificate with
an application, really isn't the way. In summary: I believe a
compromise will happen again as it is clear drmlocal.cisco.com is
deliberately intended to refer to one's own machine.
Sam

On Mon, Jun 19, 2017 at 1:50 PM, Nick Lamb via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Monday, 19 June 2017 09:32:20 UTC+1, troy.f...@cisco.com wrote:

>> The compromised certificate for drmlocal.cisco.com serial number 6170CE2EC8B7D88B4E2EB732E738FE3A67CF672 has been revoked. A new certificate is being reissued to drmlocal.cisco.com and we will work with the developers of the YES video player to ensure that the issue does not happen again.
>

[Matthew Hardeman]

I wonder if the device intercepts DNS queries within the LAN for that address and substitutes in the IP of the appliance instead of 127.0.0.1. Is it often deployed as the customer premise NAT/router in addition to serving video purposes?

I'm thinking they probably wanted some other devices or browsers on the local LAN to access, via https, the appliance on the LAN. And they wanted it to have a trusted cert for that purpose. They just didn't want to have to deal with unique name and cert per device.

Which, as has been pointed out repeatedly is a violation of the CA <-> subscriber agreement, because the baselines require that the CA <-> subscriber agreement forbid this.

It looks to me like someone wanted to avoid the need to have a unique certificate issued for each device.

The easy way forward would be for them to create a new domain, run their own dynamic DNS service for each device on that domain (get said domain on the PSL) and develop software for it to fetch and update valid certificates for these IoT devices. Presumably they could roll their own DNS infrastructure and even use something like Let's Encrypt, though I'm not certain whether Let's Encrypt is on the record as to what they'd think of such a use case.

In as far as Cisco has requested a new drmlocal.cisco.com certificate.... Why? They can't use it the new certificate in the same way again (or it would just get revoked again) and the real drmlocal.cisco.com record points to 127.0.0.1, so it's not like they have a real central drmlocal.cisco.com site that needs a certificate. I think the "local" part of the name is probably most telling. They likely came up with that name because ciscodrm.local would have been impossible to get a valid cert for.


Matt Hardeman

[Matt Palmer]

On Sun, Jun 18, 2017 at 08:17:07AM -0700, troy.fridley--- via dev-security-policy wrote:
> If you should find such an issue again in a Cisco owned domain, please
> report it to ps...@cisco.com and we will ensure that prompt and proper
> actions are taken.

I don't know, this way seems to have worked Just Fine.

- Matt

[Tom Ritter]

On 19 June 2017 at 08:28, Samuel Pinder via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> Therefore the newly re-issued
> certificate *will* end up with it's private key compromised *again*,
> no matter how well it may be obfuscated in the application, it is
> still against the very principle.

I'm pretty confused by this as well.

First off, while people have proposed multiple solutions to this
problem, they are not trivially implementable, nor are they
widespread. I think if you shook the tree with some automation, you'd
find on the order of 50 or more publicly trustable private keys
embedded in firmware pretty quickly.

So at what point does the CA become culpable to misissuance in a case
like this? Is it okay that we let them turn a blind eye to issuing or
reissuing certificates where they have a strong reason to believe the
private key will be published in firmware?

Clearly we wouldn't require them to vet every use of every certificate
they issue, but if they revoke a certificate for being used in this
fashion, it seems reasonable for them to ask the customer to at least
give them an explanation of how they've changed things such that a
newly issue certificate for the same domain will not be used in the
exact same way.

Is it reasonable for us to ask a CA to do this (that is, to ask their
customer)? Is it reasonable to require it?

-tom

[Matthew Hardeman]

On Monday, June 19, 2017 at 11:40:22 PM UTC-5, Tom Ritter wrote:
> So at what point does the CA become culpable to misissuance in a case
> like this? Is it okay that we let them turn a blind eye to issuing or
> reissuing certificates where they have a strong reason to believe the
> private key will be published in firmware?

Pretty much any DV validated certificate could be used the way Cisco's software used this one... Unless we want to create new burdens for every DV validating CA out there, I don't think it's practical to pre-suppose that a similar certificate will get similar misuse.

The right balance is probably revoking when misuse is shown.

[Nick Lamb]

On Tuesday, 20 June 2017 05:50:06 UTC+1, Matthew Hardeman wrote:
> The right balance is probably revoking when misuse is shown.

Plus education. Robin has stated that there _are_ suitable CA products for this use case in existence today, but if I didn't know it stands to reason that at least some of the engineers at Cisco didn't know either.

Knowing what the Right Thing is makes it easier to push back when somebody proposes (as they clearly did here) the Wrong Thing. If, at the end of the day, Cisco management signs off on the additional risk from doing the Wrong Thing because it's cheaper, or faster, or whatever, that's on them. But if nobody in their engineering teams is even aware of the alternative it becomes a certainty.

[mfi...@fortmesa.com]

Does no-one else see the lack of responsible disclosure in this thread distressing?

Yes, the cert was revoked, and for all you know during the race that was this public disclosure there could have been compromise. There are APT actors watching this thread right now looking for opportunities.

This could have been reported to the vendor, or if you are not happy with Cisco's security response, to the CA first. 24 hours is not too long to keep this under hat.

Instead -- this was posted to a public forum giving many thousands of people the opportunity to chain a vector attack against Cisco CCO IDs (which in some cases might lead to customer network compromise).

If our community does not work to encourage more responsible disclosures the governments will do it for us, and it won't be nice.

"Remember the Wassenaar"

Matt

Matthew Fisch, CISSP
mfi...@fortmesa.com

[Lee]

On 6/20/17, mfisch--- via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:

> Does no-one else see the lack of responsible disclosure in this thread
> distressing?

Nope. The first requirement for "responsible disclosure" is knowing
you're disclosing something. Take a look at the original msg:
-- I wasn't entirely sure whether this is considered a key compromise. I asked
-- Hanno Böck on Twitter (https://twitter.com/koenrh/status/873869275529957376
-- <https://twitter.com/koenrh/status/873869275529957376>), and he advised me to
-- post the matter to this mailing list.
<.. snip ..>
-- If this is indeed considered a key compromise, where do I go from
here, and what
-- are the recommended steps to take?

If you want to argue that I should have replied with something about
sending the info to ps...@cisco.com instead of just forwarding the 1st
two messages in the thread to them.. yeah, maybe I should have done it
that way.

> Instead -- this was posted to a public forum giving many thousands of people
> the opportunity to chain a vector attack against Cisco CCO IDs (which in
> some cases might lead to customer network compromise).

I'm curious - how does one use a cert for drmlocal.cisco.com to chain
a vector attack against Cisco CCO IDs?

Regards,
Lee

[troy.f...@cisco.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick,

I misspoke in my reply. The certificate has been revoked and it has not been re-issued. We have filed a post-stopping defect (Cisco Bug ID CSCve90409) against the product to ensure that the issue is not re-introduced.

The certificate in question was never used to transfer customer or service provider information over a public network. The engineering team utilized the cert to protect an IPC channel between a users browser and a background process running on the host.

Rest assured that if the Cisco PSIRT or Cisco PKI teams had known that the certificate would be exposed in this manner we would have prevented it. We have folks working with the responsible engineers to insure they understand the implications of their previous design.

Regards,
- -Troy

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAllJYz4ACgkQ1ANYX3sx7SAkVgCeLwuYBx2LceI/SFU+kcSUFtHB
JysAoPm5UtGh+5gzzi/4Gzfdgj2UcGcL
=YznP
-----END PGP SIGNATURE-----

[Jonathan Rudenberg]

> On Jun 20, 2017, at 10:36, mfisch--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Monday, June 19, 2017 at 7:37:23 PM UTC-4, Matt Palmer wrote:

> Does no-one else see the lack of responsible disclosure in this thread distressing?
>

> Yes, the cert was revoked, and for all you know during the race that was this public disclosure there could have been compromise. There are APT actors watching this thread right now looking for opportunities.

The disclosure looks responsible to me.

The domain resolves to 127.0.0.1, which means that the private key can only be effectively leveraged by a privileged attacker that can forge DNS responses. An attacker that can do this can almost certainly also block online OCSP/CRL checks, preventing the revocation from being seen by clients. In general, revocation will not have any meaningful impact against misuse unless the certificate is included in OneCRL/CRLSets (for Firefox/Chrome).

Jonathan

[mfi...@fortmesa.com]

Koen,
Cheers on the find and thanks for your contribution.

Jonathan,

Is your argument that TLS checking on session key disclosure is not necessary because man in the middle is game over?

You're right there are only very limited ways this sort of thing can be used (and maybe it can't be used at all). But it would be difficult to argue effectively that:

a) It can't be used under specific circumstances to weaken security and possibly combine with other attacks.

b) That someone who recognized this for what it was did not reasonably believe it _shouldn't_ be public knowledge.

c) I acknowledge your point about the effectiveness of revocation.

My issue is not in fact with the disclosure at all, but the fact that noone else on this thread pointed out that it is not the ideal disclosure methodology (at least in order of events). It's now been said.

Both Cisco and the CA maintain infosec incident handling teams that are paid specifically to handle these situations. Yes its true corporate infosec fails a lot too, but a head start is ethical.

The culture of our industry needs to think hard about the power it wields so it is not taken from us and wrapped up in ineffective and burdensome state oversight.

[mfi...@fortmesa.com]

ps, it was noted previously that if other cisco properties are a bit free wheeling with their cookie security it would be possible to leak.

[reising...@gmail.com]

I think his complaint was in the fact that you laid out every single detail while simultaneously asking what you should do. I think you could have done without the vast detail and kept it very generic until you figured out who to contact, then let the vendors fix it.

Moral of the story, if you have to ask if it's a disclosure, you are better safe than sorry and keeping the info under close wraps until you confirm it.

[random...@gmail.com]

> Moral of the story, if you have to ask if it's a disclosure, you are better safe than sorry and keeping the info under close wraps until you confirm it.

I think it's better it was disclosed than had it not been disclosed at all.

While I agree to an extent that there could have been more optimal ways for the disclosure in this particular case, I think we should not try to disencourage disclosure. If someone spots something and and asks a very generic question, I'm like 99% sure folks will tell him to be more detailed else they can't have an opinion. (Which basically is what he did, he asked one person a generic question and that person told him to ask it here, I guess it's reasonable that he was more detailed when doing so.) Now, if we tell people who spotted something AND did some additional research on it, which is IMHO commendable, that they better shouldn't have disclosed anything before checking with so-and-so and waited such-and-such an amount of time (which they might be aware of, or not), the next such person will likely just think, oh, sod it, maybe it's not so important anyway. (It's not like this was a complicated 0-day where the itsec engineer who found it would already have known exactly who to contact in advance.) Blaming the person who disclosed it is not helpful I think.

[reising...@gmail.com]

That's a good point.

[simon....@surevine.com]

I'm aware of another instance of this pattern in widely deployed software, discovered through security testing 3rd party applications (Thanks to Hanno discussing related issue on twitter).

The pattern "Using a certificate with DNS resolving to 127.0.0.1 to allow a browser page to communicate with a local web server".

Although it was done in an insecure fashion (not yet fully resolved, so disclosure would be unhelpful), I don't see a good alternative model for this vendor's use case.

I also looked when I first found the encrypted P12 file (and password hardcoded into the application), and found nothing useful online discussing this pattern, or alternatives.

I only found that you could no longer register certificates for 127.0.0.1 (the world only needs one such).

The mass issuance of certificates described above doesn't seem any better, since there still needs to be a trust relationship with an unprotected appliance or application. Or is there some aspect of the certificates issuance that bind them to a particular implementation (I thought all such binding were basically broken in most TLS implementations).

What is the recommended practice here?

[Jakob Bohm]

In general: Do not conflate an outside address (such as the domain of
the vendors online service) with anything local (like 127.0.0.1 or the
actual IP of some local IoT device). That is a gross violation of one
of the most fundamental security barriers (mine vs. yours).

The fundamental question is: What do they want to access locally, and
why should a remote web domain get any access to it?

From there logic solutions can be built that don't compromise the
browser security model and don't involve sharing secret keys with
strangers.

One common solution discussed by others in this thread is to serve
everything within the trust barrier from a localhost http server and
relying on browsers trusting explicit localhost http connections more
than remote http connections.

Another similar solution is to use a self-signed random per installation
localhost certificate generated on first run, then server everything
from a local https server.

For some cases, even simpler solutions such as using file:// URLs or
file upload form fields is appropriate.

Whatever is done, within the browser any data sharing between local and
remote needs to be treated as cross-site data sharing with all
associated security restrictions and concerns.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded