cancel
Showing results for 
Search instead for 
Did you mean: 

Wi-Fi Combo

ChMa_3922746
Contributor II

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
ChMa_3922746
Contributor II

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

Hi,

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

0 Likes
ChMa_3922746
Contributor II

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
KotnaniK_71
Employee

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
ChMa_3922746
Contributor II

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
KotnaniK_71
Employee

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
ChMa_3922746
Contributor II

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

0 Likes
KotnaniK_71
Employee

Hi,

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

Thanks.

0 Likes
ChMa_3922746
Contributor II

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
ChMa_3922746
Contributor II

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