> Point taken. However, it's important to know that SSL uses the negative form, > which is why I preferred to use the same one. You have options to *disable* > use of V2/V3/TLS, not to enable them. Thus I find it more durable to stay on > the same logics because if openssl 1.2 comes with support for TLSv5, it will > be offered by default until we have an option to disable it. With the positive > approach, it will be offered by default until unknown, and once known, it will > suddenly be disabled for the same configs unless users explicitly ask for it. > I'm rather for long-term config compatibility you know :-)
Right, I fully agree with you. > However if we see a much higher performance level by using the native API, > we'd probably write a 3rd data layer dedicated to yassl, and would probably > rename the current SSL data layer so that we can choose the one we want at > build time. Ok, thats great. I have another comment about yassl: It seems that CyaSSL, the ANSI C based edition of yaSSL is recommended over yasll (see [1]). For example TLS1.2 doesn't seem to be supported on yasll yet, while CyaSSL already supports it. I do not have any programming knowlegde, so please execuse my probably stupid question, but whats the reason to impement yasll instead of CyaSSL? Can't a C-lib be implemented in a C++ application? Regards, Lukas [1] http://www.yassl.com/yaSSL/Products-yassl.html ---------------------------------------- > Date: Tue, 4 Sep 2012 15:26:24 +0200 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: HAProxy with native SSL support ! > > Hi Lukas, > > On Tue, Sep 04, 2012 at 03:05:14PM +0200, Lukas Tribus wrote: > > Willy, this is huge! Great, great work! > > > > A few comments/questions: > > > > - are you running latest and greatest openssl on demo.1wt.eu? I am asking > > because Secure Renegotiation doesn't seem to be supported [1]. Older > > (<1.0.0?) releases seem to have a higher memory overhead as well, iirc. > > Just checked and no, it's 0.9.8 only on this box. Anyway this is not > very important on this box since it gets very low load. Also this was > more for the test than anything else, so I expected that someone would > even complain about the self-signed cert :-) > > > - I see you have implemented "[nosslv3] [notlsv1]" to limit the SSL/TLS > > protocols. I do prefer the nginx approach [2], positively specifying the > > protocols used. This is much more flexible. Even if today the 2 options are > > fine for generic HTTPS proxies in the Internet, there may be corner cases or > > future needs to specify the protocols in a more flexible manner, like nginx > > does. > > Point taken. However, it's important to know that SSL uses the negative form, > which is why I preferred to use the same one. You have options to *disable* > use of V2/V3/TLS, not to enable them. Thus I find it more durable to stay on > the same logics because if openssl 1.2 comes with support for TLSv5, it will > be offered by default until we have an option to disable it. With the positive > approach, it will be offered by default until unknown, and once known, it will > suddenly be disabled for the same configs unless users explicitly ask for it. > I'm rather for long-term config compatibility you know :-) > > > - about ssl ciphers, we should probably steal the default from nginx, by > > using "HIGH:!aNULL:!MD5" [3], so we don't enable obsolete ciphers like DES > > by > > default [1]. > > OK, right now nothing is set by default and indeed it could be an idea. > > > - any way to validate certificates of the backend? Perhaps a insecure/secure > > flag should be introduced. The exact host/domainname is needed as well to > > validate the backend certificate. Consider configurations where the backend > > server is not local, but can be contacted only over the big bad internet. > > I'm > > also thinking of a certificate validation in the health checks. > > We're considering adding some "verify" options exactly for this, in order to > only accept some backend certificates as well as to validate some users. They > are not implemented yet, but this is planned. > > > - probably not a much requested feature, but for the record: any plan to > > make > > client based certificates work? Could be interesting for example to > > authenticate haproxy on the backend servers. There are probably people with > > frontend "client certificate" use-cases as well. However general interest in > > this feature is probably low. > > This was our primary concern, but in order to get these, we needed native > SSL :-) > > So yes this will come, maybe soon, maybe later. We hope no later than the end > of the year depending on our available time, but maybe much sooner too. I also > want to be able to pass client cert info into HTTP headers, logs and ACLs. > > > - you seem to be interested in supporting native yassl. Would you then drop > > openssl support or would the idea be to support both native yassl and the > > openssl api? > > No, we wouldn't drop it, openssl is the de-facto standard. However if we see > a much higher performance level by using the native API, we'd probably write > a 3rd data layer dedicated to yassl, and would probably rename the current SSL > data layer so that we can choose the one we want at build time. > > > Congratulations to this big step in haproxy development! > > Thanks :-) > > Regards, > willy > >
