Allow two SSL Server Socket parameters to be tuned by the caller

Allow two SSL Server Socket parameters to be tuned by the caller

Before calling EnableSSLServerSockets, you can now use
SetSSLServerSocketParameters to set the max number of Session ID cache
entries as well as the ssl session cache timeouts when using nss.
Currently unimplemented for OpenSSL.

BUG=426630

[GusFernandez, 2014-10-23 22:51:29]

gusfernandez@chromium.org changed reviewers:
+ dougsteed@chromium.org, lcwu@chromium.org

[GusFernandez, 2014-10-24 01:17:20]

gusfernandez@chromium.org changed reviewers:
+ rsleevi@chromium.org

[Ryan Sleevi, 2014-10-24 01:20:38]

rsleevi@chromium.org changed reviewers:
+ davidben@chromium.org

[Ryan Sleevi, 2014-10-24 01:20:38]

I'm not happy introducing new globals, nor do I like yielding control of
critical security parameters to embedders.

Adding David, who I would like to take a look at this.

[dougsteed, 2014-10-24 16:07:46]

On 2014/10/24 01:20:38, Ryan Sleevi wrote:
> I'm not happy introducing new globals, nor do I like yielding control of
> critical security parameters to embedders.
> 
> Adding David, who I would like to take a look at this.

Not sure how the existing values were selected, or what their security
criticality is.
Ryan, you chose these values a couple of years ago, so maybe you can elaborate?

Anyway, the values aren't suitable for Cast.
1024 for the session cache size is too large, and results in allocating close to
2MB of unused memory in low end devices.
5s for the session lifetime is too short, we think there will be significant
performance benefit in increasing it to a few hours.

Our preferred values are of the order of 16 for the cache size and 28800 for the
lifetime (although these values are not carved in stone).

We could consider different ways of customizing the values to our needs. 
-Probably ugliest option would be for us to put our values in an #ifdef if there
are only couple of different profiles that make sense.
-If the existing values are somewhat arbitrary, we could substitute our
preferred values (or something closer) instead of the current values.
-We could make it mandatory to supply values (suitably range-checked) at
initialization time, and change all the call sites.

The use of the global variables was just to make the change backwards-compatible
for other users.

[davidben, 2014-10-24 16:32:53]

In general, we don't maintain any backwards-compatibility promises on ABI or API
at the net stack boundary. If some extra parameters need to be added somewhere,
we'll add them there and update consumers in Chromium. Downstream consumers are
responsible for updating their end, as with anything else in Chromium.

Ideally this should be a parameter on the server socket. Unfortunately, NSS's
API is really poor and seems to only maintains a single global session cache
anyway, so that's not possible. Which... actually I hope we never run more than
one of these in the browser process. The only consumer I see in Chromium is
remoting. BoringSSL is the future and that provides a much less useless API...

What exactly are cast's clients? Specifically, are all your clients remotely
modern[*]? If so, there's no need for a session cache at all and you can just
use session tickets. Session tickets do not require server memory. There does
appear to be an SSL_NO_CACHE option and that one is not a global. As for
expiration, it appears NSS doesn't even let you configure session ticket
lifetimes at all and hardcodes them to two days anyway. I actually suspect the
lifetime will have no effect on performance.

That said, NSS does appear to allocate all its memory up-front, so the memory
thing isn't a no-op. Ryan, do you know what the consumers of SSLServerSocket
are? Could we maybe just disable session caches in favor of session tickets
everywhere, rather than add a random global that we'll have to remember to get
rid of when we lose NSS?


[*] For browsers, see https://www.ssllabs.com/ssltest/clients.html

[dougsteed, 2014-10-24 17:23:18]

On 2014/10/24 16:32:53, David Benjamin wrote:
> In general, we don't maintain any backwards-compatibility promises on ABI or
API
> at the net stack boundary. If some extra parameters need to be added
somewhere,
> we'll add them there and update consumers in Chromium. Downstream consumers
are
> responsible for updating their end, as with anything else in Chromium.
> 
> Ideally this should be a parameter on the server socket. Unfortunately, NSS's
> API is really poor and seems to only maintains a single global session cache
> anyway, so that's not possible. Which... actually I hope we never run more
than
> one of these in the browser process. The only consumer I see in Chromium is
> remoting. BoringSSL is the future and that provides a much less useless API...
> 
> What exactly are cast's clients? Specifically, are all your clients remotely
> modern[*]? If so, there's no need for a session cache at all and you can just
> use session tickets. Session tickets do not require server memory. There does
> appear to be an SSL_NO_CACHE option and that one is not a global. As for
> expiration, it appears NSS doesn't even let you configure session ticket
> lifetimes at all and hardcodes them to two days anyway. I actually suspect the
> lifetime will have no effect on performance.
> 
> That said, NSS does appear to allocate all its memory up-front, so the memory
> thing isn't a no-op. Ryan, do you know what the consumers of SSLServerSocket
> are? Could we maybe just disable session caches in favor of session tickets
> everywhere, rather than add a random global that we'll have to remember to get
> rid of when we lose NSS?
> 
> 
> [*] For browsers, see https://www.ssllabs.com/ssltest/clients.html

Session tickets are not an option for us right now. 
They are not supported on either our iOS or Android cast senders.

[GusFernandez, 2014-10-29 20:39:59]

On 2014/10/24 17:23:18, dougsteed wrote:
> On 2014/10/24 16:32:53, David Benjamin wrote:
> > In general, we don't maintain any backwards-compatibility promises on ABI or
> API
> > at the net stack boundary. If some extra parameters need to be added
> somewhere,
> > we'll add them there and update consumers in Chromium. Downstream consumers
> are
> > responsible for updating their end, as with anything else in Chromium.
> > 
> > Ideally this should be a parameter on the server socket. Unfortunately,
NSS's
> > API is really poor and seems to only maintains a single global session cache
> > anyway, so that's not possible. Which... actually I hope we never run more
> than
> > one of these in the browser process. The only consumer I see in Chromium is
> > remoting. BoringSSL is the future and that provides a much less useless
API...
> > 
> > What exactly are cast's clients? Specifically, are all your clients remotely
> > modern[*]? If so, there's no need for a session cache at all and you can
just
> > use session tickets. Session tickets do not require server memory. There
does
> > appear to be an SSL_NO_CACHE option and that one is not a global. As for
> > expiration, it appears NSS doesn't even let you configure session ticket
> > lifetimes at all and hardcodes them to two days anyway. I actually suspect
the
> > lifetime will have no effect on performance.
> > 
> > That said, NSS does appear to allocate all its memory up-front, so the
memory
> > thing isn't a no-op. Ryan, do you know what the consumers of SSLServerSocket
> > are? Could we maybe just disable session caches in favor of session tickets
> > everywhere, rather than add a random global that we'll have to remember to
get
> > rid of when we lose NSS?
> > 
> > 
> > [*] For browsers, see https://www.ssllabs.com/ssltest/clients.html
> 
> Session tickets are not an option for us right now. 
> They are not supported on either our iOS or Android cast senders.

Closing this CL in favor of https://codereview.chromium.org/687343002/