Live data from Hacker News

Certificates for localhost

letsencrypt.org

151–157 of 157 posts

Re: Certificates for localhost

#152
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…

I've done exactly that https://github.com/fairlayer/fair

Single auth_code shared between web session and local app is all you need.

Re: Certificates for localhost

#154
post #133
post #86

Earlier quoted context omitted.

They get one private key per user, and send it to the client's device.

Which "compromises" the key, according to current Certificate Authorities policies. Once again the problem boils down to CAs being the sole "anchors of trust" in the current certificate system.

Then they could have their server tunnel ACME challenges to the device, so the private key never leaves the device, but can still be signed.

Re: Certificates for localhost

#155
post #86
post #79

Earlier quoted context omitted.

How would you run a local HTTPS server without the private key?

They get one private key per user, and send it to the client's device.

The private key is generated on the client side, and signed by the certificate. Plex has an intermediate which they control to issue these. It would not pass normal validation processes.

Re: Certificates for localhost

#156

Is it time to start using a better acronym than either XHR or AJAX? Is there a modern accurate alternative for an HTTP request made by a browser that is not a request for a page reload?

I believe the term you're looking for is a fetch (from the fetch API)? Though I don't know if that is also commonly used to refer to a standard page reload.

Re: Certificates for localhost

#157
post #36
post #33

Earlier quoted context omitted.

> I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. We're doing exactly this prime-time with Relica: https://relicabackup.com (sorry, not much on the landing page yet, but we have emailed out some info about the UI already [1]). That technique will allow us to distribute backup software that works the same for macOS, Linux, BSD, and Windows, right away; screenshot: [2]. An…

Thank you, yes, I think architecturally there are great advantages to splitting up an app like a client/server even when designed primarily to be accessed over localhost. Obviously the “server” API is extremely sensitive and I think you have to assume it is effectively exposed to the outside world, even with a 127.0.0.1 binding and a firewall. I guess if you make localhost users literally login and establish a sessio…

A login is not enough because of cross site request forgery. A site on the internet can include css, scripts or images from your service and generate get and post requests to it with the users credentials.
Post reply on HN