121–130 of 157 posts
We have a domain for internal usage only, where we can modify TXT records. Through this, and a little help from acme.sh, and dnsmasq, every workstation can have unlimited, valid certificates for local projects.
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…
We're using LetsEncrypt with local domains. We have a domain for internal usage only, where we can modify TXT records. Through this, and a little help from acme.sh, and dnsmasq, every workstation can have unlimited, valid certificates for local projects.
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.
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…
git-annex, which uses a web server on localhost for the Assistant UI, uses this process: - generate a random token - start the server configured to only accept requests that contain that token - generate an HTML file that redirects to a local address passing that token, with read permissions only for the current user - run the browser with that file as argument In theory, this should prevent external requests, as wel…
Sadly, browsers don't support this... :(
What I don't understand is this bit: > Fortunately, modern browsers consider “ http://127.0.0.1:8000/" to be a “potentially trustworthy” URL . [...] WebSockets don’t get this treatment for either name. It's good they at least added an exception for (verifyable) localhost access - but then why is the exception only given for HTTP? There seems to be a deliberate restriction that websockets are excluded. I find this kin…
While a huge pain the ass, it could be possible for your local app server to create a [bridged] virtual host network that routes locally for your server. It utterly ridiculous to resort to this method though. Does anyone else have an idea of a workaround?
At which point you again need a domain for your virtual IP, a certificate for your domain and a private key for the certificate on the device, which will probably cause your certificate to be reported as a vulnerability and revoked.
We're using LetsEncrypt with local domains. We have a domain for internal usage only, where we can modify TXT records. Through this, and a little help from acme.sh, and dnsmasq, every workstation can have unlimited, valid certificates for local projects.
Are you using a fake domain or a real one? If fake, I'd be interested in how that works.
For our projects, we create domains like {project}.{workstation}.company.net
https://community.letsencrypt.org/t/rfc-a-way-to-use-valid-h...
The idea is to basically offer a free subdomain service (ssl.fun) in conjunction with solving the DNS-01 challenge.
This would automate the existing practice of using a e.g. a public local.domain.com A record pointing to 127.0.0.1
The difference in this approach in regards to previous attempts is that the private key would not be compromised, as the client is issuing it directly.
Happy to receive feedback on this idea :-) As this would run into the 20 certs-per-domain LE limit quickly it needs some blessing before I can offer this service publicly.
There's government CA in Kazakhstan issuing certificates for people and for some government websites. They have software for people, so their website can talk to USB tokens. This website connects to that software via secure websockets at 127.0.0.1. And they bundle private key for 127.0.0.1 issued by that CA inside that application. Is it bad? I guess there's no point to report it to them, because they are CA and deve…
I worked for a place that did something similar, they were running a server on their local machines listening to https://localhost.company.com:someport (resolving to 127.0.0.1) so their javascript frontend hosted at example.com could communicate with their local machine. It was set up so the server would only respond to requests originating from company.com. They distributed the private key for the certificate localh…
Other than that, obvious attack is to extract private key from your application, launch fake server and forge DNS responses for some poor guy (for example if he's using some untrusted WiFi). So his requests would be redirected into that fake server instead of localhost application.
Earlier quoted context omitted.
I read that as being about the actual public DNS, not your own local hosts file?
Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.