This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Top Replies

  • The specific change you mention was a result of a security review we carried out on the OTP functionality. It is not good practice to provide methods to recover existing secrets because this makes it much easier to create cloned tokens that could be used without the knowledge of the original user to gain access to their account. Recovering OTP on an account by deleting the existing secret and creating a new one is more secure because even if it is done by the wrong person, the original user will realize the error the next time they try and log in using their old token.

    You see the same behaviour in most websites that offer OTP options like this - the only way to recover if you lose your OTP is to re-initialize with a new secret.

    Your point about including more specifics about this in the release notes is valid. We try to keep the release notes brief so that customers can read them all quickly and identify areas that may concern them where they can dig in to documentation to find out more. Sometimes we make them too brief. We'll take your feedback into account.

    [I updated my original post because I mistakenly thought I was reading the v19 EAP1 forum. Apologies for any confusion.]

    Jump to answer
Parents
  • SS/TLS engine errors

    As well one site has been classified as parked yet carries traffic and has done so in the past. If I use my phone hotspot the data downloads correctly.

    Ian

    XG115W - v19.5.1 mr-1 - Home

    If a post solves your question please use the 'Verify Answer' button.

  • Getting occasional errors like this is not unexpected and is certainly not new to MR2. Most occurrences of errors like these are intermittent and go unnoticed and the browser or other app just reconnects and gets on with things. Occasionally they may happen consistently for certain hosts, causing noticeable problems, which is why we include them in the logs.

    Flow timeout usually means the server stops responding to us before the handshake is complete. This happens from time to time depending on the client and server app. For example, if a server is under heavy load it might complete the TLS handshake but not be able to service the HTTP request within the TLS tunnel.

    Session Unknown can happen when a device tries to establish a TLS connection using a session ID that was previously unseen by the Firewall - maybe the device moved networks, or the TLS decryption rules changed, or the Firewall was restarted, or the session ID was just very old and had aged out of the Firewall's session cache. Typically these occurrences don't cause significant actual problems - apps generally retry the connections. This is just a standard part of the TLS protocol - even if we weren't in the path doing decryption, the server may lose track of a session ID and tell the client to reconnect.

  • Thank you for the detailed explanation. I would expect that Sophos has some way of measuring the error messages on their servers, because most of the error I see are from Sophos update servers a number of times a day.

    Ian

    XG115W - v19.5.1 mr-1 - Home

    If a post solves your question please use the 'Verify Answer' button.

  • Agreed. It's not super-common, but I see such errors regularly for Intercept X updates from Sophos servers. It may happen with other servers, but I don't remember seeing it. I guess it stands out in my mind because I'm worried that some piece of Intercept X might not be updated when it was supposed to be.

Reply
  • Agreed. It's not super-common, but I see such errors regularly for Intercept X updates from Sophos servers. It may happen with other servers, but I don't remember seeing it. I guess it stands out in my mind because I'm worried that some piece of Intercept X might not be updated when it was supposed to be.

Children
No Data