Hacker News: janosdebugs

New comment by janosdebugs in "Can Engineers Stage a Coup and Take over Their Company?"

janosdebugs — Tue, 23 Jul 2024 16:16:41 +0000

Yeah, like the shares being transfered under duress. It's not like that can't be undone. The only thing this would achieve is a bunch of prison time and possibly destruction if data.

Not to mention that modern-day IT systems are such a mess that you'd need a crazy amount if time to find and access them all.

New comment by janosdebugs in "Inspect TLS encrypted traffic using mitmproxy and Wireshark"

janosdebugs — Thu, 11 Jul 2024 21:09:25 +0000

This seems awfully complicated. A lot of applications will happily respect system proxy settings and connect to mitmproxy directly.

New comment by janosdebugs in "GitHub Copilot is not infringing your copyright (2021)"

janosdebugs — Thu, 11 Jul 2024 21:05:41 +0000

Content gating behind login screens. Scraping content behind a login screen could constitute a contract violation and would give rise to a lawsuit independent of copyright.

New comment by janosdebugs in "OpenFeature: Standardizing Feature Flagging"

janosdebugs — Wed, 10 Jul 2024 06:01:44 +0000

After reading the specs, this sounds like an awful lot of complexity for something that should be simple and low cost. The spec also seems to be very loosely defined, more like a recommendation than a spec. This means you'll likely have to integrate a library and that library will be the authoritative source of truth as far as the expected behavior is concerned.

New comment by janosdebugs in "Plausible Analytics: GDPR Compliance w/o Cookie Consent Banner"

janosdebugs — Tue, 09 Jul 2024 11:38:12 +0000

Legitimate interest still requires the data subject to be informed under Art 13. Not sure how that would be accomplished without at least an info banner. (This goes for server logs too.)

New comment by janosdebugs in "Ask HN: Create audio software akin to physics engines?"

janosdebugs — Thu, 20 Jun 2024 04:11:52 +0000

Unreal Engine and Steam Audio may be worth looking into before you invest significant amounts of time into this.

New comment by janosdebugs in "Raspberry Pi is now a public company"

janosdebugs — Wed, 12 Jun 2024 11:17:03 +0000

Name recognition? You know exactly what you get, which isn't necessarily true for the bajilion clones out there. You know that if you buy an rPi, you can buy a replacement tomorrow and it will work the same. In a world where I can't even rebuy a laptop of the same make and model a few months later that's quite the advantage.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Sat, 08 Jun 2024 08:00:24 +0000

There are very legit reasons to use passwords, for example in conjunction with a second factor. Authentication methods can also be chained.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Sat, 08 Jun 2024 07:53:45 +0000

As far as OpenSSH is concerned, I believe the main problem is that there is no centralized revocation functionality. You have to distribute your revocation lists via an external mechanism and ensure that all your servers are up to date. There is no built-in mechanism like OCSP, or better yet, OCSP stapling in SSH. You could use Kerberos, but it's a royal pain to set up and OpenSSH is pretty much the defacto standard when it comes to SSH servers.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Sat, 08 Jun 2024 05:30:48 +0000

Not necessarily. There is a fork of OpenSSH that supports x509, but I remember reading somewhere that it's too complex and that's why it doesn't make it into mainline.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:41:22 +0000

As I said, "should". In some places there will be enough people in the chain that won't be bothered to go to the LIR directly. Think small rural ISPs in small countries.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:19:15 +0000

The provider doesn't care, the owner of the server who needs to log in from their home internet at 2AM in an emergency cares. Bad actors have access to botnets, the server admin doesn't.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:12:30 +0000

Use TOTP (keyboard-interactive) and password away!

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:09:46 +0000

I saw a Postgres story like this one. Badly managed AWS org with way too wide permissions, a data scientist sort of person set it up and promptly reconfigured the security group to be open to the entire internet because they needed to access it from home. And this was a rather large IT company.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:05:52 +0000

That may be true mathematically, but there are no guarantees that a small provider won't end up having only a single /64, which would likely be the default unit of range-based blocking. Yes, it "shouldn't" happen.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 20:03:25 +0000

The hard part is making sure every one of your servers got the CRL update. Since last I checked OpenSSH doesn't have a mechanism to remotely check CRLs (like OCSP), nor does SSH have anything akin to OCSP stapling, it's a little bit of a footgun waiting to happen.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 19:54:22 +0000

There is nothing wrong with this approach if enabled as an informed decision. It's the part where they want to enable this by default I have a problem with.

Things that could be done is making password auth harder to configure to encourage key use instead, or invest time into making SSH CAs less of a pain to use. (See the linked paper, it's not a long read.)

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 19:48:25 +0000

IPv6 has the potential to be even worse. You could be knocking an entire provider offline. At any rate, this behavior should not become default.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 18:42:01 +0000

You can use SSH certificate authorities (not x509) with OpenSSH to authorize a new key without needing to deploy a new key on the server. Also, Yubikeys are useful for this.

New comment by janosdebugs in "OpenSSH introduces options to penalize undesirable behavior"

janosdebugs — Fri, 07 Jun 2024 18:25:54 +0000

Having written an SSH server that is used in a few larger places, I find the perspective of enabling these features on a per-address basis by default in the future troubling. First, with IPv4 this will have the potential to increasingly penalize innocent bystanders as CGNs are deployed. Worst case, this will give bad actors the option to lock the original owner out of their own server if they have a botnet host in the same network. With IPv6 on the other hand, it is trivially easy to get a new IP, so the protection method described here will be completely ineffective.

From my experiments with several honeypots over a longer period of time, most of these attacks are dumb dictionary attacks. Unless you are using default everything (user, port, password), these attacks don't represent a significant threat and more targeted attacks won't be caught by this. (Please use SSH keys.)

I have seen experienced sysadmins create the test user with the password of "test" on a live server on port 22 because they were having an "autopilot moment". It got hacked within 20 minutes of going online and these mechanisms wouldn't have saved it, the attacker got in on the second or third try.

If you want to have a read about unsolved problems around SSH that should be addressed, Tatu Ylonen (the inventor of SSH) has written a paper about it in 2019: https://helda.helsinki.fi/server/api/core/bitstreams/471f0ff...