Azure Static Hosting: Error code: SSL_ERROR_RX_RECORD_TOO_LONG

LAUWER 40

Hosting a simple create-react-app on Azure Static Web App (free plan).

Using default auto-generated name and certificates (no custom domain, no custom certificates, all generated by Azure).

App works for a few minutes then immediately gets SSL error (browser refuses to go to site)

Secure Connection Failed

An error occurred during a connection to my-generated-name-someguid.5.azurestaticapps.net. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

I have another similar app that I deployed some days ago (and redeployed countless times) which always works.

Any ideas?

TP 94,311 Reputation points

2024-03-18T04:57:09.79+00:00

Hi,

What happens if, after it stops working, you open up the site in a fresh browser profile (e.g. Guest)? Does it work again for a few minutes and then fail? To browse using Guest profile, in Chrome, click on person icon in upper right and then click Guest under Other profiles.

Have you tried deleting the static web app and re-creating it again? Based on your description it doesn't seem like you did anything wrong, since the service handles the certificates and related configuration automatically.

-TP
LAUWER 40 Reputation points

2024-03-18T13:12:58.8433333+00:00

Thanks for the answer.

More info:

·        Was able to directly access it with no issue when connecting via my mobile connection (instead of home network) both on device and on desktop connected via wifi.

·        I sent the link via email to outlook, which changed the link to the expected na1.safelink.protection..... wrapper, which then sends me to a "Outlook has detected an unsafe link." proceed at your own risk page. The other create-react-app I have published on another azure static web app service does not trigger the filter (note the apps are identical in structure, script content, service-worker, etc - content is slightly different.) npm audit yields 0 vulnerabilities in dependency tree.

·        I tried to run SSL Server Test with Qualys SSL Labs, A security rating, handshakes on compatible browsers all successful, 200 OK http request.

