Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Certificates for localhost

letsencrypt.org

Post reply on HN
Print view View original

141–150 of 157 posts

Re: Certificates for localhost

#141

Post by mdtusz »

rogerbinns wrote: post #81
pstuart wrote: post #18

Earlier quoted context omitted.

Couldn't you use it to coordinate NAT punchthrough?

The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular…

I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.

Re: Certificates for localhost

#142

Post by mdtusz »

cedricziel wrote: post #127
chillydawg wrote: post #123

Earlier quoted context omitted.

Are you using a fake domain or a real one? If fake, I'd be interested in how that works.

Real domain, just no A record. For our projects, we create domains like {project}.{workstation}.company.net

Any chance there's a write-up or docs on this somewhere?

Re: Certificates for localhost

#144

Post by randomfool »

chillydawg wrote: post #124
randomfool wrote: post #49

Earlier quoted context omitted.

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 tried this and Chrome complains about mixed mode and forces you to allow this behaviour and then to reload the page before you can get it working. If that's acceptable, then sure, but for actual use it's not really any good.

Did you connect to ws://localhost:/?

As mentioned in the bug above, this approach is currently recommended by Chrome and in use by a number of large applications/sites.

It's completely transparent and is being used in production today.

Re: Certificates for localhost

#145

Post by rogerbinns »

mdtusz wrote: post #141
rogerbinns wrote: post #81

Earlier quoted context omitted.

The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular…

I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.

We also have a display and also do pairing. You have to press a physical button the device which results in a 4 digit code on the display that has to be entered in the browser or app (somewhat analogous to bluetooth pairing). At the end of the day this results in a cookie being set. But the traffic is still over http.

Re: Certificates for localhost

#146

Post by sligor »

eximius wrote: post #134
inopinatus wrote: post #77

Earlier quoted context omitted.

There is an unofficial unix: URI scheme. Browsers don't support it but system clients sometimes do, for example nginx when configuring upstream groups as a reverse proxy[1]. [1] http://nginx.org/en/docs/http/ngx_http_upstream_module.html

But that doesn't specify protocal then, does it? I.e., http://unix:/path would be very not backwards compatible

a '+' is a valid character in an URI scheme

then http+unix:///path would make more sense

Re: Certificates for localhost

#147

Post by rogerbinns »

andrewmd5 wrote: post #91
rogerbinns wrote: post #83

Earlier quoted context omitted.

> 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.)

WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone...

Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar.

As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still stuck with http.

Re: Certificates for localhost

#148

Post by logicalshift »

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…

I've been building an animation tool that provides a UI over http (https://github.com/logicalshift/flowbetween) so it has a lot of these problems.

For running as a local app, what I really want is to be able to run the server as a UNIX-domain socket. (Well, I can do that fairly easily but what I really want is for browsers to be able to connect to one of these).

For a single-user app the main issue is that it could be running on a multi-user system so there's the possibility of contention for ports and so on, as well as the need to verify that the right person is connecting - while it's possible to just bind the server to the loopback address anybody on the same system can access it there so it's not necessarily secure enough. For localhost verification, accessing/setting some information from a file URL might work.

With the loopback address, encryption doesn't seem to matter too much: anybody capable of intercepting traffic between a piece of software and the browser will also be in a position to just directly read what you're typing. Possibly by looking over your shoulder.

However, one of the reasons I want a HTTP UI is to make it possible to use something like an iPad as an input device and there are definitely issues there when the service is something that's randomly stood up and torn down and usually running on a local network rather than the internet: in particular TLS really expects a centralized service so it seems anything other than a self-signed certificate isn't going to work and that comes with a bunch of scary messages for the user.

The other issues of authentication all seem to be much the same as for any other web app, though it seems to me that it's possible to streamline it a bit as it'll be quite common for a user already authenticated on one device only to need to prove that they're the same user on another.

Re: Certificates for localhost

#149

Post by rootusrootus »

recursive wrote: post #101
rootusrootus wrote: post #20

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…

What's wrong with wss://?

As a practical matter you cannot implement a localhost secure websocket. Essentially all of the methods for communicating between a web app and a native app are some kind of ugly hack and none are supported well enough that you can feel confident they'll stick around for any length of time in all the major browsers.

Re: Certificates for localhost

#150

Post by andrewmd5 »

rogerbinns wrote: post #147
andrewmd5 wrote: post #91

Earlier quoted context omitted.

WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone...

Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar. As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still…

More than happy to offer my thoughts if you want to reach out: andrew@rainway.io
Post reply on HN