Live data from Hacker News

Oxy – A Security Focused Remote Access Tool

oxy-secure.app

51–60 of 88 posts

Re: Oxy – A Security Focused Remote Access Tool

#51

Earlier quoted context omitted.

I'd consider it primarily a source release. Since source is available, of course you should audit it, or at least glance over it before compiling.

> Since source is available, of course you should audit it, or at least glance over it before compiling. Really? I don't think everybody auditing the source of the apps we use is at all realistic, and I don't think glancing at the source is worthwhile. Barring an organized audit, I think confidence in an open source tools like this just comes with popularity, rightly or wrongly.

I think it's reasonable to wait for the community to audit it, and to trust that. Popularity tends to include a certain amount of vetting by people who do have time, resources or knowledge.

Re: Oxy – A Security Focused Remote Access Tool

#52
post #36

Earlier quoted context omitted.

I'd consider it primarily a source release. Since source is available, of course you should audit it, or at least glance over it before compiling.

Since source is available, of course you should audit it, or at least glance over it before compiling. You should realize that this is not feasible for everyone as most people are not developers.. and even in the subset of people who both how to write software and (in this case) know rust, how many are really qualified to audit a software project for malicious code or vulnerabilities? I'm a professional developer and…

That's why I would wait for other people to find that out, if I can't trust or audit it myself. Agreed that a brand new package from an unknown single developer is more risky.

As far as a trap with clever obfuscation, it sounds like any software we use could be vulnerable to that. It could be added as a patch to a seemingly routine update for any of the thousands of packages on your system.

Re: Oxy – A Security Focused Remote Access Tool

#53
post #32
post #5

This is interesting, but shows some of the problems with the word "secure" The app. promises to be more secure than OpenSSH and provides a number of reasons why it thinks it will be. However the site is entirely anonymous, so you have no idea who wrote this tool and what their affiliations or background are. So either you audit the code to get some assurance, or you trust the author(s) without any evidence. Also the…

In general, I think it's very important that early-stage security tools make it clear in their copy that the codebase is young, not well audited, and therefore not yet fit for serious usage. It's super fun to play with cryptography, but giving a false confidence to users who may seriously rely on it is what can lead to major problems.

Talking about false confidence is spreading FUD to me.

Quote from the page:

> Does Oxy have...

> Years of testing and battle hardening? No, it's super green. But hey, if you try it you'll help make it less green!

Maybe not at the top of the page. But at the very least in the relevant section.

I find the page absolutely clear and to the point. Yes - it would be nice with code signing. Being slightly less anonymous might also be better to gain traction. But overall I think it is an impressive start to a rather ambitious goal.

Re: Oxy – A Security Focused Remote Access Tool

#54

Earlier quoted context omitted.

> Since source is available, of course you should audit it, or at least glance over it before compiling. Really? I don't think everybody auditing the source of the apps we use is at all realistic, and I don't think glancing at the source is worthwhile. Barring an organized audit, I think confidence in an open source tools like this just comes with popularity, rightly or wrongly.

I think it's reasonable to wait for the community to audit it, and to trust that. Popularity tends to include a certain amount of vetting by people who do have time, resources or knowledge.

That could happen, but if it did it would very much be the exception rather than the rule :)

Heartbleed and shellshock (and others of course but those two have memorable names) very much laid the general case of "many eyes make all bugs shallow" to rest.

The unfortunately truth is that a tiny percentage of source code gets reviewed by a competent reviewer.

In this case my feeling is that it being crypto+rust the chances are even smaller than usual..

Re: Oxy – A Security Focused Remote Access Tool

#55
post #49

I really enjoy the plain-text website. Bizarre font choices but perhaps the easiest to read site I have seen for a while!

If you meant the font choice for the general text of the website, than that's just whatever default font your web browser has chosen. In essence this website's code has not designated any font choice. So, whenever web browsers are not directed to use a certain font/typeface, they defer to their default font - usually some default system font. This has been the practice of web browsers since the very beginning of the…

The questions are styled to use courier, though.

.question { font-family: Courier; }

Re: Oxy – A Security Focused Remote Access Tool

#56
post #17

