search

mooltipass / moolticute

Mooltipass crossplatform daemon/tools
GNU General Public License v3.0
144 stars 67 forks source link

Bind sockets to localhost #398

Open dirkx opened 5 years ago

dirkx commented 5 years ago

On OSX - moolticute v0.30.4 (current as of today) trips just about every alert in enterprise environments by listening on *:MOOLTICUTE_DAEMON_PORT (30035) by default. I.e. on a public address.

Should probably bind to local host by default. And only allow opening 30035 to the world as some advanced setting.

limpkin commented 5 years ago

that's strange... I thought we had made this by default. @deXol : could you look into this on all 3 platforms? from what I recall we should listen to 127.0.0.1...

deXol commented 5 years ago

@limpkin: There was an issue (https://github.com/mooltipass/moolticute/issues/331) with listening localhost on Mac: https://github.com/mooltipass/moolticute/pull/338 On Windows and Linux localhost is the default.

limpkin commented 5 years ago

oh right... that was a very annoying bug.
@dirkx : we could make it an option with a warning that selecting it would cause an extremely slow start time if tha's ok with you.

dirkx commented 5 years ago

On 2 Jan 2019, at 21:58, Mathieu notifications@github.com wrote:

oh right... that was a very annoying bug. @dirkx https://github.com/dirkx : we could make it an option with a warning that selecting it would cause an extremely slow start time if tha's ok with you.

Better to fix the code to make sure that it binds correctly - it is probably some carelessness with resolving.

Dw

limpkin commented 5 years ago

I wonder what was wrong with LocalHostIPv6... but I don't think there's much we can do on our side given the fix was a single line: https://github.com/mooltipass/moolticute/pull/338/files#diff-96cfc3ad5d7bdc97647a71d636d8700fL156

deXol commented 5 years ago

@limpkin IPv6 was the first attempt to fix this issue https://github.com/mooltipass/moolticute/pull/334, but caused more problem on every platform.

limpkin commented 5 years ago

right, but in both cases we had a very slow daemon start :/

dirkx commented 5 years ago

Hmm - did a quick build on OSX 10.12.6 with the latest Qt Creator; and when I start the appdaemon - I get a connection instantaneously. So I strongly suspect this is not an issue daemon side.

limpkin commented 5 years ago

@deXol : I seem to remember it was a release-only issue. I'm fairly sure that we'd tackled it earlier if we had noticed it on qt creator :)

dirkx commented 5 years ago

Ok - after diving into this; the App side has ‘hardcoded’ “ws://localhost'. While the server had QHostAddress::LocalHostIPv6 and then QHostAddress::LocalHost (IP v4). So I guess this depended on hosts or whatever the primary resolver path yielded in what order. And then the app side timing out.

If I change both to either QHostAddress::LocalHostIPv6 or QHostAddress::LocalHostIPv4 and corresponding ws://XXX where XXX is the actual [::1] or 127.0.0.1 sanity returns.

If v6 was known to work on all plaforms but the mac - then I suggest reverting the change to the Daemon; (and going to v6 again). And changing the client side to "ws://[::1]” (line 22, WSClient.cpp) or constructing a proper URL from QHostAddress::LocalHostIPv6 or QHostAddress::LocalHostIPv4 which takes whatever the latter says.

Dw

limpkin commented 5 years ago

@deXol if that's ok with you :)

limpkin commented 4 years ago

@deXol maybe in the coming weeks we should dig into this again, especially the ongoing PR. I'd still vote against ipv6 given our past issues but perhaps the slow connection issue has been solved on macOS side? :)

rsrdesarrollo commented 2 months ago

Hi, is this going to be implemented? This in conjunction with #1241 for me is a clear security issue.

Regards

limpkin commented 2 months ago

I think we can implement #1241 fairly quickly :)