Open glyph opened 7 years ago
I think perhaps a different API shape might be appropriate if we implement this; while there's nothing technically preventing you from having mapping[key] → Deferred
, having __special__
methods returning Deferreds is not exactly idiomatic and will probably be highly surprising.
Also, whatever interface we end up with here should be compatible with ICertificateStore
from txacme one way or the other (probably by making the interface the same in both places, but providing an adapter might also be okay).
It should be possible to support a
Deferred
returned fromSNIMap
'smapping
parameter, allowing for certificates to be requested from a remote certificate store, such as a back-end database, rather than the filesystem.Right now,
SNIMap
requires the synchronous construction of aContext
object, so we must synchronously construct one. Superficially, the structure of TLS support requires this.However.
We already construct a
_ConnectionProxy
rather than handing aConnection
directly back to Twisted. All the bytes received from the connection go to this object, not the underlyingConnection
, viabio_write
. We can create a throw-awayConnection
object that we pass bytes to, waiting for the SNI hook, and then instead of assigning itsContext
and letting it continue the connection, instead we fire off aDeferred
.When that
Deferred
fires, we need to feed those same handshake bytes into a newConnection
object, this one with the correct Context already set; the one extra trick is that we need to somehow have a reference to theTLSMemoryBIOProtocol
to call_flushSendBIO
on it, now that we can send out the now-availableServerHello
that we have available, given our SNI-selected backend certificate. Luckily, we got that passed in to us withserverConnectionForTLS
! Technically speaking we can do this all with public APIs, just usingproto.transport.write(self._obj.bio_read())
to kick off the next write.