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.
I thought timing attacks only matter for clear data to encrypted data and back part of the library, and as long as they didn’t write any data parsing that is content specific pre or post encryption their encryption and didn’t write their own encryption then there shouldn’t be any major holes.
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].
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).
You pretty much just have to demonstrate the benefits to the maintainers of a few major distros and that it should be the default and the rest will follow to avoid breaking interop.
Two major releases is a safe bet from the time the decision is made so <10 years.
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.
I really like the site as it currently is. I've been considering converting my own website, which has CSS but I've still gotten readability complaints about (usually I'm the one complaining), to such a plain format.
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..
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.
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 I'm certain someone could slip some obfuscated code in a project with several thousand lines of code and I'd never know it.
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.
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.
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.
I have no problem with your original, or particularly with your use of "guy". But the dictionary excerpt seemed to clearly show that the usage was incorrect, as it only applies to groups. So my comment is entirely about the person who accused the other commenter of virtue signalling.
And I agree with you about Mosh style features. That would be lovely.
> From The Collaborative International Dictionary of English v.0.48 [gcide]:
> [...]
> 4. A member of a group of either sex, usually a friend or comrade; -- usually used in the pl.; as, tell the guys to come inside; are any of you guys interested in a game of tennis?. [Informal] [PJC]
"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."
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!
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.
I haven't audited the code, but did take a peek at the protocol. Nothing obviously busted from the description, but there are definitely some weird design choices. https://news.ycombinator.com/item?id=17393780
I don't think it's being called out as a bad idea. It seems to me that the author sees it as a feature to provide this in the tool and protocol, and is mentioning it. Whether it really is a good idea remains to be seen.
[edited when I re-read the blurb and realized that oxy does more than ssh in this case]
I interpreted this as not being a ‘bad idea’, rather, the implementation of rsync’s feature could be simplified if OpenSSH behaved in a similar way to Oxy.
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.
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.
- 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?
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.
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!)
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.
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?)
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.
Ah! I figured out the underlying reason: in the default configuration the PSK isn't per-peer-pair, it's per server. That makes a ton more sense! You get to keep the relatively simple key distribution mechanism, keep identity despite a team-shared PSK (that's what signing solves), and you get PQ resistance.
(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.)
Hah, OK then :-) I figured there might be a unit-testy reason or something -- where you can temporarily disable panics and patch out process exits. Thanks!
I think (from issue tracker spelunking) PBKDF2 got added in because at some point the PSKs weren't very strong and intended to be human-transmittable. They're still in the transport protocol. I'm not sure why, but I guess for some parameter choices it could improve forward secrecy? (That is: if you break a KEX at t=0 now you have to compute a hard function a bunch of times to make it to t=now if sessions are long-held? Seems far-fetched but...)
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) :)
>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.
"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."
87 comments
[ 3.2 ms ] story [ 154 ms ] thread$ 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.
A link to the Github repo would also help with gaining usage: https://github.com/oxy-secure/oxy
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.
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.
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.
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
From https://www.merriam-webster.com/dictionary/guy
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.
And I agree with you about Mosh style features. That would be lovely.
> From The Collaborative International Dictionary of English v.0.48 [gcide]:
> [...]
> 4. A member of a group of either sex, usually a friend or comrade; -- usually used in the pl.; as, tell the guys to come inside; are any of you guys interested in a game of tennis?. [Informal] [PJC]
"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".
.question { font-family: Courier; }
>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.
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.
- 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.
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) :)
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.