Online Website Scans Crash HTTPS Server (SDK 6.4 on CYW943907AEVAL1F)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

There is a vulnerability of the HTTPS server where it can be crashed by commercial online website vulnerability scanners.  The setup is:

- snip.HTTPS running on a  CYW943907AEVAL1F eval board (SDK 6.4)

- port 443 opened up on router to Internet

- using URL redirection service (free at noip.com) to redirect an URL to the port (this URL is entered into the websites, below).

Running concurrent scans from the following online scanners can crash the server (non-responsive):

https://www.ssllabs.com/ssltest/

https://observatory.mozilla.org/

https://app.webinspector.com/

https://quttera.com/

The problem is exacerbated when I use Firefox to fetch the top page from the server and click it in quick succession while those tests are going on.

0 Likes
1 Solution

I think I will close this case because it has been difficult to pinpoint the exact failure.  While running a "hammer test" on my application (including multiple instances of this: Re: SDK6.2 Breaks TLS Compared to SDK6.0 (CYW943907AEVAL1F) ), I do not see the failure (note: I have included this workaround:  "ssl_receive_packet" in file "wiced_tls.c" hangs CPU (SDK 6.4 on CYW943907AEVAL1F)  ).

Now, given enough loading, I do see the CPU crawl to a near halt.  But, when the load lets up, it does recover.

If I uncover anything more definitive, I will open up a new case.

Thank you very much for your interest and in following up!

View solution in original post

0 Likes
9 Replies
KotnaniK_71
Employee
Employee
50 likes received 25 likes received 10 likes received

Hi,

Can you please share the detailed steps to reproduce the issue.

0 Likes

Sure!  Here is what I did:

1) Get HTTPS server running.

2) Kick off the four online scanners and have them "scan" the WICED server (port 443).

3) Start Firefox and do several quick page reloads.

It may not happen right away, but you will know when the server crashes.  It is quite insidious because it doesn't reboot (which actually may be preferable) -- it just stops responding on port 443.

0 Likes

Hi Charles,

Sorry for the delay in getting back to this.

In the four online scanners, Can you please let me know if you're providing the http server IP address or assigned any public domain for the https server.

Thanks.

0 Likes

No problem with the delay.  I am creating a public IP address at no-ip.com.  I used it to redirect the URL to the WICED device IP.  Now, if you're behind a corporate firewall, it may not be possible to do.   Hmm.

0 Likes

Hi Charles,

I have tested by using above steps and unable to reproduce the issue.

Can you please try to run in debug mode and provide us the logs or screenshots when the server crashes.

Thanks.

0 Likes

I will do that, thank you.  Stay tuned...

0 Likes

Hi,

Can you please provide an update or logs when the server crashes.

Thanks.

0 Likes

I apologize for the delay as efforts have been spent on enterprise Wi-Fi.  Thank you very much for the follow-up.  I should be able to get to that in the next day or two. 

0 Likes

I think I will close this case because it has been difficult to pinpoint the exact failure.  While running a "hammer test" on my application (including multiple instances of this: Re: SDK6.2 Breaks TLS Compared to SDK6.0 (CYW943907AEVAL1F) ), I do not see the failure (note: I have included this workaround:  "ssl_receive_packet" in file "wiced_tls.c" hangs CPU (SDK 6.4 on CYW943907AEVAL1F)  ).

Now, given enough loading, I do see the CPU crawl to a near halt.  But, when the load lets up, it does recover.

If I uncover anything more definitive, I will open up a new case.

Thank you very much for your interest and in following up!

0 Likes