3 ms·
The section "How secure is HTTP/2 compared to HTTP/1?" (https://portswigger.net/research/http1-must-die#how-secure-is-http2-compared-to-http1 https://portswigge
by ameliaquining 1y ago
The section "How secure is HTTP/2 compared to HTTP/1?" (https://portswigger.net/research/http1-must-die#how-secure-is-http2-compared-to-http1 https://portswigger.net/research/http1-must-die#how-secure-i...) responds to this. In short, there's an entire known class of vulnerabilities that affects HTTP/1 but not HTTP/2, and it's not feasible for HTTP/1 to close the entire vulnerability class (rather than playing whack-a-mole with bugs in individual implementations) because of backwards compatibility. The reverse isn't true; most known HTTP/2 vulnerabilities have been the kind of thing that could also have happened to HTTP/1.
Is there a reason you don't find this persuasive?
- nitwit005 1y agoThe new features/behaviors in the new protocol inherently create new classes of vulnerabilities. That above link relates to an issue with RST_STREAM frames. You can't have issues with frames if you lack frames. It's quite possible the old issues are worse than the new ones, but it's not obvious that's the case.