RiotGames
Update tournament callback to support newer CAs
As per the devportal;
The server callback supports http (port 80) and https (port 443) however Certificate Authorities (CA) approved after Jan 29, 2012 aren't supported. The callback server won't perform a callback if it is unable to validate an SSL cert issued by an unknown CA (and therefore doesn't trust).
2012 is quite some time ago, and it would be nice to have this be more up-to-date
I was about to create this issue now.
But if we could get CAs such as Cloudlfare supported that would be amazing. As its a vital backbone of the internet these days.
@OllieJennings This was something that was considered in the past. This would basically entail updating the rest client used by the service or manually adding certs to the rest client. This isn't out of the question, but my expectation is that this won't be a priority in the near future. We'll let the team know so they are aware, but the impact of this issue is relatively low because there are alternatives between using an older CA or making the callback over http and including something like a signed token in the meta field.
Hey, can this get a bump somewhat? Looking at prices for SSL providers, it goes for about 100$/year. Compared to newer CAs where its free (Let’s Encrypt)
The issue centers around the http client, that makes the request, trusting or not trusting the Certificate Authority (CA) that issued the cert. The http client that makes the request is relatively old and doesn't trust CAs established after Jan 29, 2012. Let's Encrypt, for example, was established in 2014 so any of the SSL certs issues from Let's Encrypt wouldn't be trusted by the current http client. Updating the http client is currently a low priority because for two reasons; first any certs issued from a CA before 2012 should work as expected and second requests can be made over http and validated for authenticity.
To validate a callback made over http, you can include a "validation code" in the meta field of the post body when generating the tournament code. When the callback is made, you can validate that the code matches to ensure the callback was made from the tournament service.
That being said, I'll bring it up the next time they're working on this service and see if they can update the http client.
If you're worried about spoofing you'll need a validation code (in metadata or as a query parameter) regardless of https; there's nothing stopping someone from sending whatever random stuff they want to your https endpoint.
But in terms of security if you're using unsecured http then your validation code could get MITM'd ... but if you're worried about that you probably spend all your money on tin foil hats. (The "correct" solution is to have Riot's servers sign the response in a header field with a known public key, works http and https, but not gonna happen). You could also just ignore callback data and poll the match endpoint instead.
So yeah, just use http is my opinion
I second this request. Not trusting post 2012 CAs (eg. mentioned Let's Encrypt) forces our microservice responsible for handling callbacks to accept insecure http requests which could else be rejected.
