Riot CDN is now served over HTTPS

[ti-mo]

As reported by @fsalazar1977, Riot is now serving its content over SSL. (at least the client requests https:// resources) This cripples our ability to cache game content and breaks the client's update mechanism until fixed.

Looking for possible downgrade mechanisms to HTTP. Since Akamai's certs are used for l3cdn.riotgames.com, I assume cert validation is disabled, issuing self-signed to the client is rumored to work. (to be confirmed)

@RiotGames, please don't do this, run artifact integrity checks on the client. :)

[stevenh]

@irconan We use seperate IP aliases for each service, so no changes there, however caching doesn't go through NAT as that would mean it would have to be processed by the FW, so that wouldn't work.

[v3n]

@stevenh: Should be releasing with the 6.6 patch which is supposed to release this week, it's in mainline now. I realize the release schedule isn't ideal, sorry for that.

@irconan: Is it possible to configure nginx to directly pass all 443 traffic to the real l3cdn? Or is that exactly what you're proposing and I'm just dumb? :p (not a network engineer).

[stevenh]

@v3n this week before Friday?

[ClearCarbon]

@stevenh I'm not attending i57 but I've been attending Insomnia events for almost a decade now. I've generally found communication about these sort of issues to be frustrating, not everyone checks (or knows about) the intranet and forums and the group I attend with don't participate in the tournaments. I've not been to an insomnia at the NEC yet but if you have the gaming room projectors like at Telford adding a message about this on there would be really helpful for a lot of the attendees.

[v3n]

@stevenh: today & tomorrow for various regions.

[nexusofdoom]

is the update live? do you know when the RFC1918 changes will be merged to the mainline branch?

[ClearCarbon]

@nexusofdoom I've tested it and the change appears to have gone live

[RobertJamesMichael]

Hi Temo, just in case, LOL is serving via HTTPS again, do you know how to solve this?

[stevenh]

There's no really fix I'm afraid.

Caching proxies and https are just at odds, https is specifically designed to avoid that type of thing as if it could be done it you could sit as a man in the middle and sniff everyones content.

[riconnon]

@fasa1977 so you're resolving the names to an IP in RFC1918 block and it's still attempting HTTPS? This would indicate that Riot have removed the workaround that was put in place for this exact use-case.

I wonder if @v3n is able to comment?

[ClearCarbon]

from what I could see the new client doesn't have the RFC1918 workaround. This was some time ago during the new clients beta.

[riconnon]

I guess we can hope that the workaround was just lost in a refactor somewhere and can be re-added.

[RobertJamesMichael]

Right @irconan and @ClearCarbon, @stevenh is it possible to get back the workaround? , we are having hard time patching LANs, we were making this manually, but, since the beginning of the new season, we have more people that want to play (thats why I am reporting this and not before), of course we do our job, but think in Lans with more 200 computers...no matter the bandwidth you get, it's difficult to patch efficiently that ammount. Thanks in advance for your help!

[ti-mo]

Hi folks, curious to hear @v3n's input, but to me the move to TLS seems inevitable. CDNs are all offering TLS at the edge, up to the point of (I predict) plaintext endpoints not even being an option anymore a couple of years down the line.

If Riot is willing to keep supporting this, that would be great for us, but I'm afraid this is it.

[nexusofdoom]

what version of the client are you running?

this is my config

riot

server { listen lancache-riot deferred default; servername riot ;

access_log /srv/lancache/logs/Access/riot.log main buffer=128k flush=1m; access_log /srv/lancache/logs/Keys/riot.log keys_range buffer=128k flush=1m; error_log /srv/lancache/logs/Errors/riot.log;

Default Node

include lancache/resolver; include lancache/cache-key-default;

location / {

Some downloads are very large so we cache based on

# range to keep single downloads quick and hence ensure
# interactivity is good.
set $no_cache 0;
if ($request_uri ~* "(/releases/live/solutions/.*/releases/releaselisting)") {
    set $no_cache 1;
}
proxy_no_cache $no_cache;
proxy_cache_bypass $no_cache;
proxy_bind 10.0.4.2;
#proxy_ignore_headers Expires;
proxy_ignore_headers Expires Cache-Control;
#proxy_hide_header ETag;
#proxy_cache_valid 200 206 360d;
proxy_cache riot;
proxy_read_timeout 300;
include lancache/proxy-cache;
include lancache/cache-range;

} }

[nexusofdoom]

I am running on client version patch 8.1 and it looks like it downloading over http not https and working for me.

[jblazquez]

Hi all,

I work on League of Legends. I wanted to drop a note here to mention that over the next couple of weeks we're going to start switching League to patch in a different way from a new set of CDN endpoints, which will affect the caching setup that you have implemented here.

We're moving away from l3cdn.riotgames.com to two new hostnames: lol.dyn.riotcdn.net and lol.secure.dyn.riotcdn.net. We're keeping the HTTP fallback behavior that you're relying on here for caching because we don't want to break your use case. Please read below to see how we're going to be using the two new domains going forward. Hopefully this will be an easy transition for you folks!

lol.dyn.riotcdn.net is the hostname we'll use for downloading the vast majority of patch data. We default to using HTTPS here but we will fall back to HTTP if the hostname resolves to a private IP address. We consider all of the following "private IPs":

IPv4: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918 private IPs), 169.254.0.0/16 (RFC 3927 link-local IPs) and 127.0.0.0/8 (RFC 1122 localhost IPs). IPv6: FC::/7 (RFC 4193 unique local unicast) and FE80::/10 (RFC 4862 link-local IPs)

lol.secure.dyn.riotcdn.net on the other hand is a hostname we'll use for HTTPS exclusively, with no possible fallback. We will only download a small (~5MB) release manifest from here, which contains cryptographic hashes for the rest of the patch data. This allows us to safely use HTTP in the fallback scenario with no security implications, while still making the vast majority of the data cacheable.

Your DNS server should redirect lol.dyn.riotcdn.net only.

Another thing that's changing is the nature of our HTTP requests. We will make many more individual requests compared to before, and each request will be an HTTP range request, potentially with multiple byte ranges at a time. This will allow us to retrieve just the data that we need from the CDN. Our patcher expects CDNs to honor these range requests and respond with a 206 code, but it can gracefully handle 200 responses as well, albeit with reduced efficiency.

Hope this helps! Let me know if anything is unclear or you need more information about how this will work.

[nexusofdoom]

Thank you I have updated my installer.

[mintopia]

@jblazquez I'd just like to thank you very much for letting us all know about this and providing this fallback. It's brilliant, and I just wish the other game publishers and developers would do the same thing!