<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote type="cite"
cite="mid:DB7PR01MB4805A7F231E286A5FD412355B2FD0@DB7PR01MB4805.eurprd01.prod.exchangelabs.com">
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
dir="ltr">
<p style="margin-top:0;margin-bottom:0"><span style="font-size:
12pt;">Technically I suppose Chrome isn't doing anything
wrong because it's a GET request which it's free to request
whenever it feels like it, but it'd be good if there were a
way to opt out through headers. I'll try various responses
to the requests with the "Purpose: prefetch" header.</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size:
12pt;"><br>
</span></p>
</div>
</blockquote>
<p><br>
</p>
<p>Actually I think that chrome is indeed doing something "wrong"
here, as typing an SP URI in Chrome browser will cause a
background "prefetch" request to the SP which under certain
circumstances** will cause subsequent prefetch to the IDP followed
by a Replay Attack warning (in the IDP logs) once the user
finishes typing the SP URI and presses enter (header is: "Purpose:
prefetch")<br>
</p>
<p>Now it might be possible to:</p>
<p>- ignore the issue at all and ask the user to open the SP URI
again (...)<br>
- disable this behavior in chrome (obviously not feasible for
those who have publicly exposed SP/IDPs)<br>
- open a discussion on the topic with google<br>
- disabling replay attack detection as mentioned by Scott
(although he is not recommending it) <br>
</p>
<p>or try in some other ways. The approach I'm testing is by
"ignoring" the "prefetch" requests on the IDP side by detecting
the header that Chrome uses while it performs those requests in
the background, preventing the request from reaching the
shibboleth back-end and consequently avoiding the further
round-trip that IDP<--->SP perform after the replay attack
error. Its relatively easy to test if you have an NGINX/Apache in
front of your jetty instance.</p>
<p>I have no other possible/better work-around/solutions in mind at
the moment, ping me if you do :D <br>
</p>
<p>Best,<br>
Alessandro<br>
</p>
<p>** When Chrome has no tcp connection to the SP open, and the user
has no session on the SP, which will cause a redirect to the SP<br>
</p>
<blockquote type="cite"
cite="mid:DB7PR01MB4805A7F231E286A5FD412355B2FD0@DB7PR01MB4805.eurprd01.prod.exchangelabs.com">
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
dir="ltr">
<p style="margin-top:0;margin-bottom:0"><span style="font-size:
12pt;">
</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-size:
12pt;">Nick</span></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b> users
<a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.net"><users-bounces@shibboleth.net></a> on behalf of Feyaerts
Vincent <a class="moz-txt-link-rfc2396E" href="mailto:vincent.feyaerts@uantwerpen.be"><vincent.feyaerts@uantwerpen.be></a><br>
<b>Sent:</b> 26 September 2018 10:12:41<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:users@shibboleth.net">users@shibboleth.net</a><br>
<b>Subject:</b> Issues with Chrome "prefetching" our IdP pages</font>
<div> </div>
</div>
<meta content="text/html; charset=Windows-1252">
<meta name="x_Generator" content="Microsoft Word 15 (filtered
medium)">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif}
a:x_link, span.x_MsoHyperlink
{color:#0563C1;
text-decoration:underline}
a:x_visited, span.x_MsoHyperlinkFollowed
{color:#954F72;
text-decoration:underline}
span.x_EmailStyle17
{font-family:"Calibri",sans-serif;
color:windowtext}
.x_MsoChpDefault
{font-family:"Calibri",sans-serif}
@page WordSection1
{margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.x_WordSection1
{}
-->
</style>
<div link="#0563C1" vlink="#954F72" lang="NL-BE">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span lang="EN-US">Hi,</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">We have a set-up
consisting of ADFS+Shibboleth 3 IdP. ADFS is the slave SP.
Both are load balanced behind a Big-IP F5 LTM. Our problem
is not really related to this set-up. I think it might
occur in any normal IdP deployment.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">The Shibboleth IdP
back-end logs are full of messages like:</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><i><span lang="EN-US">org.opensaml.messaging.handler.MessageHandlerException:
Rejecting replayed message ID
'id-f7e02f5c-843f-4d3d-88af-168b8a79653e' from issuer
<a class="moz-txt-link-freetext" href="http://url/adfs/services/trust">http://url/adfs/services/trust</a></span></i></p>
<p class="x_MsoNormal"><i><span lang="EN-US"> at
org.opensaml.saml.common.binding.security.impl.MessageReplaySecurityHandler.doInvoke(MessageReplaySecurityHandler.java:157)</span></i></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">I checked our logs
of the load balancer, the client does indeed request the
URL with the SAMLRequest referencing that ID twice. Now,
it appears one of those requests has a header “Purpose
prefetch”. This is a Google Chrome header. Now, I have no
idea why it would prefetch these pages but it does.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">Technically speaking
this might be a Chrome problem, but it interferes with a
normal Shibboleth IdP from working, and I hope somebody
else has found a way to fix this on the IdP, because I
can’t change Chrome.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">I tried sending a
403 as a response to the Prefetch request, but then Chrome
just stops and won’t ask again.</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US">Regards</span></p>
<p class="x_MsoNormal"><span lang="EN-US">Vincent Feyaerts</span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
<p class="x_MsoNormal"><span lang="EN-US"> </span></p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
</body>
</html>