Certificates for localhost

Post by andrewmd5 » Thu, Jun 21, 2018, 1:16 AM UTC

rogerbinns wrote: post #83

matthewmacleod wrote: post #21

Earlier quoted context omitted.

We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app. There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!

> We ended up using the WebRTC data channel ... That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something to get the page that does the webrtc as far as I can tell.)

Post by j4cob » Thu, Jun 21, 2018, 1:27 AM UTC

yebyen wrote: post #66

justinclift wrote: post #63

Earlier quoted context omitted.

Ahhh yeah. But that's how most OS's set things up by default, in order to meet the required specs. (bugs and implementations hiccups aside) Once the OS is up and running, manipulation of the routing tables at least _used_ to make this possible on Linux and Solaris. Not sure about FreeBSD, but that's just from memory fuzziness on my part. :)

> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine This is definitely false, without any routing tables. Any unprivileged user can start an SSH tunnel listening on any localhost port above 1024, sending traffic out to wherever.

Post by kawsper » Thu, Jun 21, 2018, 1:48 AM UTC

j4cob wrote: post #92

tialaramex wrote: post #40

Earlier quoted context omitted.

To be fair, the complicated openssl invocation is largely because OpenSSL is crap. Let's break it down: "openssl req x509" This is a dodge because we don't actually want to write a CSR and then sign the cert, we're going to skip all that so we're using a sub-feature of a different sub-feature. Fine. "-out localhost.crt -keyout localhost.key" There surely must be nicer ways to set this, but it's not so objectionable..…

FYI, OpenSSL has a new flag that makes the "-extensions" part somewhat simpler, but most people won't have it in their copy yet: https://github.com/openssl/openssl/pull/4986

Post by adamfisk » Thu, Jun 21, 2018, 2:53 AM UTC

tootie wrote: post #56

zaroth wrote: post #12

I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. It seems like a great way to get the cross-platform ease of use of developing the UI without having to do everything in browser, so you can optimize the heavy lifting and don’t end up with an Electron app pulling 8Gb of RAM and 100% Of 16 cores. But I could never quite satisfy the nagging feeling that the localhost server c…

If browser and server are on the same machine, you remove a whole host of the barriers to identification. You could use any sort of local knowledge like system files or your NIC as identification. NB: I haven't thought this through, but I'm sure there's something to it :)

Post by Ajedi32 » Thu, Jun 21, 2018, 3:14 AM UTC

randomfool wrote: post #49

BillinghamJ wrote: post #13

The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.

As discussed in crbug.com/378566, Chrome currently allows connecting to unsafe WebSockets on localhost. So just use a WebSocket to communicate from your HTTPS hosted page to your local server. And yes, you definitely should whitelist access based on the origin header.