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

[Nathaniel Smith]

On Sun, Jan 22, 2017 at 4:01 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
>
>> 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. ;)

Well, and the code that receives the values, which currently has to
handle both enums and bytestrings. Agreed it's not a big deal, it just
seems like the value the enum is adding is all negative.

>> - 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?

I've just been used to using bytearrays everywhere for things like
socket receive buffers. I find them much more convenient to work with
than BytesIO b/c you can do things like pass them directly to
send/recv/parsing functions, and they have nice properties like O(1)
deletion from the front. It doesn't matter so much for this case where
we're just shuffling bytes to and from a socket in a lump, but that's
why I was assuming bytearrays without thinking about it :-). I guess
h2's data_to_send and data_received don't involve any file-like
objects either?

>> 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?

I think it's more likely the other way around -- users need to
override the default backend, but don't want to specify all the
details? And any library that does build configuration should be able
to do it using generic code so long as it's sticking to generic
features?

requests.get(..., backend=WeirdEmbeddedTLSLib) -> "I need to use this
lib, but requests should pick the ciphers/TLS version/etc., I'll just
screw it up"

web-server.cfg:

listen-port = 443
[ssl]
enabled = True
backend = SChannel
certificate = foo.pem

Like, in the PEP as currently written, it goes to great efforts to
make sure that generic code can be used to select cipher suites, but
there's no way for a web server to load in certificate given a PEM
filename, except via having a hard-coded table of all possible
backends? The PEP says that each backend should somehow somewhere
provide a concrete subclass of Certificate, but to find it you need to
consult the backend-specific docs.

This is really a usability point that's mostly orthogonal to the
semantics/design discussion and should be pretty straightforward to
sort out, so it might make sense to defer worrying about it until the
other stuff's more settled.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org