A quote [1] from the (C)yassl forums regarding RFC5746 "Secure Renegotiation" in (C)yassl:
> 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. So the problem I mentioned will be fixed by implementing secure renegotiation in (C)yassl, thats great. [1] http://www.yassl.com/forums/post651.html#p651 ---------------------------------------- > Date: Tue, 4 Sep 2012 20:16:03 +0200 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: HAProxy with native SSL support ! > > On Tue, Sep 04, 2012 at 06:52:24PM +0200, Lukas Tribus wrote: > > A few more comments about (C)yassl: > > > > - development of new features is obviously not as fast as in OpenSSL. For > > example TLS SNI is not supported yet (ETA: next release) [1]. This feature > > was introduced in 2007 (0.9.8f) in the openssl implementation, and it was > > enabled by default in 2009 (0.9.8j), [2]. That doesn't mean yassl isn't > > suited for haproxy, one just needs to be aware that yassl is NOT a faster > > openssl with lower memory overhead. Its a different implementation with > > different goals and OpenSSL will remain the full-featured reference, with > > company's like Google introducing new features and providing bugfixes > > for it. > > > > - (C)yassl doesn't support - by design - renegotiation. They also don't > > implement RFC4756 (secure renegotiation), see [3]. While this is not > > a security problem (from a server point of view), it will become an > > interoperability problem sooner or later, once browser vendors "make > > the switch", and threat non-RFC4756 capable servers as broken [4], > > [5], [6]. I wonder how this is going to be fixed, if at all. > > > > - I also believe that most of the haproxy maintainers will compile haproxy > > with openssl, and yassl will be more or less available only to those > > compiling haproxy on their own. In fact, libyassl/libcyassl is not even > > available in debian for example [7], and they don't like libs linked > > statically to their packages. > > Thank you very much for these insights. I was not aware of the second point, > so your explanation is useful and welcome. I generally agree with everything > you said, it makes a lot of sense to me. > > > Anyway, time will tell and the mentioned issues are no "showstoppers". > > Indeed, and when products are used, they evolve. > > Regards, > Willy >
