Looks like support for Secure Renegotiation has been introduced in wolfSSL embedded SSL Release 2.9.0 (2/07/2014).


Nice!

todd wrote:

That said, we do want to be compliant with the major implementations, both client and server.  And because of that, secure renegotiation is on our roadmap for the end of the year.

Any updates about secure renegotiation support?

I don't see anything in the changelog, I assume there has not been any development yet.



thanks
Lukas

AFAIK some servers even require the client to support renegotiation (use-cases with client certificates).

Anyway, I greatly appreciate your decision to support secure renegotiation. This will make yassl future proof.


Thank you!

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:

Mozilla BugID 554594 - link [4] wrote:

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.

Yngve Nysæter Pettersen (Opera's security group) - link [3] wrote:

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