Sign outgoing LSL HTTPS requests for verification
tracked
Chaser Zaks
Pre-AWS, we were able to verify incoming LSL HTTP requests by checking against the request IP to verify that it is in LL's IP blocks, now since everything is under AWS, it isn't possible anymore.
There isn't a reliable way to verify that a request is coming from SL, so that it can be fenced to Second Life requests only.
After researching and trying to come up with some feasible methods, I came across the fact it is perfectly fine for a TLS connection to send a client certificate.
This is for NodeJS, but it's the best thing I can find at the moment https://medium.com/@sevcsik/authentication-using-https-client-certificates-3c9d270e8326
It may be possible to sign outgoing requests with LL's global cert, so that if a request is incoming, a server can check if the certificate is actually LL's.
What I am unsure about is if this break existing requests? I'm under the impression that most servers will ignore the certificate by default, because they don't typically request a client certificate. If so, this can be added as a HTTP_REQUEST flag.
It looks like the specification goes as so (In this scenario, Client is a LSL script, server is a third party HTTP server):
- Client contacts server and says "Hello"
- Server replies "Hello", presents it's certificate.
- Server OPTIONALLYasks the client for their certificate, normally this is off.
- Client verifies server's certificate
- If asked, client presents it's own certificate
- Server checks the certificate, OPTIONALLYrejects the connection if it is untrusted
I'd like to be able to keep all my stuff open source, while also not telling people who want to modify stuff "Go make your own server if you want to edit the scripts", because that doesn't feel very open source to me. Being able to verify that a request is from one of LL's servers and trust the x-secondlife-owner key is vital for this.
This would allow people to verify LSL requests using the cert provided by https://github.com/secondlife/llca
Assuming Squidproxy is still used to proxy outgoing requests, both Squid-3 and Squid-4 both support signing outgoing requests: https://squid-users.squid-cache.narkive.com/ppuGVty2/using-client-certificate-for-all-connection#post6
Log In
Gwyneth Llewelyn
Good, good. Much better than most of the alternatives I've seen elsewhere; in fact, I would argue that using client certificates should be
additional
to whatever root certificate LL uses, self-signed or not.I also especially like the notion that this could be made
optional
, not mandatory. That would mean that those who need
to rely on the reliability of the source (the SL Grid) would at least have a way to do some validation. While all existing scripts, which either implement their own secure authentication procedure or simply don't care about any kind of authentication would not
immediately break every existing scripts.Gwyneth Llewelyn
See also: https://feedback.secondlife.com/feature-requests/p/use-a-well-recognized-ca-for-simulator-https-listeners (it's not the same request, but it also mentions the issue with LL's self-signed certificates)
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Kathrine Jansma
TLS client certificates are nice, but tend to be troublesome if any kind of proxies or ingress services are involved. In addition, TLS client certs are pretty heavyweight.
It might be much easier to just publish some JWT JWKS_URI for Secondlife and then just put a trivial signed JWT (with ES256) into a custom header instead.
Then any consumer could verify the origin by verifiying the signature with the published keys. And one gets the option to embed custom signed request metadata into the JWT.
Thats much easier than dealing with the Lovecraftian ASN.1/X509/PKI mess required for client certificates.
Signal Linden
We will likely be be dropping the whole self-signed CA + cert and opting to use a standard commercial authority (This will make things less annoying for viewers to deal with, and also be more secure since LLCA uses an insecure algorithm.)
However, that said: doesn't change anything about this feature request. Could use a client cert of some/any variety, as long as the public key is shared it could be verified.