AWS CloudFront conflict with Stape's SSL Cipher

Custom domain
1

Hey
We’re trying to implement a same-origin domain and proxy requests to a subdomain, which we created in Stape’s UI. But my DevOps says there’s a conflict preventing us from doing so. He shared some information with me. Please take a look.

# Validate mtrcs.hubmee.com Cipher
openssl s_client -connect mtrcs.hubmee.com:443

---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256

As a result, we are getting 502 (sometimes 503) errors when trying to send requests to the same-origin domain. This happens because CloudFront does not allow routing requests to the subdomain due to your SSL Cipher, which is not supported by AWS CloudFront.

here is the list of supported Ciphers by AWS CloudFront
and your’s SSL Cipher is not in this list.

What can we do in this case? Should we wait until you update your cipher (if you plan to do so)?
I would appreciate your response.

2

I think you can try to use own CDN aproach for sGTM subdomain. This way you will handle SSL certificate for sGTM the way you needed.
Here is more info about own CDN:

3

Could you please clarify, is this the only possible option? Does you advice mean that you do not want to change your SSL Cipher? I read the article
and the quote from it

  • [Recommended] The custom subdomain you’ve set up inside the stape.io admin. Using a custom subdomain when configuring a worker is recommended since it gives two benefits: loading gtm.js and gtag.js from a custom path using Custom Loader power-up, which makes tracking scripts unblockable and allows the setting of long-lived first-party cookies. If you use a custom subdomain for your same origin tagging server URL, ensure you’ve added a custom domain to your sGTM container on stape and created DNS records as described here. Do not use Own CDN with the same origin domain.

You explicitly say not to use the Own CDN option in the last sentence. So what do we do if we need to both load gtm.js & gtag.js via custom loader, and set the fist-party cookies?

4

Loading js via custom loader has nothing to do with own CDN / same origin approach. You can use this in any variation you want.

Own CDN allows you to achieve all the same things as with the same origin. It’s just another variation of the approach to circumventing ITP restrictions.
Since you are securing SSL with your own CDN, you can do it the way you want. From a cookie prolongation point of view it will be the same as the same origin approach.

5

I added to backlog to add capability with CloudFront.
We changed our SSL version and Cipher because of compliance with some security certificates.

I am sure this worked before. Like 2 years ago :slight_smile:

6

Hello. Thank you for your reply.
Can you please tell me if you have an approximate timeline of when you plan to do this? I’m well aware it’s a low Prior, but still. We are really looking forward to it, because as I understood devops, we can’t use own CDN option.
And the cipher thing is blocking all further implementation.

7

Team said that 2 weeks needed.
But I think it will be in one month :slight_smile:

1 Like