Nico Williams <n...@cryptonector.com> wrote:
> On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote:
>> Thus, a single header isn't enough, although there could be some
degeneration
>> that results in a single header. We need a few variables to update.
>>
>> I think we have a choice between:
> HTTP/2 and, I imagine, /3, does header compression of the right sort
> here.
The front-end/back-end connection is not likely to be HTTP/2 soon, but maybe
this would push it there. Right now, it's a often pseudo-binary-HTTP
connection via uwsgi (across python/ruby/perl/npm) backends, fastcgi and
passenger has a protocol that I don't recall.
All avoid reparsing the HTTP headers excessively, while still letting the
whole thing evolve. There are responses that allow the backend to ask the
front to serve up static content and/or cached results as well.
So it's not often pure HTTP/1, but it acts a bit like it.
>> 2) assuming that state will be maintained by both ends, and simply
updating
>> the state appropriately. When it comes to this, I think of the
>> HTTP PATCH methods, but I'm not sure I mean this literally.
> Can TLS let a client authenticate multiple times?
What has been pointed out is that TLS can renegotiate client authentication.
(Also also server authentication, but that's not relevant here, I think).
If I had a monolithic web server with application code, I think that I would
have no idea what to do if such a thing happened: how I'd detect it, or what
I'd do with it. I think it would look like an entirely new client identity.
(This would be particularly difficult for J2EE environments which basically
spin up a JVM per [authenticated] client)
>> Alternately, the TLS front-end could maintain a RESTful interface on a
>> per-connection basis that the back-end could interrogate. The header
>> would just provide the right reference to that. The RESTful interface
>> could even be pushed/updated into some other CPU on the TLS terminator.
> Yes, this would also work. In this case Client-Cert: would carry just a
> URI. This is nice because the backend can validate that the origin of
> that URL is one it trusts.
Yeah, URI rather than URL, as it could even be ni: telling the client to go
look in a database/memcached/redis for the entire story.
This is more than a baby step, as Brian has pointed out.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
