
Oxy – A Security Focused Remote Access Tool - thesimon
https://oxy-secure.app/
======
kotharia
No longer able to access the website but still on GitHub
[https://github.com/oxy-secure/oxy](https://github.com/oxy-secure/oxy)

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

~~~
code_duck
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.

~~~
nebulous1
> 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.

~~~
code_duck
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.

~~~
raesene9
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..

~~~
floatboth
> crypto+rust

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

------
lvh
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!)

~~~
galadran
The Noise framework (and Wireguard) deliberately support the combination of
psk and public key authentication. One clear benefit is that you get
redundancy against a failure in either mode. If your DH implemention is
broken, the attacker still has to compromise your shared secret. Alternatively
if the attacker compromises your shared secret, they still have to break your
public key crypto. In short, its an excellent hedge against user or
implementor error.

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.

~~~
lvh
I get the general argument, but the spec doesn't really try to make that case.
The default knock and PSK are (PQ) tiny: they appear to be 20 base32-encoded
bytes or 96 bits of entropy. If they were being used in the same sense as
Wireguard/Noise's PQ, I'd expect them to be 256 bits.

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

------
thesimon
Author seems to be
[https://twitter.com/JennaMagius/status/1010893277069914113](https://twitter.com/JennaMagius/status/1010893277069914113)

------
newdayrising
"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."

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

~~~
mxuribe
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 web. As an example, for me on a
windows 7 machine using chrome, it displays the font as Times New Roman; other
browsers and OS combo might show different system fonts. I hope this helps!

~~~
markussss
The questions are styled to use courier, though.

.question { font-family: Courier; }

~~~
elliotpage
Yes, this is what I meant! Thank you!

------
kuwze
Man if this guy copied Mosh's feature-set it would be really awesome.

edit: I guess I assumed something I shouldn't have

~~~
tptacek
It does not appear to be a "guy".

~~~
newdayrising
It is a "guy":

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

~~~
tptacek
¯\\_(ツ)_/¯

I was just going off the name and the fact that their (Github, I think?) bio
described them as a "girl".

------
tmikaeld
Seems really good! Might be interesting when there's an official third party
audit (Yeah i know you do pentesting as a profession but that's biased, we
need unbiased).

A link to the Github repo would also help with gaining usage:
[https://github.com/oxy-secure/oxy](https://github.com/oxy-secure/oxy)

------
LinuxBender
Interesting!

\- 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?

~~~
nickik
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.

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

~~~
floatboth
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.

~~~
nickik
I have a Yubikey to but I never really liked that setup. I would much prefer
to have my private keys on my computer and have U2F.

------
parliament32
>Oxy operates as a hidden service, and connection initiation occurs over two
phases: a UDP "knock", followed by a TCP connection that will contain all
subsequent connection data. The TCP connection defaults to port 2600; however,
the UDP "knock" uses a port number between 1025 and 65535, derived from the
server's "identity" value. By not using a standardized port, detection of oxy
services (and thereby deployment of exploits targeting the oxy service) is
made more difficult.

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.

------
chinarulezzz
>Memory Safe + Fast

$ grep 'unsafe {' -R ~/oxy --include=*.rs | wc -l

13

Not bad.

~~~
jandrese
It's a good start, but the problems with SSH lately have largely been things
like timing attacks that even the smartest compiler won't catch.

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.

~~~
nine_k
I wonder how efficient a counter-measure would be adding small random delays
in every part of code, possibly injected at MIR or LLVM level. It might drown
any timing information in random noise.

They will definitely lower the performance, but likely a bit slower and more
secure connection process is preferable to a less secure one.

~~~
ryanong
From my current understanding adding random noise doesn’t affect most timing
attacks because it is averaged out. I may be wrong though

------
provlem
This is cool. Since, I know rust, I will be auditing source code tool soon and
will write up, if I find any thing.

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

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?

~~~
tmikaeld
Having it in all Linux/Unix default repos would certainly help?

------
lucb1e
This looks really neat. A fresh codebase creates the opportunity for some new
things that would otherwise be breaking or hard to implement, as the author
seems to have done.

------
wstuartcl

    	  curl -O https://oxy-secure.app/oxy
    	  chmod +x oxy
    	  ./oxy --help
    
    

All the signs of a security conscious developer.

------
otterpro
Having an alternative to SSH is appealing, as SSH is pretty much required for
most servers but it is also target of most attack vectors. If Oxy becomes
production-ready, I'd definitely consider using it so I can block all SSH and
eliminate SSH brute force attacks on my servers. As for SSH security, I
strongly recommend Fail2Ban, alternate SSH port number, and requiring key-
based authentication.

------
snvzz
>Well how does rsync work, then? rsync relies on executing a non-ssh helper
program on the remote.

And that's a bad idea why?

~~~
CGamesPlay
It is a "bad idea" in terms of attackable footprint, although I don't think it
was being called out as a bad idea in this page, more of clarification that
the stated feature really doesn't exist in SSH.

~~~
snvzz
>It is a "bad idea" in terms of attackable footprint

So the more the features jammed in, the safer? Something about that doesn't
seem alright to me.

------
pm
I'm not a security expert, so could one of the security experts who frequent
HN weigh in on this? Otherwise this looks super cool.

~~~
thesimon
I'm not a security expert and can only point out one thing that I noticed from
my knowledge from network security class in college:

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

