3 ms·

Note: I am the author of this article. Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue

by palant 4y ago

Note: I am the author of this article. Yes, that’s what I also assume. I didn’t bother verifying however that mixed content warnings are generally not an issue with localhost in any browser that South Korea cares about (e.g. Internet cough Explorer). Keep in mind that they have some rather adventurous ways to access the local web server, such as JSONP or communicating by posting to a frame.

heleninboodler 4y ago
The localhost issue is very interesting. Of course, there's no chance that someone is impersonating localhost, but there is a chance that someone is eavesdropping on it (although this implies a level of privilege that may make encryption moot). Should browsers just accept self-signed certs for localhost on the assumption that you can't actually impersonate it? Maybe. I used to run internal PKI for a large company and "can I get a cert for localhost" was one of the top 3 arguments I used to find myself in (for the record, the answer was always no).
- palant 4y ago
  Interception of localhost traffic is in fact a non-issue, someone able to do it can do worse. So TLS really shouldn’t be necessary on localhost, that’s it.
  - heleninboodler 4y ago
    Certainly seems likely to be the case, but I'm open to there being a theoretical attack that involves being able to inspect the data flowing through the TCP stack without being able to inspect the process spaces of the two endpoints. E.g. if the TCP stack was able to be put in a debug mode that was logging packets somewhere, you'd prefer those to be encrypted. It's pretty far-fetched in terms of an attack surface, but "this data never exists unencrypted outside these two processes' memory spaces" is objectively stronger in a specific way than plaintext transiting kernel buffers.
- shp0ngle 4y ago
  the browsers are currently just accepting http on localhost and it’s the best solution. The eavesdropping issue is nonsense. The only reason is “we want to support IE7”, I guess. Which I didn’t consider but might be an actual usecase in South Korea
shp0ngle 4y ago
Yeah IE7 doesn’t support SSL-less localhost. I think that will be the main reason.

by palant 4y ago

heleninboodler 4y ago

The localhost issue is very interesting. Of course, there's no chance that someone is impersonating localhost, but there is a chance that someone is eavesdropping on it (although this implies a level of privilege that may make encryption moot). Should browsers just accept self-signed certs for localhost on the assumption that you can't actually impersonate it? Maybe. I used to run internal PKI for a large company and "can I get a cert for localhost" was one of the top 3 arguments I used to find myself in (for the record, the answer was always no).

palant 4y ago
Interception of localhost traffic is in fact a non-issue, someone able to do it can do worse. So TLS really shouldn’t be necessary on localhost, that’s it.
- heleninboodler 4y ago
  Certainly seems likely to be the case, but I'm open to there being a theoretical attack that involves being able to inspect the data flowing through the TCP stack without being able to inspect the process spaces of the two endpoints. E.g. if the TCP stack was able to be put in a debug mode that was logging packets somewhere, you'd prefer those to be encrypted. It's pretty far-fetched in terms of an attack surface, but "this data never exists unencrypted outside these two processes' memory spaces" is objectively stronger in a specific way than plaintext transiting kernel buffers.
shp0ngle 4y ago
the browsers are currently just accepting http on localhost and it’s the best solution. The eavesdropping issue is nonsense. The only reason is “we want to support IE7”, I guess. Which I didn’t consider but might be an actual usecase in South Korea

shp0ngle 4y ago

Yeah IE7 doesn’t support SSL-less localhost. I think that will be the main reason.