Do you think your router is sniffing the user agent (UA) of Firefox? Install add-on https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/ and add the UA of FF9 in UA Switcher that's Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20100101 Firefox/9.0 then try to connect to your router by acception the certificate.

Thanks for the quick reply. I added this and set the agent - same issue.

I can go in and delete the certificate (running FF10), access the url and get the warning that the certificate is an issue, then import it then get the connection reset. I am not really sure how this UA works, but if that was an issue, I would think I would get the reset all the time, even before I imported the certificate.

Good idea though. Thanks

Okay, so UA sniffing is not the issue here. Did you ask Cisco support forum too? Maybe other users have reported the same issue.

No, have not gone there yet because this worked fine with Firefox 9. I tend to believe it is something in Firefox 10. I am not stating that the certificate is fine, but if I can finally reach the router with 9, then why can I not with 10?

There are many posts regarding the invalid usage of certificates in Linksys products.

By the way, if I enable http (not https) FF10 has no issue reaching the router.

Does it require HTTPS, can you access it with HTTP?

What I think happened was the following:

There was a security protocol change that was introduced in Firefox 10 (as well as in Chrome 18 and in IE9 with the latest security patch from Microsoft) to address a particular vulnerability. Some poorly coded sites/pages are taking a shortcut when interpreting the secured data stream and now that the format has changed they don't handle the change gracefully and bail on the connection.

As for options, you can see if the router will accept non-HTTPs connections which should be fine or you can try to contact Cisco to make a firmware update to support this new protocol.

@cww:

Are there any docs about this change?

I've seen another post about a connection reset error that also affected Google Chrome.

• [/questions/918028]

(removed link to this thread)

The attack is called BEAST and allows the attacker to access cookies on your machine (and thus be able to impersonate you online). The fix is to do something called 1/n-1 record splitting. I don't have a good general documentation on what that means (not that it much matters) but bug 702111 is the bug for servers that don't handle it well.

In the bug, the following details:

I'd appreciate a hint what must be changed in an OpenSSL-based https server to make it compliant with NSS 3.13.1.

You must make your application code smarter.

Whenever your application attempts to read application (data) bytes from the SSL socket, you must be prepared to receive the data in multiple chunks.

Your current code is probably like this:

• read from socket
• you see one byte
• you try to process the one byte according to your inner protocol
• your code decides that one byte isn't a valid protocol command, and you abort the connection because of a failure

You must change your code to continue to read from the socket, and concatenate the received bytes, until you are able to process the data according to your protocol.

Thanks cww.
Comment 60 in that 702111 bug report has a workaround (environment variable), but be aware that using it makes you vulnerable to that BEAST (Browser Exploit Against SSL/TLS) attack.

See also:

• http://www.net-security.org/secworld.php?id=11693 Browser companies react to BEAST attack
• Bug 665814 – Rizzo/Duong chosen plaintext attack (BEAST) on SSL/TLS 1.0 (facilitated by websockets -76)

I do have access via http - but I did not want to enable that if I did not need to.

Probably not a Microsoft patch because IE 9 has no problem getting to the https link - yes it warns me exactly as I would have expected. I would have likes FF to also warn me versus presenting me a "Connect was reset".

I had read about the TLS issue and the issue of using the latest versions also.

http://support.microsoft.com/kb/2643584 is the microsoft security bulletin for this. I'm not 100% sure they shipped it to everyone or made it a required patch.

I searched and it appears you are correct - that patch is not my machine.