- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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/
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can you please share the detailed steps to reproduce the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will do that, thank you. Stay tuned...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can you please provide an update or logs when the server crashes.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!