undefined | Better HN

0 pointsnecovek6y ago0 comments

How do you imagine this to work? XHR caller and XHR endpoint are both coming from untrusted sources at that point — if you allow either side to define a trust root, you are fully opening up to MITM attacks.

For development purposes, I imagine the approach akin to cross-origin support in browsers for loopback networks might work (i.e. don't enforce checks on them).

0 comments

namibj6y ago

Well, the caller is already allowed to run code. Allowing it to use TLS with cert-pinning doesn't make that any less secure.

necovekOP6y ago

I apologise, I still don't understand your claims.

Without previous proof that the calling code was not eg. modified in-flight (eg. over HTTP or over HTTPS without a valid certificate), allowing it to use TLS and to either modify the trust root or pin a new certificate would severely reduce the security of the communication, and would be completely against what HTTPS is designed to solve in the first place (mainly MITM snooping and attacks).

And if there is a "previous proof" of genuinity (eg. by serving through properly encrypted HTTPS), what the benefit is to allowing those clients to pin certs? I.e. they'll still need the existing "proper" HTTPS for all the other first time visitors (and return visitors using new browsers/OSes/devices)?

namibj6y ago

Don't worry.

I don't mean we should allow the fetch API to mess with the browsers trust configuration. It should only allow a temporary override of trust rules, similar to DANE TLSA-RRs, but provided by JavaScript instead of DNSSEC-verified DNS lookups.

Imagine e.g. combining this with an SPA bootloader contained in a data-url (like a bookmarklet), which the user scans via a QR-code or receives via text-based messaging.

CORS would still be in-play, and maybe the insecure nature of the caller is communicated to the API.

The benefit of this pinning would be e.g. allowing direct communication with IoT hardware, or even just prevention passive content analysis.

You could talk to IPs directly and still use TLS without weird wildcards like *.deviceid.servicedevices.com where the dns just has these zone entries:

  deviceid.servicedevices.com  DNAME  has-a.name

, but that's ugly and leaks the device's IP through a DNS lookup.

1 more reply

j / k navigate · click thread line to collapse

0 comments

namibj6y ago

Well, the caller is already allowed to run code. Allowing it to use TLS with cert-pinning doesn't make that any less secure.

necovekOP6y ago

I apologise, I still don't understand your claims.

namibj6y ago

Don't worry.

Imagine e.g. combining this with an SPA bootloader contained in a data-url (like a bookmarklet), which the user scans via a QR-code or receives via text-based messaging.

CORS would still be in-play, and maybe the insecure nature of the caller is communicated to the API.

The benefit of this pinning would be e.g. allowing direct communication with IoT hardware, or even just prevention passive content analysis.

You could talk to IPs directly and still use TLS without weird wildcards like *.deviceid.servicedevices.com where the dns just has these zone entries:

  deviceid.servicedevices.com  DNAME  has-a.name

, but that's ugly and leaks the device's IP through a DNS lookup.

1 more reply

j / k navigate · click thread line to collapse