Hi Denis, This presentation is only describing one attack. Page 12 summarises it. The attack is not a full attack targeted against oauth, but it shows how a malicious network can steal any codes returned to the browser in the URL, even if the codes are always sent over TLS.
I was only responding to your assertion that PKCE is not required when TLS is in use. I believe that assertion was not right, as the above attack is against TLS enabled servers and PKCE would have made any stolen auth code useless, so PKCE still has value even when using TLS. Thanks Joseph > On 23 May 2018, at 12:58, Denis <[email protected]> wrote: > > Hi Joseph, > > Among these 39 slides, to which attack(s) are you referring ? > > I wrote:"It is quite hard to understand under which context(s) and conditions > OAuth 2.0 could be safely used". > > For each counter-measure, it would be useful to explain under which > context(s) or under which assumptions > it should be used. > > Denis > >> Hi Denis, >> >>> On 22 May 2018, at 14:05, Denis <[email protected] >>> <mailto:[email protected]>> wrote: >>> In particular, the text states: >>> >>> "Clients shall use PKCE [RFC7636] in order to (with the help of the >>> authorization server) detect and prevent attempts >>> to inject (replay) authorization codes into the authorization >>> response". >>> >>> This is incorrect, since RFC7636 should be used when the authorization code >>> is returned from the authorization endpoint >>> within a communication path that is not protected by Transport Layer >>> Security (TLS). >>> >> That is not really the full story as we've seen attacks where URLs that you >> would expect to be protected by TLS are vulnerable; one example is: >> >> https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf >> >> <https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf> >> >> IMHO it would be sane to use PKCE anywhere where a code is returned in the >> URL and there isn't another proof of possession / token binding mechanism in >> play. >> >> Joseph >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
