Hi there,
I’m having the same login issues as detailed in this thread and this thread. I’ve taken some steps to debug the problem myself which I hope are helpful as it seems others have also encountered this behaviour. The rest of this post is technical mumbo-jumbo.
My username and password are definitely correct. They are provided by the same password manager I use to log in at syrinscape.com and I have compared the values explicitly.
The error I receive is “From callback, Error getting response stream (Write: The authentication or decryption has failed.): SendFailure”. The content of that error with “From callback” removed is an error others have encountered verbatim in C#/Mono contexts and in Unity projects: https://forum.unity.com/threads/error-getting-response-stream-write-the-authentication-or-decryption-has-failed-sendfailure.466707/
If I use Wireshark to watch traffic, I see the start of a TLSv1 handshake between my client (presumably the Creator server) and syrinscape.com in which my client rejects the handshake because the certificate is invalid. It receives a certificate in which subject=/CN=* and issuer=/CN=* instead of the legitimate syrinscape.com certificate.
I observe this same behaviour if I connect to the server directly using openssl without an SNI extension:
openssl s_client -connect syrinscape.com:443 -tls1_2
The certificate syrinscape.com is providing under these conditions is the same one found by default for some letsencrypt configs as located here:
https://github.com/ixc/letsencrypt-docker/blob/master/docker-compose.yml
https://github.com/ixc/letsencrypt-docker/blob/master/docker-cloud.yml
I observe the correct behaviour if I add an SNI extension in OpenSSL, as in:
openssl s_client -connect syrinscape.com:443 -tls1_2 -servername syrinscape.com
Looking back at the packet capture for the original exchange, the one triggered by the Syrinscape Creator software, I can see that Syrinscape (or its underlying HTTP framework) didn’t send an SNI extension in its ‘Client Hello’ TLS handshake. The OpenSSL behaviour suggests that the site totally fails to work without an SNI extension. This can be confirmed using the standard SSLLabs toolset and opening the panel labelled Certificate #2: RSA 2048 bits (SHA1withRSA) No SNI: https://www.ssllabs.com/ssltest/analyze.html?d=syrinscape.com&s=54.191.105.217&hideResults=on&latest
It’s strange, then, that the application typically works for everyone and has only broken down in these isolated cases. Figuring out exactly why this occuring requires more information about the context these requests are being sent from, but hopefully that’s a good starting point.
