On Mon, Feb 16, 2015 at 02:19:17PM +0100, Daniel Stenberg wrote: > On Sat, 14 Feb 2015, Alessandro Ghedini wrote: > > >I've implemented new libcurl/curl options for enabling TLS false start > >[0]. AFAICT only nss supports it so only the nss backend implements the > >new option. > > Awesome! > > >Both chromium and firefox enable false start only if the server also > >suports NPN/ALPN or if it supports forward secrecy in order to avoid > >weird/broken SSL implementations. Also, since there is a chance that > >application data is sent to an imposter (since we send the data before > >verifying the server's Finished frame), it is also recommended to only > >enable false start when strong ciphers are used. So I wonder, should we do > >all theses checks in libcurl too or just let the user decide? > > With the traditional curl approach we would offer all three options: > OFF/ON/WITH-CHECKS, but I guess the "on" case is a potential security > problem waiting to happen when users won't read the documentation and > possible documentation warnings. > > So, I'm thinking the checks will be good.
Ok, I looked into how to do the checks and I found a couple of problems: * ALPN/NPN is currently only enabled if HTTP2 support is built and requested by the user. We would need to enable ALPN/NPN with HTTP1.1 as well (I can look into this). * Regarding the check for forward secrecy, firefox allows RSA, DH and ECDH key exchange algorithms, but chromium (which uses the SSL_RecommendedCanFalseStart nss function) doesn't allow RSA. What should libcurl do? (e.g. my test server uses RSA by default). > And with the checks, could we perhaps consider enabling it by default at > some point? Yeah, I think that would be ok. Cheers
signature.asc
Description: Digital signature
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
