4 ms·

They show big red error and prompt to continue is hidden under spoiler. Also XHR requests just cut off, it's painful when developing and testing.

zozbot234 7y ago
Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.
- namibj 7y ago
  The XHR api could allow specifying a trust root and/or cert-pinning though.
  - edoceo 7y ago
    It already does, put your self-CA in the browser trust store.
  - necovek 7y ago
    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).
    - namibj 7y 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.
      - necovek 7y 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)?
        namibj 7y 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.
        necovek 7y ago
        Ah, enabling TLS for access using only an IP address is a great point, thanks.

zozbot234 7y ago

Well, a XHR cannot programmatically decide whether a self-signed cert should be trusted. Perhaps browsers should pop up a warning bar in such cases, explaining that some site functionality is being blocked for security reasons. Clicking it would take the user to the big scary warning page, where they would be allowed to indicate that they trust the self-signed cert (permanently or not) and reload the original page.

namibj 7y ago
The XHR api could allow specifying a trust root and/or cert-pinning though.
- edoceo 7y ago
  It already does, put your self-CA in the browser trust store.
- necovek 7y ago
  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).
  - namibj 7y 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.
    - necovek 7y 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)?
      - namibj 7y 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.
        necovek 7y ago
        Ah, enabling TLS for access using only an IP address is a great point, thanks.