wow.checkout this cool forum http://mawazo.tk
Certificates for localhost
61–70 of 157 posts
Re: Certificates for localhost
#62I'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?
> What exactly is that scenario? Shipping an app with a built-in web server?
I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example).
You cannot access the device directly because there's no (standard) Browser NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it would be fine if only you could interface with that pesky gadget.
In the past, people used NPAPI plugins for that, but those days are gone (browser plugins are much more sandboxed now, so they just don't have those capabilities anymore).
Solution? You ship a companion small native app. That native app is supposed to interface your web application with the usb device. How do you achieve that? Simple, the native app exposes an http/websocket-based API at "localhost:someport" on the one side, and talks to the device using native drivers on the other.
If you don't use https in your web-app, that is it. Your web-app can now communicate with your native app (by making requests to "localhost:someport"), and through your native app communicate with the device. Problem solved... right?
Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins.
> And could you not solve it with certificate pinning?
Pinning a certificate is not secure because using the same certificate in all installations is not secure: notice that your native app must have the certificate and the corresponding private key (because it must serve requests under that "localhost:port"). At this point, any of your users could just grab that cert/key pair (from their local installation) and use it to man-in-the-middle your other clients (the cert is valid for them too!).
The problem is exactly the same if you obtain a publicly-recognized certificate and distributed it with your native app.
The secure solution is, as the article says, to generate a certificate _specific for this user_ during the installation of your native app, and adding that certificate to the user's certificate store. This way the certificate is only valid for that user. Your native app can use this user-specific certificate to serve https/wss requests, and the user's browser will connect to that without warnings because the certificate is trusted. However, if user A extracts the certificate and key from her installation and tries to use them to main-in-the-middle another user B, it won't work because the certificate B trusts is his own installation-time-generated-one, not A's certificate which is different.
Re: Certificates for localhost
#63> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine. ... Isn't that a widely held, but incorrect, assumption? eg People with reasonable knowledge of IPv4 on *nix can still route 127.0.0.1 traffic out through an external interface? From memory, people used to do that when attempting to bypass various firewall/filter rules on other hosts for a locally attached network. Maybe things have tightened up/cha…
No, 127.0.0.1 should never appear on any network, and no network device should ever route it. The earliest documentation I was able to find is in RFC 1122 [1] from 1989, but according to RFC 6890 [2], the principle dates back to 1981. [1] https://tools.ietf.org/html/rfc1122#section-3.2.1.3 [2] https://tools.ietf.org/html/rfc6890 (table 4)
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. :)
Re: Certificates for localhost
#64Easiest way is to get a certificate for a subdomain of a domain you own, e.g. dev.example.com, and then point dev.example.com to 127.0.0.1 in your hosts file.
This sounds like a bad idea. You don't want private keys to a production subdomain being handed around teams. For instance, let's say you have dev.mybank.com. Somebody could trivially poison a DNS cache for a local system to redirect to their server, have a valid SSL key on the company domain, and implement a very real-looking phishing website for the company. Another problem - controlling a subdomain could be used t…
A domain you own a production domain.
Our corp has corptech.com and a few similar ones for this purpose. A generic .com costs about nothing, so no point in running anything non-production on your primary domain.
Re: Certificates for localhost
#65The 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.
Isn't this exactly what the blog post is saying not to do?
> By introducing a domain name instead of an IP address, you make it possible for an attacker to Man in the Middle (MitM) the DNS lookup and inject a response that points to a different IP address. The attacker can then pretend to be the local app and send fake responses back to the web app, which may compromise your account on the web app side, depending on how it is designed.
Re: Certificates for localhost
#66Earlier quoted context omitted.
No, 127.0.0.1 should never appear on any network, and no network device should ever route it. The earliest documentation I was able to find is in RFC 1122 [1] from 1989, but according to RFC 6890 [2], the principle dates back to 1981. [1] https://tools.ietf.org/html/rfc1122#section-3.2.1.3 [2] https://tools.ietf.org/html/rfc6890 (table 4)
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.
Re: Certificates for localhost
#67If you're using ASP.NET Core, this is built into the most recent 2.1 release - local dev cert as well as HTTPS redirection middleware and HSTS in development. https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-c... https://docs.microsoft.com/en-us/aspnet/core/security/enforc... As the letsencrypt article points out, you want to start building and testing with HTTPS as early as possible, so this is all wired u…
Came here to write this, very impressed! Saved me so much time. It might help others to point out you need the ASP.NET Core 2.1.300 SDK -- 2.1.200 is not sufficient, and it took me a while to realise this. Perhaps I'm veering off topic, but why no Typescript in the 2.1 reactredux templates?
Re: Certificates for localhost
#68I’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…
It would be neat if you could listen to a unix domain socket and have a simple way to specify that as an endpoint for an http URI.
i.e.,
http://[uds/path/to/uds.socket]
I reuse ipv6's current syntax here just for the example. A lot of bikeshedding would be needed. It would also be ugly to expose those kinds of internals to an end user, so you'd need some additional technology on top of this to look pretty.
Re: Certificates for localhost
#69I'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?
> What exactly is that scenario? Shipping an app with a built-in web server? I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example). You cannot access the device directly because there's no (standard) Browser NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it…
>Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins.
The article also says that the website could make requests to http://127.0.0.1:portnumber/ and browsers will allow that even from HTTPS websites.
Re: Certificates for localhost
#70https://github.com/ctcherry/tlself
I created this proxy to help with this, it dynamically creates certs from a self-signed-trusted local CA. It only targets OSX for now. It's not perfect but it has been working great for me.