1 (edited by lukas 2012-09-16 15:26:51)

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:

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

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

Everything you note seems correct.  If I was a browser though I would disallow renegotiation completely unless it was secure.  Seems pretty simple.  Same on the server.

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.

Thanks for the informative post and links.  We'll post back when it's done or if we have other ideas.

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

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!

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

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

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

Hi Lukas,

We haven't found time yet to add support for secure renegotiation, but it's still on our list.

Best Regards,
Chris

Re: [SOLVED] Follow up on "Secure Renegotiation"

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


Nice!

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

Is there any further information on secure renegotiation?  e.g., is it on by default or do you need to do something to include / enable (or disable) it?  Does (or can) the application need to do something to trigger it, e.g., after so many bytes or time, etc.?  Or does the library handle it transparently?

Share

Re: [SOLVED] Follow up on "Secure Renegotiation"

Hi Brian,

We have not yet added support for secure renegotiation to wolfSSL embedded SSL.

Best Regards,
Chris

Re: [SOLVED] Follow up on "Secure Renegotiation"

Reviewing old blog posts and came across this. For completeness sake secure renegotiation was added for client side in release 3.3.0 (wolfSSL is now on stable release 3.9.10)

https://wolfssl.com/wolfSSL/Blog/Entrie … 3.3.0.html

NOTE: This is not secure despite the name "Secure Renegotiation" it is prone to MIM attacks.

See: CVE-2009-3555 ( https://cve.mitre.org/cgi-bin/cvename.c … -2009-3555 ) for further details. We provided this due to customer demand but we do not recommend it be used EVER!

Please keep in mind this feature will not be available in TLS1.3 which wolfSSL will implement as soon as the draft is finalized. (so plan accordingly)

Kind Regards,

Kaleb & the wolfSSL Team