<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">
Thanks all - I'll either see if ADFS would be able to use a POST binding for its request, or I'll teach our F5s to bounce away the prefetch requests as Alessandro describes. Currently our requests from ADFS are signed so there is something to be subverted if
we were to allow replays. <br>
<br>
</div>
<div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">
<div dir="auto" style="direction:ltr; margin:0; padding:0; font-family:sans-serif; font-size:11pt; color:black">
Get <a href="https://aka.ms/ghei36">Outlook for Android</a></div>
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of Cantor, Scott <cantor.2@osu.edu><br>
<b>Sent:</b> Tuesday, October 16, 2018 1:04:33 PM<br>
<b>To:</b> Shib Users<br>
<b>Subject:</b> RE: Issues with Chrome "prefetching" our IdP pages</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">> Actually I think that chrome is indeed doing something "wrong" here, as typing<br>
> an SP URI in Chrome browser will cause a background "prefetch" request to the<br>
> SP which under certain circumstances** will cause subsequent prefetch to the<br>
> IDP followed by a Replay Attack warning (in the IDP logs) once the user finishes<br>
> typing the SP URI and presses enter (header is: "Purpose: prefetch")<br>
<br>
But the point is that in HTTP a GET is supposed to be idempotent, and SSO protocols with message IDs and replay checking break that rule. Really the best thing to do is use POST for requests and that is perfectly allowed in SAML.<br>
<br>
But as Nate said, my opinion on replay checks is about usability, not security. There is no good outcome that will ever be possible from a replay, and it's simply a matter of opinion what the "best" bad option is for usability.<br>
<br>
We should have exposed an option to disable the checking but I don't think it ever got filed as a RFE so I never got around to it. It's possible, just not clean.<br>
<br>
-- Scott<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg">
https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br>
</div>
</span></font>
</body>
</html>