Re: ZEO SSL support and Daft docs

On Wed, Jun 22, 2016 at 4:43 PM, Patrick Strawderman <[email protected]> wrote:
> What will the defaults be regarding things like protocol version

I'm currently using ssl.PROTOCOL_SSLv23 as recommended by the docs.  I
suppose this could be configurable. I'm open to suggestions.

> and cipher
> suites?

I have no idea. Whatever you get by default in a SSLContext. :)

> I would suggest not supporting SSL at all, and only supporting TLS.
> It seems like ssl.create_default_context() disables SSLv2 and SSLv3, as well
> as some weak ciphers, but it might make sense to provide a stricter default
> for the ciphersuite list, and to disable compression (to mitigate attacks
> like CRIME).  Note that Python >= 2.7.9 and Python >= 3.4 is a requirement
> for a lot of these options in the ssl module.

This sounds reasonable. I'll look into this.

>
> A couple of other thoughts:
>
> - Why not verify hostnames by default? Also, why must the hostname be
> explicitly specified? Couldn't it default to the hostname used in the client
> config? I suppose that would make it inconvenient for development or people
> who specify IP addresses.

It *does* default to the host given in the server address.

My thought was that host checking wouldn't be that interesting without
signed certificates, and that unsigned certificates would be far more
common for ZEO.

> - What about logging a warning when the client has SSL enabled but is not
> verifying server certificates? I guess this is also useful for development,
> but would be worried about forgetting to set this up correctly in
> production.

I'm open to this. I wonder what others think.

> - The description for client authentication seems a bit off. Namely the line
> "A client must be configured with one of the certificates supplied using
> this setting." You're supplying a CA cert that you trust and that the client
> certificate must have been signed with. So that sentence is only (somewhat)
> true for self-signed certs.

I'm open to wording changes, but I'm assuming that people would rarely
bother with signed certs for ZEO. Perhaps I'm wrong. At a minimum, I
can clarify the wording to indicate that this is referring to unsigned
certs

> - The certfile can contain the private key, so maybe the key parameter
> should be optional?

Yup.  It is.

> - What if I don't want to store the private key unencrypted on the machine?
> I'm not sure that adding a password option is a great idea, since it would
> be have to be in plaintext, but people might load such secrets at runtime
> (e.g., from a service like Confidant or Vault). This could be done with a
> configuration option for specifying a callable to retrieve the password.

OK.  This would presumably be a dotted name of an importable callable,
given that the context here is a configuration file.

>
> - It seems like clients can be configured to use the system's CA bundle, but
> the same is not mentioned in the description for the server's client cert
> configuration. Is that intentional?

It was unclear to me if this would be useful.  I *am* implementing it that way.

FYI, here's the code that sets up SSLContext's from configuration:

https://github.com/zopefoundation/ZEO/blob/ssl/src/ZEO/zconfig.py

I hope to make a PR for the initial SSL implementation tomorrow.

As you know, this isn't my strong suit, so I appreciate the input. :)

Jim

-- 
Jim Fulton
http://jimfulton.info

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.