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

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html