On 25/07/2017 14:58, simon.wat...@surevine.com wrote:
On Tuesday, 20 June 2017 10:43:37 UTC+1, Nick Lamb wrote:
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.
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?
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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
