Topic: [SOLVED] Follow up on "Secure Renegotiation"
Hi,
this about RFC5746 "Secure Renegotiation".
As per your manual [1] and public announcements [2], (C)yaSSL doesn't implement renegotiation at all. Support for RFC5746 (aka "secure renegotiation") is thus not included as well (your manual contains a typo: RFC4756 has nothing to do with this).
Browsers however can't differentiate between vulnerable servers and servers without renegotiation at all. Major browser vendors have implemented warnings when connecting to non-RFC5746-aware servers. As of today, those warnings are mostly "silent", with Firefox for example logging this only to the error log. However, multiple browser vendors plan to show active and disturbing warnings because of this in future.
Please see:
If the server does not implement RFC 5746, the client is unable to tell whether you're vulnerable or not, and you will get the warning.
Disabling server-side renegotiation was a quick & dirty, and very temporary, workaround deployed while there was no other, and more secure options available, in order to mitigate the discovered problem. It was never meant to be a permanent solution, nor does it provide any real security.
It seems the renegotiation attack can also be launched against the client (please see the link [3]). So if we have a HTTPS server based on (C)yaSSL, we will have some problems because of this. Security related? Probably yes. Disturbing because of big bad warnings in the browser? For sure!.
Please see the above links [3], [4], [5] and [6]. We can clearly see from the statements at wiki.mozilla.org, that it's only a matter of time for an active and visible warning for the user to come.
The haproxy project recently announced [7] they would like to implement wolfSSL in their product, because of its performance and memory consumption benefits. If this becomes reality, that would mean that a number of large websites would probably adopt wolfSSL for HTTPS services. Haproxy will support both openssl and wolfSSL [8], so if wolfSSL causes big and scaring warning banners on the browser, a broad adoption will probably not happen.
So my actual question here is: Whats the opinion of your team about this?
I understand your argumentation (in the manual) very well, but given the above feedback from browser vendors and what they will do in future, will you stick to this? I am not interested in discussing the technical details here (in fact, I do not have enough knowledge to discuss this), but I would like to know what you folks at yassl think about this, given that browser vendors will "flip the switch" sooner or later, and then we find ourselfs "pants down", monday morning, after a major firefox update, with our managers yelling at us "why did you use yassl instead of openssl?".
The whole question may has other aspects on embedded devices, but you probably want to consider the content delivery industry and their point of view.
The forum only allows 3 links per post, so I had to break the http links.
[1] h**p://yassl.com/yaSSL/Docs-cyassl-manual-9-library-design.html
[2] h**p://www.yassl.com/forums/topic40-no-renegotiation-vulnerabilities.html
[3] h**p://my.opera.com/yngve/blog/2010/11/04/temporary-workarounds-are-well-temporary
[4] h**ps://bugzilla.mozilla.org/show_bug.cgi?id=554594#c8
[5] h**ps://wiki.mozilla.org/Security:Renegotiation#security.ssl.treat_unsafe_negotiation_as_broken
[6] h**ps://wiki.mozilla.org/Security:Renegotiation#security.ssl.require_safe_negotiation
[7] h**p://www.mail-archive.com/haproxy@formilux.org/msg07781.html
[8] h**p://www.mail-archive.com/haproxy@formilux.org/msg07802.html