News for hackers. Stuff that matters.
Re:SSH3: SSHv2 using HTTP/3 and QUIC by lajamerr on Saturday December 16, 2023 @11:19AM (#38665351)
I assume he means with the encrypted metadata in HTTP/3 / QUIC that it makes it harder as a security admin to "peek" at what is going on in the network.

In my opinion its short sighted, because if we care about security, then we should care about user security and privacy as well. Because if the security admin has the ability to packet inspect stuff, so does a potential malicious app.

Re:SSH3: SSHv2 using HTTP/3 and QUIC by insanitybit on Saturday December 16, 2023 @12:41PM (#38666193)
Odd, surely SSHv2 already suffers from inability to inspect on the wire.
Re:SSH3: SSHv2 using HTTP/3 and QUIC by egberts1 on Saturday December 16, 2023 @02:50PM (#38667140)
From the Github:

SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication.

So, it has nothing to do with SSH2; more about HTTP/3-QUIC security theater: hostname is still being sent over TLS/1.3 negotiation.

Re:SSH3: SSHv2 using HTTP/3 and QUIC by insanitybit on Saturday December 16, 2023 @04:29PM (#38667880)
To be clear, my reading of the parent post is that the grandparent doesn't like HTTP/3-QUIC making it harder to read data off of the wire (ie: for internal security analytics).

But I don't see how this is worse than SSHv2. In both cases retrieving the hostname / IP is obviously trivial since you just instrument DNS for the hostname and, of course, the IP is cleartext.

Re:SSH3: SSHv2 using HTTP/3 and QUIC by egberts1 on Saturday December 16, 2023 @02:06PM (#38666836)
More like incomplete state machine for HTtP/3-QUIc
Re:SSH3: SSHv2 using HTTP/3 and QUIC by NegativeK on Saturday December 16, 2023 @04:09PM (#38667696)
The owning organization or user should already have full admin on all endpoints.

Malicious apps and attackers should not.