[Security-sig] Unified TLS API for Python: Round 2

Cory Benfield cory at lukasa.co.uk
Sun Jan 22 07:01:00 EST 2017


> On 20 Jan 2017, at 23:00, Nathaniel Smith <njs at pobox.com> wrote:
> 
> - given that for next protocol negotiation we have to accept arbitrary
> bytestrings and the primary value of the NextProtocol class is to
> protect against typos, I wonder if it would simplify things slightly
> to make the attributes of this class just *be* bytestrings. I.e. what
> you have now but without the inheritance from enum.

While we *could*, I don’t think the value-add of doing this is very high. Basically the only thing it simplifies is the type declaration, and I don’t know that it’s worth doing that. ;)

> - what object types *do* you expect to be passed to wrap_buffers? I
> was assuming bytearrays, but the text at the bottom suggests
> file-likes?

Yeah, good question. I was assuming file-likes as well, but I don’t see any reason we couldn’t also do bytearrays. What do you think the advantage of that is?

> It isn't quite clear to me right now how this kind of API should look
> with your proposal. Obviously they can't just take a SSLConfiguration
> object, because there's no way to look at an SSLConfiguration object
> and figure out what backend is in use (even though in general a given
> SSLConfiguration is only usable with a specific backend, because
> backends provide the Cert type etc). They could take a
> ServerContext/ClientContext, I guess? But it would be nice if there
> were some way to say "give me the default configuration, using
> SChannel". Or to write a function that sets up an SSLConfiguration
> while being generic over backends, so like it takes the backend as an
> argument and then uses that backend's cert type etc.

Yeah, I was assuming that they’d take a ClientContext/ServerContext object, rather than a configuration plus an instruction on which backend to use. It’s not clear to me that a function that setups up a configuration while generic over backends is actually a meaningful thing to have: are there really going to be users who are insistent on a specific TLS configuration but don’t care what concrete implementation is going to be used, such that their libraries have to pick it for them?

Cory





More information about the Security-SIG mailing list