Let's see if this picture, along with an explanation, helps.
View attachment 739
Step 1, the attacker grabs a SQRL authentication challenge from a site. It can't make up its own because there is a unique identifier embedded in it which the server MUST have in its own memory for an authentication to succeed. (The design actually includes an option to lock the challenge to the IP address of the requestor, but that won't work in a mobile phone authorizing for a desktop computer, so mobile phones need to request disablement of this feature.)
Step 2, the attacker some how, in real time, forwards this challenge to the user. The challenge is time sensitive, so email is probably not a good way to deliver it, but they may use email to lure in the victim before starting a real time attempt.
Step 3, the client decodes the challenge, and gets the site hostname that it originated from. Part of the SQRL protocol requires this, because the generation of the correct site key is based on the hostname. If the attacker messed with that, then they could potentially try and authenticate the user to a look-a-like site, say amazu
ne but then a unique key would be generated for amazu
ne.com and would not be valid at the correct site.
When starting step 3 the client opens a DIRECT TLS connection to the hostname from the challenge. If it's a stolen challenge from a valid site, and the user proceeds with it, then they will, using the same back channel, get the response back (step 4) from the valid site with an authorization cookie. The attacker can't see this because they're not in the path. (There are possible scenarios where an attacker might try and get in the middle of the conversation, but that would be much harder, involving either DNS poisoning or maybe malware on the users PC. SQRL does not claim to be secure if the user has malware, as nothing really can legitimately make this claim.)
Step 5, the client has the cookie it needs, it now launches directly to the correct site, again using the correct hostname it received along with the cookie, again totally bypassing any attacker in the middle.