Sätter min ISP X-Forwarded-For med googleusercontent.com som värde?

Hur vet du det? Om du inte kör https så kan svaret komma från vilken mellanliggande nod som helst, du har ingen som helst försäkran om att det är den maskin som finns i URL:en som faktiskt har svarat.

Dessutom kan vilken mellanliggande nod som helst injecera vad som helst i den okrypterade trafiken.

Om du hade kört https i stället hade du dock troligen sett exakt samma sak. Av det kan vi sluta oss till att den som sätter headrarna har tillgång till certifikatet för ifconfig.me (eller mindre troligt: falskeligen kan utfärda certifikat som gäller för ifconfig.me och vars rotcert finns i våra webbläsare).

Det troliga är därför att det är servern som finns i DNS namngiven som ifconfig.me som terminerar TLS-sessionen, sätter headern till det IP som anropet kom ifrån och öppnar en ny TCP- eller QUIC-anslutning till den server som faktiskt ska processa anropet.

En helt vanlig reverse proxy med andra ord. Syftet med en en reverse proxy kan vara att dela på lasten som krävs för att kryptera/dekryptera TLS och att göra den faktiska processningen som krävs för att leverera innehåll. Om man vill logga var anropet kom ifrån på den slutgiltiga destinationen måste man hitta på ett sätt att överföra den informationen, eftersom IP-från-adressen nu tillhör reverse proxyn, därav XFF-headern. Eller, som i det här fallet, hela funktionaliteten går ut på att visa varifrån det ursprungliga anropet kom...

En reverse proxy som har dekrypterat den TLS-skyddade trafiken kan naturligtvis sätta vad sjutton den vill.

Jag orkar inte testa IPv4, men i mitt fall blev det 2600:1901:0:bbc3::, som också tillhör google.

Varför man gör så? Ingen aning. Varför man inte döljer XFF-headern igen när man vet att man själv har satt dit den? Ingen aning, lathet?

Edit: Roade mig med att slå upp ifconfig.me i DNS och kolla whois. Det är googles IP. Gissningsvis är sajten helt enkelt hostad i googles moln.