Hacker News Reader

If all your endpoints are at least somewhat under your control (i.e. the thing doesn't need to be accessible via a web browser on a vanilla computer) you can reduce "exploits" to "exploits of my implementation of TLS/my VPN of choice" plus the bootstrap issue.

If the endpoints are not under your control to that extent, then I'd argue that "all the residential ISPs in US" is just as bad as "all of China/Russia" due to botnets.

View on HN

I'm not sure what you mean by implementation of TLS. It's just standard Java TLS libraries, though of course we can be pretty strict about which ciphers are in use - we do control the client to that extent and are typically pretty good about keeping on top of that at least.

If you require client certificates then you don't need to worry about non-insider attacks on anything other than your TLS library and your client cert bootstrap procedure.

I didn't even think of that as a possibility, but it's a good suggestion and something that's within the realm of feasible (though far from trivial) for us. Thank you.

TBF putting a reverse proxy that does authn and rejects requests that do not authn correctly in front of everything (except for the login pages) is nearly as good: the exposed area is then login page, reverse proxy, and the authn login in the reverse proxy. That might be vastly simpler to implement.

Reply on news.ycombinator.com