Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gz5
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
61.
▲
by
gz5
2y ago
Interesting, this has flip-flopped a few times so we have some evidence of behavior. Until 2015's 'net neutrality', ISPs could have theoretically prioritized or deprioritized certain packets, e.g. favor their own video stream
62.
▲
by
gz5
2y ago
since cyper-based (instead of sql), is the key question whether my k8s data is more graph-like or relational? adjacent but lots of experts here - independent of Cyphernetes or specific tooling, what are you doing to secure k8s api / ku
63.
▲
Germany government collapses at a perilous time for Europe
(nytimes.com)
50 points
by
gz5
2y ago
|
121 comments
64.
▲
by
gz5
2y ago
i believe the p2p strengths should play better with other in-progress tech transitions - e.g. transition of all thick apps to the browser, decentralized identity, micropayments, distributed IoT and IIoT devices. what do you think?
65.
▲
by
gz5
2y ago
nice use of WebRTC, which somehow is still underutilized. >If you're self-hosting and you want to access the signaling server remotely via mobile data, you may need to set up DDNS and port forwarding if your ISP provides a dynamic I
66.
▲
by
gz5
2y ago
>fully block all internet access to endpoints you don't fully control. Not that all risk can be eliminated, but this simplifies management while reducing the attack surface area by orders of magnitude. The good news is companies ar
67.
▲
by
gz5
2y ago
Forget about the market reaction for a minutes, which is always difficult to interpret. More holistically, aren't we underestimating their dev ecosystems (CUDA etc.)? Think of the dev ecosystem effects in all the various permutations,
68.
▲
by
gz5
2y ago
Nice. The deadline argument concept is smart and not in many other implementations. It seems there are two sides of the spectrum for secure SSH access: + Relatively infrequent access by limited # of people to servers which are not top targ
69.
▲
by
gz5
2y ago
Note: this was distributed to their customers today
70.
▲
by
gz5
2y ago
we can use the Internet without being used by the Internet. an open source example: https://blog.openziti.io/no-listening-ports
71.
▲
by
gz5
2y ago
Useful for a truly never-connected 'island' (meaning it never needs to speak to the outside world). However, even some of the use cases they cite rarely exist on a never-connected island, e.g. industrial automation and transportat
72.
▲
by
gz5
2y ago
Seems CS themselves may have been hacked? For example, seems unlikely that both: 1. CS normally pushes global updates to entire user base simultaneously? 2. This made it through their testing. Not only 'just' QA but likely CS empl
73.
▲
by
gz5
2y ago
yep was trying to avoid word which carry varying connotations, e.g. vpn or zero trust. zero implicit trust is likely the best term? you have to trust something, but enforce (and therefore trust) strong (not network based) identity, authN a
74.
▲
by
gz5
2y ago
Agree, good point, the overlay needs to do strong identity, authN, authZ. The critical part the overlay adds to traditional auth is making the server unreachable from the underlay networks, reducing attack surface by billions. Meaning: + L
75.
▲
by
gz5
2y ago
An attacker who gets username/pw still can't get on the overlay network (the overlay requires credentials which can't easily be stolen or compromised, e.g. a private key signed X.509 certificate). Yes, because 99% of attacks
76.
▲
by
gz5
2y ago
The root cause (1) is the data store should not have been available on the underlay network. Anything connected to an underlay network is a ticking time bomb. Any servers or admins which need to talk to the data store should instead use a
77.
▲
by
gz5
2y ago
consider* putting endpoints on a private overlay network in which network access is cryptography-gated (e.g. x.509 cert based). then, a misconfigured endpoint (or a zero day etc.) can't be exploited by any_actor_on_the_internet - actor
78.
▲
by
gz5
2y ago
>Why did it happen? Non-technical people have made choices and have optimized for stuff being cheap. Yes and amplified by: + Cybersecurity 'bad actors' are decentralized and distributed. They innovate at speed, with no barrier
79.
▲
by
gz5
2y ago
Encapsulate and encrypt in the app itself, or in the browser. App (via the openziti sdk): https://blog.openziti.io/no-listening-ports Browser (the openziti js sdk loads on the fly): https://blog.openziti.io/
80.
▲
Show HN: OpenZiti (Apache 2.0, P2P, E2E encrypted, full mesh overlay) is now 1.0
(github.com)
13 points
by
gz5
2y ago
|
0 comments
81.
▲
by
gz5
3y ago
For Chromium-based browsers, an option is to use BrowZer (built on OpenZiti, Apache 2.0). Enables you to connect into a full mesh private network (mTLS, e2e encrypted, no TLS man in middle inspection). 3 examples below with well known ap
82.
▲
by
gz5
3y ago
there are 3rd party foss options (1): 1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-we... 2. zero implicit trust: https://github.com/openziti/ziti-webh
83.
▲
by
gz5
3y ago
NetFoundry | $115k to 180k base comp | Full-time | REMOTE | USA | DevRel Leader You are responsible for building the OpenZiti developer community. This is initially an IC role; you will then build out a DevRel team. The open source OpenZiti
84.
▲
by
gz5
3y ago
Ironically (in an AI context), actions driven by human sentience has to be the #1 factor enabling this. I do think there are sub-factors, e.g. California legislation against non-compete and non-solicitation enabling Microsoft to (apparently
85.
▲
by
gz5
3y ago
well said and i agree. i believe we are talking about different layers. your point - essentially assume your network is always breached - absolutely. and don't you make that 'battle hardening' simpler and more effective by
86.
▲
by
gz5
3y ago
this is where zero trust has steered us wrong, inadvertently. absolutely perimeter security based on weak auth (being 'on' the WAN) is insufficient. but improving internal security doesn't address all internet-based attacks
87.
▲
by
gz5
3y ago
good point. i simply meant that the vulnerability can be exploited from the network (with no (initial) root access to the machine) and so almost all of them are.
88.
▲
by
gz5
3y ago
agree, but shouldn't we try to further reduce the attack surface? e.g. the 'server' only listens on networks which force 'clients' to authorize before those clients are given access to that network (not always poss
89.
▲
by
gz5
3y ago
Look at any major CVE and you will almost always see "...that attackers can exploit remotely". It is logical - 9x% of large cyber-attacks are done digitally, not with physical proximity to the target. Yet, we often focus on the vu
90.
▲
by
gz5
3y ago
NetFoundry | $115k to 180k base comp | Full-time | REMOTE | USA | DevRel Leader You are responsible for supporting the OpenZiti developer community. This is initially an IC role; you will then build out a DevRel team (our engineers do our
More ›