Which you appear to be the developer of from other comments in this thread. Not saying it's bad, but it's self-promotion rather than organic preference.

I think if it's strongly relevant and someone else started the conversation, that it's fine as long as there's disclosure.

HN is for self promotion

> Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.

https://news.ycombinator.com/newsguidelines.html

I felt you could really tell his enthusiasm was for the arts.

Which is fine, of course, everyone has preferences; but the contrast with the much more rote science episodes did make me a little sad.

Disappointing response. Guess I'll continue to avoid Kagi.

> - OpenZiti does not require inbound ports or hole punching, it builds outbound only connections via an overlay which looks sort of similar to DERP (but better with app specific encryption, routing, flow control, smart routing etc). This overlay also removes need for complex FW rules, ACLs, public DNS, L4 loadbalancers, etc.

The routers that you deploy to make up the overlay still need inbound ports though, right? I thought that's what 10080 was doing.

Yes, but the risk posture is very different. The question I like to ask is, 'what does it take to exploit a listening port on the overlay to get to a service':

- (1) need to bypass the mTLS requirement necessary to connect to the data plane (note, each hope is uses its own mTLS with its own, separate key).

- (2) have a strong identity that authorizes them to connect to the remote service in question (or bypass the authentication layer the controller provides through exploits; note again, each app uses separate and distinct E2EE, routing, and keys)

- (3) know what the remote service name is, allowing the data to target the correct service (not easy as OpenZiti has its own private DNS that does not need to comply to TLDs)

- (4) bypass whatever "application layer" security is also applied at the service (ssh, https, oauth, whatever)

- (5) know how to negotiate the end to end encrypted tunnel to the 'far' identity

So yes, if they can do all that, then they'd definitely be able to attack that remote service. Note, they only have access to 1 single service among hundreds, thousands, or potentially millions of services. Lateral movement is no possible. So the attacker would have to repeat each of the 5 steps for every service.

A colleague wrote this too, its from a slightly different angle but still very relevant - https://blog.openziti.io/no-listening-ports.

Maintainer here. Yes. The routers and the controller will have a port that can accept mTLS traffic.

Their communication really is all over the place. Even the name is really awkward in English.

(And yes, not everything should be forced to be English and it's apparently supposed to be Esperanto; but nothing else on the site is so that's not how most people will parse it).

I was working there at the time and even internally Jazelle documentation was hidden. Very odd for what it is.

Likely licensing issue with Sun/Oracle?

One rationale I've seen somewhere is that they were intentionally trying to not commit to a stable instruction set they'd need to support going forward, i.e. intentionally make support very closely coupled to a specific JVM and OS implementation.

Of course it might just also have been a cooperation with a specific JVM vendor (that could then promote their JVM as the fastest on a given set of CPUs).

I'm vaguely sympathetic to these crypto people's end goals (talking about things like constant time evaluation & secret hiding), but it's really not what general purpose compilers are even thinking about most of the time so I doubt it'll ever be more than a hack that mostly works.

They'll probably need some kind of specialized compiler of their own if they want to be serious about it. Or carry on with asm.

The author has written such a compiler: https://cr.yp.to/qhasm.html (or at least, a prototype for one)

Jasmin has largely replaced qhasm.

Jasmin is also an assembler for JVM bytecode, love overloaded names.

Traefik's YAML does a particularly bad job at keeping syntax (such as it is) separate from user-defined labels, I feel.

Very difficult to just look at a file and see which bits are labels for the sake of it, and which bits are direct instructions to builtin features.

I’ve put a warning sign over the big red button so we should be fine.

Oops - too late.