>Memory Safe + Fast $ grep 'unsafe {' -R ~/oxy --include=*.rs | wc -l 13 Not bad.

That is not bad after all, I am not bashing oxy, haven't studied it yet, but don't forget that the dependencies could be using more, and there is a fair few of them[0]. https://github.com/oxy-secure/oxy/blob/571ef12199f8b0f3eca55...

btw, a tool for quickly counting unsafe in dependencies: https://github.com/anderejd/cargo-geiger

Re: Oxy – A Security Focused Remote Access Tool

#57
post #44
post #41

Earlier quoted context omitted.

U2F would be amazing. I hacked around with adding second factors to openssh and its possible but not great. There was even a hack to do it with U2F. But to have a ssh like thing that supports U2F out of box would be amazing.

OpenSSH supports, at the very least, PKCS#11 modules out of the box these days, which can be used with hardware security modules.

For a Yubikey, you don't even have to dick around with the PKCS11 mess. Just use gpg-agent, it will use the GPG key on your Yubikey as an SSH key.

Re: Oxy – A Security Focused Remote Access Tool

#58

Earlier quoted context omitted.

I think it's reasonable to wait for the community to audit it, and to trust that. Popularity tends to include a certain amount of vetting by people who do have time, resources or knowledge.

That could happen, but if it did it would very much be the exception rather than the rule :) Heartbleed and shellshock (and others of course but those two have memorable names) very much laid the general case of "many eyes make all bugs shallow" to rest. The unfortunately truth is that a tiny percentage of source code gets reviewed by a competent reviewer. In this case my feeling is that it being crypto+rust the chan…

> crypto+rust

Well, security_protocol+rust. The actual crypto comes from https://github.com/briansmith/ring which just calls hand-written assembly crypto code copied from BoringSSL.

Re: Oxy – A Security Focused Remote Access Tool

#59
Great to see protocol versioning over negotiation. I don’t think replacing OpenSSH is as important as wireguard replacing OpenVPN but it’s up there.

Protocol tasting notes:

- If you’re going to dole out PSKs, why care about signatures? If you’re going to dole out PSKs, why are they separate from the knock PSKs? (You sort of address this by sharing knock PSKs are per server and handshake PSK is per pair. But if I have a PSK per pair anyway, why not use it for knocks?)

- the knock protocol looks like semantically it wants a PRF. Is there a reason not to make it a PRF?

- Why isn’t this a Noise instantiation?

- Why sign instead of 3DH?

- Why is PBKDF2 involved in the PSK (preshared key)?

Of these, not using a PRF feels like a smell (probably not a vuln, but why would you choose to have that in your spec?). On the other hand, having PSKs and then choosing to have PBKDF2 involved (to stretch a passphrase, I guess?) and then having a key exchange anyway is really strange to me. The point of a key exchange protocol is to get a shared secret. But the protocol starts by assuming you already have a shared secret! Just use that already. Plugin in a PRF and the current time and some randomness and BAM: fast trustworthy crypto forever.

Of course, there's a reason we don't use PSKs all over the place: it means that instead of exchanging N public keys you have to exchange N^2 secret ones. People do it, but it's not the default. I'm fine with something that uses PSKs and something that uses public keys, but I don't understand why a system would have both. You get the operational complexity of PSKs and the performance of KEXes. Why bother? (I understand that the protocol says the PSK is to make it post-quantum, but you'd get identical post-quantum properties if you just skipped the KEX!)

Re: Oxy – A Security Focused Remote Access Tool

#60
post #48

Earlier quoted context omitted.

The virtue signaling doesn't come off as genuine as you tried to convey it.

If it's virtue signalling to point out a lack of precision then...well...harrumph...etc

I think some people sometimes use guy in the more casual non-gender-specific way, myself included. Maybe it's a cultural or regional thing?

And I guess it could be said that using guy is assuming the gender of someone, but one the other hand isn't that also assuming that the someone saying guy is making an assumption, etc, etc?

Perhaps it's just a bit sad when a whole point is disregarded because of a single ambiguous word?

I'd also find it cool if Mosh's features were available in Oxy, as it's great when using unsteady wifi connections, in trains and stuff.

Post reply on HN