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
