Non-idempotent methods (PUT, DELETE) use early data (with QUIC)
Reported by
slus...@gmail.com,
Apr 17 2018
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4 Steps to reproduce the problem: It seems that there behaviour of POST is not the same as behaviour of PUT and DELETE, when 0-RTT is used. POST request is not sent in early data; but PUT and DELETE use early data. Non-idempotent requests should not use early data (because of their replay-ability). Verification steps: - establish a (full) connection ( GET request) - wait until the connection is terminated (timed out). - issue a GET request - 0-RTT should be used. - wait until the connection is terminated (timed out). - issue a new request, that uses method PUT, POST or DELETE. Attached logs: PUT, POST and DELETE requests. POST does not use early data (0-RTT connection is established), PUT and DELETE use early data. What is the expected behavior? Non-idempotent methods (PUT, POST, DELETE) do not use early data. What went wrong? Early data is used with PUT and DELETE. Did this work before? N/A Chrome version: 67.0.3381.0 Channel: n/a OS Version: OS X 10.12.5 Flash Version: Shockwave Flash 29.0 r0
,
Apr 17 2018
Early data is subject to replay attack, therefore I chose the type "security". I am not sure if it was appropriate.
,
Apr 18 2018
,
Apr 18 2018
rch@, zhongyi@ -- can you please take a look at this externally reported security bug and help triage it? Could you also comment on what would be the appropriate severity level for this? Thanks!
,
Apr 18 2018
svaldez: I would have thought that this would be fixed by: https://chromium-review.googlesource.com/934522 But that seems to have been released in 67.0.3360.0 which would mean it's present in the repro mentioned in this bug. WDYT?
,
Apr 18 2018
The CL in #5 does seem to use HttpUtil::IsMethodSafe which excludes PUT and DELETE, but it is worth noting that both PUT and DELETE are idempotent.
bool HttpUtil::IsMethodIdempotent(const std::string& method) {
return IsMethodSafe(method) || method == "PUT" || method == "DELETE";
}
,
Apr 18 2018
The UA string in the network logs from #0 suggest that they were captured in Chrome 65. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
,
Apr 19 2018
You are right, I should have written unsafe methods instead of "non-idempotent" methods.
,
Apr 19 2018
Re #8: can you confirm this no longer repros in Chrome 67 and later?
,
Apr 19 2018
I will test it and I'll let you know.
,
Apr 19 2018
,
Apr 19 2018
As mentioned, this should be fixed in M67 and later. But yes, the correct behavior for IETF QUIC and TLS 1.3 0-RTT is to only do early data with SAFE methods.
,
Apr 19 2018
elawrence: Thanks for pointing out the right Chrome version! I'll mark this as fixed. In any case, the use of 0-RTT for idempotent, but unsafe methods was an intentional behavior of Google QUIC. The prohibition of using unsafe methods in 0-RTT was added as part of the standardization process for QUIC at the IETF.
,
Apr 20 2018
OK, Thanks. Indeed, early data is prohibited in newer Chrome for unsafe method, my tests went fine.
,
Apr 20 2018
Re #14: Thanks for confirming!
,
Apr 20 2018
,
Apr 20 2018
Marking as Verified, and removing the security bug labels, as the previous behavior was WAI for Google QUIC. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by vakh@chromium.org
, Apr 17 2018Components: Internals>Network Internals>Network>QUIC
Owner: rch@chromium.org