getting handshake_failure when trying to play a mp3 from a URL

Question

question

Michael Milawski asked Jul 21, '22

getting handshake_failure when trying to play a mp3 from a URL

Hi,

I am trying to play a mp3 file from a URL. It works on some servers but fails on others... Here is a simple request:

{
    "body": {
        "version": "1.0",
        "response": {
            "outputSpeech": {
                "type": "SSML",
                "playBehavior": "REPLACE_ALL",
                "ssml": "<speak><audio src='https://62d85c44c72a1f0521f09205--wondrous-cat-a778d9.netlify.app/audio/czesiek/00_cz_razem_wracamy.mp3' /></speak>"
            },
            "shouldEndSession": true,
            "type": "_DEFAULT_RESPONSE"
        }
    }
}

I get the following error:

        "error": {
            "type": "INVALID_RESPONSE",
            "message": "Received fatal alert: handshake_failure for requestId amzn1.echo-api.request.XXXXXXXXXXXXXXXXXXXXX"
        }

And Alexa says "I can't connect to the URI of the audio file". (or something like that, I translated it from German)

what am I doing wrong? I assume with "handshake" amazon means ssl handshake? Whats wrong with the provided url? I tried it with a letsencrypt and now I try it on netlify (see url above).

Any hints? whats wrong with the provided url / ssl?

Thanks

alexa audioplayer

10 |5000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2022-07-21T16:07:18Z

KirkC@Amazon answered Jul 21, '22

I investigated the https certificate of the domain hosting the mp3 file in question using Nmap and found that it currently only supports a very narrow suite of ciphers:

nmap --script ssl-enum-ciphers -p 443 62d85c44c72a1f0521f09205--wondrous-cat-a778d9.netlify.app

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: client
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     cipher preference: server
|_ least strength: A

When two computers try to establish a secure connection, they must first attempt to find a common supported cipher with which to encrypt communications between them.

If two servers do not share a common supported encryption cipher, the https handshake fails and no connection can be established.

The solution to this would be to renew your https certificate but with a wider range of cipher support.

We're unable to provide specific steps on how to renew a server's certificate as steps can vary greatly depending upon the server software used. For further guidance I'd recommend reaching out to the authority which issued your https certificate, which appears to be Digicert in this case. Or, since Netlify appears to be a managed service and you may not actually manage the https certificates at all, you may instead reach out to Netlify themselves.

2

10 |5000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Michael Milawski · Jul 21 at 05:34 PM

thank you! Is there a list of ciphers or a recommended cipher that should be available in the ssl certification so alexa / amazon server can establish the handshake?

0 ·

KirkC@Amazon ♦♦ Michael Milawski · Jul 22 at 08:37 PM

We do not maintain a publicly facing list of supported HTTPS ciphers for Echo devices as they are subject to change without notice.

That having been said, as a test I took your "00_cz_razem_wracamy.mp3" file, uploaded it to my AWS S3 bucket, and launched my "SSML Test" skill to verify whether simply changing the hosting provider (thereby changing HTTPS certificates and supported ciphers) would resolve the issue. Here was my experience:

Me: Alexa, launch s. s. m. l. test
Alexa: <SSML audio plays without issue>

The conclusions reached here then were, first, confirmation that indeed the limited https cipher support of offered by Netlify was the root cause of the issue. Second, that simply by changing your hosting over to AWS S3, this issue would be fixed.

If you'd like to try hosting your MP3 files on S3 instead, I've provided some documentation here:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html

Lastly, out of curiosity I checked what TLS 1.2 ciphers were supported by my AWS S3 bucket, the results were as follows:

|   TLSv1.
|     cipher
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) -
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) -
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) -
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) -
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) -
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) -
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) -
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) -
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) -
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) -
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) -
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) -
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) -
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

You'll observe that several more ciphers were supported by AWS S3, and also that none of the three TLS 1.2 ciphers supported by Netlify were listed here. If you'd like to try to get Netlify to broaden their range of cipher support first before changing hosting providers, you may use this list as a reference.

1 ·

question