Oxy – A Security Focused Remote Access Tool
oxy-secure.app
oxy-secure.app
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 lack of any form of signed binaries would make me a little nervous from a security focused tool. You're then not only trusting the author(s) but their web hosting providers as anyone with access to that webserver can change the binary without it being obvious that they have.
As a comparative: https://www.wireguard.com/
That how a serious open source project looks like.
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.
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..
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.
Since source is available, of course you should audit it, or at least glance over it before compiling.
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.
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.
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.
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!)
Less tangibly, it can prevent an adversary from recording your traffic now, waiting until Quantum Computers are practical, breaking your public key crypto and reading your messages.
Sure, you can't just slap both modes together and claim the adversary has to break both, some care is involved, but it absolutely isn't strange at all.
tl;dr there are plenty of good reasons to use a combination of modes. Both Noise and Wireguard have built on support for strengthening public key crypto with psks.
EDIT: I take it back: the keys _used_ to be 96 bits (example given in the protocol description), but are now 256 judging by the keygen code. Apparently (I'm spelunking in the bug tracker) they were short once because there was an attempt to make them diceware-style verbally transmittable? Regardless: at least it looks like an effective PQ measure assuming the key derivation works.
(Generally hedging against DH snafus makes a lot of sense to me, hedging against clients who can somehow manage to hold on to one kind of key material but not another is less convincing. I guess you could have P-256 on a smartcard and PSK on disk or something?)
The code relying on that just extends the generated key with the statically found key, so it appears to be fine as long as you just chuck enough entropy in. So it appears an empty shared secret would just do what you'd expect: just the DH bit.
(The problem this addresses is a passive observer who eventually gets a quantum computer, but can't pop any machines to just steal the PSK or whatever.)
https://github.com/oxy-secure/oxy/blob/571ef12199f8b0f3eca55...
What is the point of panic! after exiting the process?
It's really nice to see protocols where people use memo fields to make sure one key can't be derived for another purpose though, and that is a feature you get out of PBKDF2 (but not only PBKDF2, hence my question) :)
.question { font-family: Courier; }
edit: I guess I assumed something I shouldn't have
> 1 a : man, fellow
> b : person —used in plural to refer to the members of a group regardless of sex
> saw her and the rest of the guys
"Dylan Davis (@JennaMagius) is a senior security analyst at RiskSense. He has performed a variety of Fortune 500 incident response engagements, discovered new CVEs in major software, and performed vulnerability analysis on a wide variety of embedded devices."
I was just going off the name and the fact that their (Github, I think?) bio described them as a "girl".
A link to the Github repo would also help with gaining usage: https://github.com/oxy-secure/oxy
- Does this have the buffer limitations for file transfer that ssh has? i.e. Can I send near wire speed?
- Which independent third party pen testing and code validation groups have reviewed this?
- Since this does not depend on rsync helpers for file transfers, are there any plans to add multipart transfers similar to lftp's p-get or other mirror sub-system functions? i.e. split a 40gb file into 20 chunks / streams.
- Is the UDP knocker optional? I can think of places that won't work. Captive portals, hotels, some airports, some public wifi, some corp networks.
- What setcap capabilities does this require?
- Any plans to add modules or helpers for things like U2F?
- Any thoughts on centralized management of key trusts? that is the biggest gap in openssh that I know of and the original author of ssh acknowledges. i.e. "who" is really logging in as "who", "where" and how old is that key?
But to have a ssh like thing that supports U2F out of box would be amazing.
https://github.com/gravitational/teleport https://gravitational.com/teleport/docs/admin-guide/#fido-u2...
Disclaimer: I work for gravitational, but not on teleport.
By not using a standardized port, I can't firewall off UDP on non-essential ports... I hope there's a way to disable this.
$ grep 'unsafe {' -R ~/oxy --include=*.rs | wc -l
13
Not bad.
In fact a smart optimizing compiler can make that even harder to avoid since it is more difficult to know exactly what machine code it will produce.
They will definitely lower the performance, but likely a bit slower and more secure connection process is preferable to a less secure one.
https://github.com/oxy-secure/oxy/blob/571ef12199f8b0f3eca55...
- in ui.rs, for resetting the blocking state of stdin via fcntl
- in tuntap.rs, for an ioctl to do some tun/tap setup, and resetting errno beforehand
- in pty.rs, for ioctls for controlling terminal admin and setting the terminal size
- in util.rs, for getting the current UID, calling getpwnam or getpwuid, and extracting field values from the resulting passwd struct
I have to confess that i don't know the details of the Linux API well enough to know for sure, but they all look eminently reasonable.
I’m interested: how long does it take for a piece of critical software like this to gain widespread adoption with a non-shite incumbent?
Two major releases is a safe bet from the time the decision is made so <10 years.
curl -O https://oxy-secure.app/oxy
chmod +x oxy
./oxy --help
And that's a bad idea why?
[edited when I re-read the blurb and realized that oxy does more than ssh in this case]
So the more the features jammed in, the safer? Something about that doesn't seem alright to me.
>Upon successful verification of the signature contained in the third message (and verification that the eight-byte timestamp is current), the server proceeds to send three symmetrical messages: a long term server public key, an ephemeral server public key, and a signature message authenticating the ephemeral key.
This might be vulnerable to replay attacks. The user proves freshness of his request by sending a signed unix timestamp, the server however doesn't seem to do that.
Shouldn't compromise the security of the protocol, just one thing that I noticed.