3 ms·

Not going there with anything HTTP/3. Disclaimer: I write network packet parsers for XNS/IPS/IDS for a living, to look for "bad things".

qwertox 3y ago
I wish you would share some of your thoughts.
mmaunder 3y ago
How intentionally vague.
- lajamerr 3y ago
  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.
  - insanitybit 3y ago
    Odd, surely SSHv2 already suffers from inability to inspect on the wire.
    - egberts1 3y ago
      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.
      - insanitybit 3y ago
        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.
  - egberts1 3y ago
    More like incomplete state machine for HTtP/3-QUIc
  - NegativeK 3y ago
    The owning organization or user should already have full admin on all endpoints. Malicious apps and attackers should not.
nixgeek 3y ago
The standards bodies don’t seem to buy the “bad things” argument and appear resolute on making it harder to MITM traffic on the wire and attempting to force IDS/IPS to all be run on the client. Is there a 5-10 year future where you just can’t do this as a middlebox?
- jeroenhd 3y ago
  Protocols supported MITM with correct configurations and it led to complete ossification of said protocols because middleboxes suck at following standards. It seems that at the time these features were dropped, most middleboxes have ignored features like exporting keys or configuring static RSA keys and went for CA-MitM attacks instead. You should expect these tools to break if they're actively trying to subvert protocols to do things they're not designed to support. I don't really see what changed, though. I guess static keys were dropped to provide forward secrecy, but other than that running your own rogue CA is as possible as it was 20 years ago. Middleboxes lagging behind in support for features like HTTP/3 is probably annoying, but that's because of a lack of implementation more than anything. You can still use your domain tools/MDM configuration/settings to configure an HTTPS proxy and firewall off the normal ports if you want to MitM your network reliably. If yiur prozy doesnt support http/3, it will happily downgrade your connection to HTTP/1.1 for you. Android's insistence on not actually applying user-installed certificates is a pain for many apps, but other operating systems will happily and silently drop security measures like certificate transparency when they encounter a user-operated MitM CA. The lack of MitMability comes down to Android being fussy, IoT devices you had no chance of ever controlling needing workarounds, and devices you don't have permissions to manage not being manageable. I really do wish Android would let MDM solutions inject certificates into the system store (though I can see why they don't with the wide range of stalkerware in the wild).
  - egberts1 3y ago
    Second paragraph: "most middleboxes ..." It is the "others".
password4321 3y ago
My understanding is limited, but HTTP/3 boils down roughly to HTTP/2+QUIC. Major cloud providers are still shaking issues out of HTTP/2 like "Rapid Reset" 2 months ago, the nesting and layers open gaps and new edge cases as naive implementations were clearly not yet battle hardened even against old attack families like amplification/resource exhaustion. https://news.ycombinator.com/item?id=37830987 https://news.ycombinator.com/item?id=37830987 The novel HTTP/2 'Rapid Reset' DDoS attack https://news.ycombinator.com/item?id=37837043 https://news.ycombinator.com/item?id=37837043 HAProxy is not affected by the HTTP/2 Rapid Reset Attack
deleted 3y ago
[deleted]
xorcist 3y ago
Not sure why this is downvoted. HTTP3/QUIC is a lot more complex to implement than SSH. SSL is a very well studied standard, but it is clearly a committee product with lots of features built on enterprise standards like X.509, and SSH is made by a few protocol engineers with a razor sharp use case. It is easy to see why someone who audits parsers for a living would be much more comfortable with SSH as compared to a something over HTTP/SSL/QUIC.

qwertox 3y ago

I wish you would share some of your thoughts.

mmaunder 3y ago

How intentionally vague.

lajamerr 3y ago
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.
- insanitybit 3y ago
  Odd, surely SSHv2 already suffers from inability to inspect on the wire.
  - egberts1 3y ago
    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.
    - insanitybit 3y ago
      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.
- egberts1 3y ago
  More like incomplete state machine for HTtP/3-QUIc
- NegativeK 3y ago
  The owning organization or user should already have full admin on all endpoints. Malicious apps and attackers should not.

nixgeek 3y ago

The standards bodies don’t seem to buy the “bad things” argument and appear resolute on making it harder to MITM traffic on the wire and attempting to force IDS/IPS to all be run on the client. Is there a 5-10 year future where you just can’t do this as a middlebox?

jeroenhd 3y ago
Protocols supported MITM with correct configurations and it led to complete ossification of said protocols because middleboxes suck at following standards. It seems that at the time these features were dropped, most middleboxes have ignored features like exporting keys or configuring static RSA keys and went for CA-MitM attacks instead. You should expect these tools to break if they're actively trying to subvert protocols to do things they're not designed to support. I don't really see what changed, though. I guess static keys were dropped to provide forward secrecy, but other than that running your own rogue CA is as possible as it was 20 years ago. Middleboxes lagging behind in support for features like HTTP/3 is probably annoying, but that's because of a lack of implementation more than anything. You can still use your domain tools/MDM configuration/settings to configure an HTTPS proxy and firewall off the normal ports if you want to MitM your network reliably. If yiur prozy doesnt support http/3, it will happily downgrade your connection to HTTP/1.1 for you. Android's insistence on not actually applying user-installed certificates is a pain for many apps, but other operating systems will happily and silently drop security measures like certificate transparency when they encounter a user-operated MitM CA. The lack of MitMability comes down to Android being fussy, IoT devices you had no chance of ever controlling needing workarounds, and devices you don't have permissions to manage not being manageable. I really do wish Android would let MDM solutions inject certificates into the system store (though I can see why they don't with the wide range of stalkerware in the wild).
- egberts1 3y ago
  Second paragraph: "most middleboxes ..." It is the "others".

password4321 3y ago

My understanding is limited, but HTTP/3 boils down roughly to HTTP/2+QUIC. Major cloud providers are still shaking issues out of HTTP/2 like "Rapid Reset" 2 months ago, the nesting and layers open gaps and new edge cases as naive implementations were clearly not yet battle hardened even against old attack families like amplification/resource exhaustion. https://news.ycombinator.com/item?id=37830987 https://news.ycombinator.com/item?id=37830987 The novel HTTP/2 'Rapid Reset' DDoS attack https://news.ycombinator.com/item?id=37837043 https://news.ycombinator.com/item?id=37837043 HAProxy is not affected by the HTTP/2 Rapid Reset Attack

deleted 3y ago

[deleted]

xorcist 3y ago

Not sure why this is downvoted. HTTP3/QUIC is a lot more complex to implement than SSH. SSL is a very well studied standard, but it is clearly a committee product with lots of features built on enterprise standards like X.509, and SSH is made by a few protocol engineers with a razor sharp use case. It is easy to see why someone who audits parsers for a living would be much more comfortable with SSH as compared to a something over HTTP/SSL/QUIC.