I was hoping for a good answer, rather than "this is hard and it will just get worse." We have an old app that my team is modernizing with this exact situation. Uses websockets now, but that's an historical thing and all the web apps were non-secure so it worked okay. Now everyone wants SSL turned on, and this puts the websocket method in jeopardy. Somebody before me decided we should switch all the inter-app communi…
Certificates for localhost
101–110 of 157 posts
Re: Certificates for localhost
#102I'm having a hard time understanding the use case here. Using a domain name for loopback IP and generating a cert will work fine for internal use. They're saying it's a security hole because you may need to distribute that private key to users. What exactly is that scenario? Shipping an app with a built-in web server? Not sure I've ever seen that done. And could you not solve it with certificate pinning?
HTTP/2 requires https in most (all?) browsers these days. If you’re measuring load times locally this can be a bit of a problem.
Re: Certificates for localhost
#103I’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…
Re: Certificates for localhost
#104Earlier quoted context omitted.
If you've got rogue software running on your machine, all bets are off.
Not necessarily. It could be running in a sandbox, or as unprivileged user, and accessing your app's API over localhost would allow for privilege escalation.
Re: Certificates for localhost
#105Earlier quoted context omitted.
So how do you compare to arq backup or borg backup? Other than your choice of using a web browser tab for UI?
Great question. More details coming out soon on our mailing list and Twitter---and there's so many factors to consider---but in short, Relica: - is designed for consumers who are not technically skilled - works on Linux and BSD (I don't think Arq does) - offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times - allows you to backup to lo…
How does that work?
Re: Certificates for localhost
#106Earlier quoted context omitted.
Great question. More details coming out soon on our mailing list and Twitter---and there's so many factors to consider---but in short, Relica: - is designed for consumers who are not technically skilled - works on Linux and BSD (I don't think Arq does) - offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times - allows you to backup to lo…
>offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times How does that work?
Re: Certificates for localhost
#107I’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 want to say a few things regarding "insecurtity" of localhost. I find it completely insane and a huge overlook that the downloaded js can access your localhost PRIVATE services. It should be able to access external public services sans cross-origin etc policies. But the browser should not allow access to your localhost services by default, never. They are assumed to be private services. Everyone uses them as such, taking advantage of the (lack of) security implications.
If you download a program, and install it, you are open to the same problems. But, there is a huge difference between installing something and clicking a random link on the internet. Local services should be treated the same as files in your computer. Block everything unless explicitely allowed by the user.
Re: Certificates for localhost
#108I’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…
> But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider! Wouldn't that be solved by binding your listener to 127.0.0.1 (as opposed to 0.0.0.0 or your actual IP)? Sending a request to 127.0.0.1 shouldn't be able to send anything to…
The long answer is if the sender configured their routing to point localhost to your host then your service would still connect and route traffic back to the foreign address. But this type of attack can easily be firewalled against.
There is also the potential problem of reverse proxies. However that requires local machine access anyway.
Re: Certificates for localhost
#109Also, I wouldn't use the host name "localhost", but something like "mydomain.test", and update /etc/hosts accordingly.
Re: Certificates for localhost
#110Earlier quoted context omitted.
>offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times How does that work?
We replicate your upload after it leaves your computer (at the packet level - we can't decrypt your data, we don't even have the key for it). There were quite a few technical hurdles we had to overcome to make this work, but I gotta admit, it's really cool to see it in action. :)
This does raise the question of how fast the upload will be - how's your network?
Switching from Dropbox to OneDrive doubled my upload speed simply because there's better peering from my ISP to Akamai vs whatever Dropbox was using at the time.