Maybe the site was automatically flagged as sketchy (for which reason, I can't imagine)?

I suspect my ISP/ISP provided router/Modem has some built in protection getting triggered by perhaps the same issue outlook safelink is jumping in with warning screen.

Tried redeploying to other web service, same issue (again, all good at first, but becomes problematic within minutes of being live).

Will try the following actions:

·        Will push an update that replaces deployment with a single hello world index.html (and nothing else, no react, no js, no resources, just a single html document). - could help answer if the address itself is flagged/problematic.

·        Will push the working app to the second not working deployment, again clearing out any trace of the problematic deployment. - again to see if I can narrow it down to the app (but this time, a much closer match, one react app for another with almost identical architecture and content).

·        Will check addresses periodically over the following 24-48hrs for the issue from multiple sources. (Since the address itself might be flagged, maybe

waiting for propagation of new deployment could change thing?)

·        Will try yet another app service, but this time just publish that single html page to see if any similar issues occur. If all good for 24-48hrs, will give another go at the problematic app.

·        Will thoroughly scan and rescan problem react app for any issues I might have missed, any big diffs from the working react app.
LAUWER 40 Reputation points

2024-03-18T14:16:46.45+00:00
Short followup.

Created new repo.

Spawned new static web app service. Fully managed by Azure (generated name/url + generated managed certificates).

HTML5 template for CI generated entirely by Azure (did not modify it).

Publishing went through perfectly (in like a second because no node, just pull and upload (no minify, nothing fancy at all).

Site is basically a folder /hello_world + single index.html file with just hello world stuff:

<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="utf-8" />

<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />

<meta

name="Hello"

content="Hello World" />

<title>Hello World</title>

</head>

<body>

<noscript>You need to enable JavaScript to run this app.</noscript>

<div id="root">

<h1>Hello World</h1>

<p>CAN'T GET ANY SIMPLER THAN THIS</p>

</div>

</body>

</html>

Worked fine for a few minutes.

Now getting same browser generated Error code: SSL_ERROR_RX_RECORD_TOO_LONG on home network. Still working on mobile network.

Outlook flagging as potentially malicious when link sent to an @outlook.com email address. And this is minutes after deploying.

Pretty much 100% eliminated (ok, 99.999%) the following possibilities:

The app itself since it's a single static html page with no media, no scripts, no styling, no links, no content except some hard coded strings. How can a single markup file do anything malicous (no frames, no links, no refs to anything, literally just the markup included in this comment).

The repo is brand new, has nothing in it except a blank readme (at root), the hello_world folder, and a single index.html file containing the markup in this comment (might as well be empty).

Malicious code introduced via dependencies or inadvertent malicious patterns in scripts (no scripts whatsoever, no node, no builld process).

Malicious code introducing itself in deployment process (everything is 100% managed by Microsoft (GitHub actions + Azure generated yaml with literally no fancy stuff, just pull from repo + upload to server) - I upload nothing via my workstation).

Messing about with certificates or settings (although, this was already eliminated), Azure FULLY manages the entirety of this process, from url generation to certificate and backend management.

Remaining possibilities:

Maybe it's a problem with 5.azurestaticapps.net domain?

Unlikely to be the certificate itself since it seems to work fine on mobile network and that SSL Test suite rates it A and passes everything when performing battery of handshake and cryptography tests.

Noticed my working app, service created months ago, is generated-name-and-guid.4.azurestaticapps.net (instead of 5.).

This working 4. app is NOT flagged by outlook link protection, ever. Also never experiences any ssl related errors/security issue browser flags.

Will keep thinking about this, might have missed some potential possibilities.

OTHER FOLLOW UP (QUICK I PROMISE)

Went in my ISP provided router app settings, it's considering the url as a phishing scam (anything from 5.azurestatic... Maybe too many hackers used this service to fish and now most ISPs, network management apps and even the outlook link protector considers the domain malicious!??
TP 94,311 Reputation points

2024-03-18T14:28:26.0833333+00:00

Hi, thanks for all the detailed info.

I need to read through more carefully, but based on my understanding so far it seems like something with your ISP firewall/router/modem.

I've not seen the specific issue you are having, but I've definitely had a variety of issues with clients that have ISP-provided security firewall/router/modem/wifi devices. Does yours have any integration with your computer?

For example, some sort of security software installed, certificate from firewall installed in trusted certification authorities store? If yes this would allow the local ISP firewall/router to do TLS inspection. This is only one possibility.

A suggestion I have is for you to login to your local ISP device and see if you can disable any advanced security scanning/blocking options it may have. Basically, your goal would be for it to be a plain NAT router with no other "fancy" security capabilities enabled. Then test to see if the issue is resolved.
LAUWER 40 Reputation points

2024-03-18T15:43:25.3266667+00:00

OK, so I can temporarily enabled access to site in my router settings, but it still seems like anything at 5.azurestaticapps.net is getting auto-flagged by router, ISP, and even Outlook na01.safelinks.protection link wrapping service (simple react app, more fleshed out react app, and simplest possible static hello world html page with no scripts, resources, links, or even styling).

Directly accessing url via my wireless service does not trigger the error. When connect to home network/wifi, it shows the ssl error. I'm guessing the router is doing something that messes with certificates.

Router does list all sites from antyhing.5.azurestaticapps.net as Phishing/scam sites (even that single html Hello World page). And since the "anything" part of the url is only minutes old, I doubt it's specific to each of the apps but rather the domain itself. Probably narrowed to subdomain for some reason, given the 4.azurestaticapps.net is never flagged by anything (not by outlook safelinks, not by ISP, not by router).

Will try emailing myself a fake/non-existent .5.azurestaticapps.net site to see if outlook flags that (although it might detect it's not resolvable and skip flagging it? let's find out!).

Interesting discovery:

/e Yea, so, as I suspected -> sent myself a fake/non-existent url at .5.azurestaticapps.net and outlook safelinks indeed flags it as suspicious/malicious (a web app/site that literally does not exist + never existed + I just made it up)!

One more note about this last bit, I can send other links from same address to same address and outlook does not flag any of them, just the 5.azurestaticapps.net links.
TP 94,311 Reputation points

2024-03-18T20:11:47.4933333+00:00

Does it behave the same way if you leave the static site with default home page? By default home page I mean the one that is there before you have deployed any content to the site. I'm guessing it will since you created fake site and it flagged that.

I just created static site on *.5.azurestaticapps.net with default home page and it is working from my PC. Haven't tested safelinks yet.

UPDATE: I sent two test messages from an outside email account to M365 mailbox. One contained link to *.5.azurestaticapps.net site, the other to *.3.azurestaticapps.net site, both sites are default SWA home page. The *.5 message was quarantined with High Confidence Phish, and the *.3 message was delivered without issue.
LAUWER 40 Reputation points

2024-03-19T12:50:13.77+00:00

Haven't tried the default page created. Closest thing I did try was that completely benign/content-less single index.html "site". And of course that fake link.

Interesting to hear that the *.5 is also getting quarantined on your end. And not the *.3. Considering my .4 is also not tripping phishing alarms, it supports the theory *5.azurestaticapps.net is potentially blacklisted at one level or another and potentially many considering how my home network and/or ISP is treating that specific subdomain.

Will look into spawning a service on another staticwebapps.net subdomain (if that's even possible since they are not region specific deployments but global). Else it should resolve itself when I register and link a custom domain to the service (hopefully, otherwise it will be a pretty major deal breaker!)
ajkuma 26,136 Reputation points Microsoft Employee

2024-03-21T12:14:15.3933333+00:00

Thanks for the follow-up and update. If the answer provided by TP helped (pointed, you in the right direction), we could summarize the answer provided, and then we request you click Accept Answer - it will help users to find the answers quickly: the question author cannot accept their own answer. They can only accept answers by others.
Or if you need fruther assistance, please let us know, we will be happy to help.
LAUWER 40 Reputation points

2024-03-21T22:12:43.2233333+00:00

So, just to be clear, the answer is:

"URLs generated by Azure Static App Service with 5.* are auto-blacklisted by Microsoft and at least some (likely many) other services and ISPs and there's nothing a user can do to resolve this on their own without resorting to custom domains or hoping for another integer prefix than 5?" Any chance this issue will be resolved and 5.* will stop being assigned and/or be removed from blacklists (although the latter seems risky since they ended up there for a reason).

Can definitely Accept Answer once it's posted, no problem there!

Thanks for your help TP! Much appreciated!

Accepted answer

TP 94,311 Reputation points

2024-03-21T23:20:43.9066667+00:00

@LAUWER I like your idea in regards to using custom domain, however, I'm concerned that M365 anti-spam engine will see that it resolves to the *.5 and quarantine it anyway. I've not tested it, so maybe it will work fine.

In terms of a solution, I was thinking you could open an Azure support request under Static Web Apps (SWA) service and put pressure on them to investigate internally with M365 team. Similarly, you could open support request on M365 side as well, inquiring why a new Static Web App is being quarantined when it has no prior history of being a phishing site (or even existing for that matter).

Making progress with the support case(s) will likely take some patience as I would guess at the lower levels they will potentially want to shift blame and say their service is operating fine so there is nothing they can do. This is where polite pushback will hopefully get them to escalate further.

One question for them is, Are they okay with a large swath of SWA FQDNs being "blacklisted" by default, by their own malware detection mechanism?

On separate note is what is happening with your local ISP firewall/modem/router device. I don't know what is going on with that, if it is looking to some sort of shared blacklist database, or what? And if it is, why is it causing strange error instead of simply blocking the connection to the site altogether? I think this might require taking in-depth look at the specific hardware device and its configuration options, and local packet capture and analysis.

Maybe updating the ISP firewall/modem to latest firmware will magically "fix" the SSL_ERROR_RX_RECORD_TOO_LONG error. Worth a try.

If the above is an acceptable "Answer" to you I will convert it to answer so you can accept it, otherwise if it isn't acceptable (I understand if that is how you feel) I will leave it as a comment. Maybe someone else can chime in here and give new/better insight.

Thanks for reading this far.
Please sign in to rate this answer.

1 person found this answer helpful.
LAUWER 40 Reputation points

2024-03-22T13:12:21.56+00:00

~~I will try to open a support ticket with Azure, but posting on Answers is the closest I came to being able to do that.~~

~~Was checking up on another static app I've had hosted on Azure for years now (slightly different address, no .#.* prefix, with a custom domain hosted externally. Some observations:~~

Different certificate altogether, not even provided by Microsoft but rather DigiCert (now it's been AWHILE and my old self was less rigorous about documentation, so I can't confirm whether this was generated automatically or not).

The Azure hosting seems completely opaque in that I saw now requests or anything of the sort to .azurestatic.... when perusing network traffic on the custom domain via the custom domain url.

Anyways, will probably try out with Azure + custom domain, and if I have any problems whatsoever, it's a rather simple process to switch to a less... "blacklisted?" provider? At this stage every major provider offers competitively priced static hosting (free to dirt cheap) and easy to use GitHub action hooks and domain configs.

~~As much as I may not like the answer, it certainly seems like the correct one! Thanks again for your help with all this~~ @TP.

/e Rewrote this because it wasn't posting (probable moderation delay!) can ignore this response!

LAUWER 40 Reputation points

2024-03-22T14:19:55.1+00:00

Considering it blocks anything (including non-existent sites that cannot possibly be malicious) I suspect it's a string matching based approach where anything that contains .5.azurestaticapps.net gets blocked.

I think custom domains trigger certificate generations of their own (I have another, albeit older, app deployed on azure static app services with a custom domain, and there are two distinct certificates from different authorities for each - visiting site via azurestaticapps url sends one cert, visiting it via custom domain serves other). Can't remember if I took specific action for this to happen or if it's just default behaviour (this was awhile ago and portal has changed a lot since then).

I may not like the answer, but it's definitely valid and you confirmed all my suspicions and helped greatly at tracking down actual problem(s)! Will gladly mark your comment as answered when you "upgrade" it!

Thanks x1000 TP for all your help, it's beyond appreciated!

PS: Will try to open a support ticket but last I tried this message board/Answers was the closest I came (may not even be possible without a proper support subscription?)

TP 94,311 Reputation points

2024-03-22T16:22:45.75+00:00

Okay, I just tested by assigning custom domain to the *.5 static app that was quarantined previously, and the email message made it through. Even though this is a positive sign I wouldn't take it as 100% guarantee that using custom domain will solve it.

You are correct, when you assign custom domain a new certificate is issued by intermediate cert under DigiCert Global Root CA with matching subject. What I was concerned about above is the scanning algorithm would see that the CNAME record points to *.5 and based on that still block.

In regards to Azure support request, to create Technical support request you need at least Developer level paid support plan. At least Standard if you want faster response and ability to speak to someone on the phone.

Please note the process to create a support request is confusing and will lead you to think that only thing you can do is see various "Recommended solutions", read articles, etc., instead of actually creating a case. This is true even if you have paid plan.

To cut through the confusion look for Return to support request in upper left and click on it when you see it.

Please click Accept Answer and upvote on my answer above.

Thank you.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Azure Static Hosting: Error code: SSL_ERROR_RX_RECORD_TOO_LONG

0 additional answers

Your answer