Waarom https?
Tweakers is overgestapt op volledig https. Dat betekent dat je nu, als het goed is, alle pagina's van Tweakers, het forum en de tweakblogs via https krijgt. Mochten we ergens iets gemist hebben, dan horen we dat natuurlijk graag in dit topic.
Waarom https?
'Wat voegt https nou eigenlijk toe voor een site als Tweakers?' is een terechte vraag. Er worden erg weinig gevoelige onderwerpen behandeld en het zal weinig kwaad kunnen als iemand aan de hand van je verkeer kan zien dat je een Android- of iPhone-fan bent.
Beveiliging
De s in https staat voor 'secure' en het zorgt inderdaad voor een beveiligde verbinding. Let daarbij wel op dat dat alleen over de verbinding gaat. Onze site en jouw computer zijn door het gebruik van https niet ineens volledig hacker-proof geworden; daar zijn meer maatregelen voor nodig.
Een van de belangrijkste soorten aanvallen die met https sterk worden bemoeilijkt, is de zogenaamde 'man in the middle'-aanval. Dat lijkt op een proxy-server, maar dan met kwade bedoelingen. Daarbij zit een aanvaller tussen jou en de webserver in; naar jou toe doet hij zich voor als de webserver en naar de webserver doet hij alsof hij jou is. Ondertussen kan de aanvaller alle informatie die wederzijds wordt opgestuurd, inzien en/of aanpassen. Dit soort aanvallen is vooral gevaarlijk in situaties waarin echt iets te winnen valt, zoals een betaalopdracht bij een bank. Overigens hebben banken naast https meestal nog extra beveiligingsmaatregelen, zoals two factor authentication, om het MitM-scenario, en andere aanvallen, nog moeilijker te maken.
Bij 'gewone' websites zit het gevaar meer in het toevoegen van malafide zaken, zoals de injectie van malware of het toevoegen van eigen advertenties./i/2001070375.png?f=imagemedium)
Gelukkig is een MitM-aanval in de praktijk vrij lastig uit te voeren. Het is op zijn minst nodig dat jouw verbinding onderschept kan worden; er moet tenslotte ergens in de netwerkverbinding toegang verkregen worden. Er is wel een bekend voorbeeld: slecht beveiligde, publieke wifi-netwerken.
Naast de versleutelde verbinding biedt https ook extra authenticatie. Je browser controleert de hostname met het certificaat dat wordt opgestuurd. Als die niet met elkaar overeenkomen, geeft het een foutmelding en weigert het de pagina te tonen. Op die manier zijn domain-spoofs, en daarmee bijvoorbeeld phishing-aanvallen, wat lastiger op te zetten.
Privacy
Bovenstaand MitM-principe is ook vanuit privacy-oogpunt gevaarlijk. De informatie hoeft tenslotte niet veranderd te worden; voor sommige doeleinden is inzien ervan voldoende. Bovendien is het ongemerkt inzien van gegevens veel makkelijker dan het ongemerkt veranderen ervan.
Ook op Tweakers komen discussies voor met meer betekenis voor je privésfeer
Het eerder genoemde voorbeeld van iPhone- of Android-fans is natuurlijk niet zo spannend, maar ook op Tweakers komen discussies voor die een stuk meer betekenis voor je privésfeer hebben dan dat. Denk aan het doorgeven van contactgegevens voor Vraag & Aanbod-advertenties, maar ook sommige discussies in het forum, zoals de discussies die gaan over hoe slecht een werkgever is. Een bericht dat vanaf het netwerk van de werkgever wordt geplaatst, kan in theorie naar de plaatser teruggeleid worden. Daar hoeft dan alleen maar de meta-informatie voor te worden bijgehouden, zoals welke urls door iemand op welk tijdstip worden opgevraagd. Met https is via dergelijke metadata nog wel te zien dat en op welk tijdstip je verbinding maakt met de servers van Tweakers, maar niet wat je dan opvroeg.
Overigens is dit vooral relevant op netwerken waarvan je de tussenstations niet helemaal vertrouwt, want dat je technisch gezien afgeluisterd kan worden, is natuurlijk nog geen garantie dat het ook gebeurt. Zelfs diegenen die niet van de goedheid van hun medemens willen uitgaan, kunnen nog hopen op de gierigheid; apparatuur om af te luisteren kost tijd om op te zetten en geld om aan te schaffen.
Site-performance
We hebben ruim een jaar geleden ons dilemma om wel of geen https te nemen aan de bezoekers van Tweakers voorgelegd. Uiteindelijk hebben we daarna besloten om de introductie van https uit te stellen. Een van de redenen was dat de voor encryptie benodigde rekenkracht en vooral de connection setup van https, zoals het uitwisselen van certificaten, ten opzichte van http nog een zichtbare invloed op de prestaties van de website hadden.
Intussen is de wereld echter veranderd. De benodigde rekenkracht is minder relevant geworden, onder andere door de verdere opkomst van snellere cpu's en aes-instructies in die cpu's. Daarnaast is de bijbehorende software verder geoptimaliseerd. Ten slotte hebben we zelf ook meer geleerd over https, zoals welke tunables er bestaan en welke encryptievormen sneller werken dan andere.
Met https moet in principe voor iedere verbinding onderhandeld worden over de te gebruiken certificaten. Dat geeft een relatief grote overhead en is een van de redenen dat het (vooral) in het verleden duidelijk trager was dan http. Door allerlei trucjes in de nieuwere versies van tls en optimalisaties in serversoftware en browsers is dat langzaamaan minder erg geworden.
Met http/2 wordt het nog beter. Waar in http/1.1 vaak meer dan tien losse netwerkverbindingen werden opgezet met servers, ieder met eigen https-overhead, wordt nu nog maar één verbinding per server opgezet. Alle requests worden vervolgens via multiplexing min of meer tegelijk over die ene verbinding gestuurd.
Veel meer connecties parallel met HTTP/2 (rechts) vs. HTTP/1.1. De tragere eerste request wordt veroorzaakt door de langzamere testserver.
Daardoor zijn ook maar één keer de connection setup van tcp/ip en de daarop volgende ssl-onderhandeling nodig. Daarnaast kan er beter gebruik worden gemaakt van de snelheidseigenschappen van het tcp/ip-protocol, zoals het eenmalig opbouwen van een ruimere windowsize.
Met deze en andere aanpassingen is http/2, de facto met https, in sommige benchmarks zelfs sneller dan http/1.1 zonder https. Doordat de meeste browsermakers ondertussen http/2 ondersteunen, heeft nu zo'n zeventig à tachtig procent van onze bezoekers een browser die daarvan kan profiteren. Onze schatting is dat de verliezen door de versleuteling met ssl worden gecompenseerd door de optimalisaties van http/2, waardoor de site voor bezoekers ongeveer even snel moet blijven.
Domain sharding en san-certificaten
Pagina's bestaan vaak uit tientallen of honderden losse elementen, zoals afbeeldingen, stylesheets en javascript-files. Voor ieder van die elementen moet een losse request worden gedaan en dat brengt allerlei overhead met zich mee. Een aantal jaar geleden was het gebruikelijk dat browsers maximaal twee verbindingen per domein konden opzetten. Deze verbindingen werden vervolgens opengehouden en alle elementen werden een voor een opgevraagd. Dat maximumaantal verbindingen is overigens sindsdien opgelopen tot rond de acht of tien.
Doordat er voor elk element een stukje overhead aanwezig is, kon met dat lage aantal verbindingen geen optimaal gebruik worden gemaakt van de steeds hogere bandbreedte bij internetgebruikers. Om daar toch beter gebruik van te maken is in het verleden domain sharding bedacht; daarmee worden de site-onderdelen over verschillende servers verspreid. In het geval van Tweakers is dat gedaan door eerst tweakimg.net en later ic.tweakimg.net te introduceren. Omdat de limiet van twee, of acht+, verbindingen per domein geldt, kun je daarmee extra verbindingen ontsluiten voor browsers om daarlangs elementen binnen te halen. Door die extra parallelliteit was de totale benodigde tijd voor de losse site-elementen uiteindelijk lager.
Verliezen door de versleuteling met ssl worden gecompenseerd door de optimalisaties van http/2
Bijkomend voordeel was dat je die site-elementen dan ook gelijk op een 'cookievrij' domein kon plaatsen, de totale hoeveelheid data die voor een 'request' moet worden opgestuurd, nam daarmee met tientallen tot honderden kilobytes af. Met uploadsnelheden van rond de 1Mbit/s gaf dat weer een aardige winst voor de cookiedata, die verder toch werd genegeerd bij die elementen.
Met het bundelen van requests in één verbinding bij http/2 is dat opsplitsen in losse domeinen niet meer nodig. Sterker nog, als je niet oppast, werkt het in de nieuwe situatie juist tegen. Het eerder genoemde bundelen van browser-requests over één verbinding is dan niet meer zomaar mogelijk; dan zouden er in ons geval steeds drie nodig zijn. Omdat zo'n twintig à dertig procent van onze bezoekers nog geen http/2-ondersteuning heeft, wilden we dat ook weer niet zomaar opgeven.
/i/2001095851.png?f=thumblarge)
Gelukkig is er een oplossing die beide situaties kan combineren. We hebben ervoor gezorgd dat al onze domeinen hetzelfde certificaat en hetzelfde ip-adres hebben. Daardoor kan een browser in principe diezelfde verbindingen hergebruiken voor verschillende domeinen. Op die manier hebben we voor http/1.1-gebruikers nog steeds domain sharding en cookievrije domeinen, maar voor http/2 verloopt alles over die ene verbinding.
Het lijkt misschien onlogisch om verschillende domeinen met één ssl-certificaat te faciliteren, maar daar is de 'subject alternative name'-functionaliteit voor bedoeld. We hebben daarmee onder andere tweakers.net, gathering.tweakers.net, tweakimg.net, ic.tweakimg.net en tweakers.tv samengevoegd in een san-certificaat.
Let's Encrypt
Helaas bleek het lastig om betaalbare san-cerficaten te vinden die ook overweg konden met het snellere ecdsa. Bij de betaalbare aanbieder waar we al klant waren, maar geen ecdsa konden gebruiken, zouden we al gauw het dubbele kwijt zijn geweest van wat onze huidige wildcard-certificaten kosten. Gelukkig biedt Let's Encrypt wel de mogelijkheid voor ecdsa-certificaten en ondersteunt dit bovendien san-certificaten. We zijn daarom overgegaan naar het automatisch genereren van nieuwe certificaten via dat systeem en daarmee is het zelfs gratis geworden voor ons. Helaas heeft Let's Encrypt geen ondersteuning, en plannen, voor wildcardcertificaten, waardoor we met name het certificaat voor *.tweakblogs.net alsnog los moeten blijven voeren.
SSL offloading en Global Server Load Balancing
Hoewel de voor https benodigde rekenkracht relatief kleiner is geworden, heeft dat nog wel degelijk aandacht nodig. Zo wordt een aantal zaken bij de server en browser gecached om die relatief zware connection setup zoveel mogelijk te vermijden. Met twee pools van vier webservers is het echter lastig om die caches effectief te laten werken als ieder van die servers zelf de https-verwerking doet. Elke keer dat je request door een andere server afgehandeld wordt, met iets meer dan 2/3e kans, zou dan de in jouw browser bewaarde cache ongeldig zijn. Overigens zijn er wel manieren om ervoor te zorgen dat de loadbalancers steeds dezelfde server gebruiken voor specifieke gebruikers.
We waren echter al op zoek naar nieuwe application delivery controllers. Ondersteuning voor ssl offloading in combinatie met http/2 hoorde daarbij tot onze selectiecriteria. Met ssl offloading doet een proxy-server, in ons geval op de loadbalancers, het https-werk en wordt er daarna intern verder gecommuniceerd. Het voordeel daarbij is dat je in principe altijd op dezelfde server uitkomt voor https, ongeacht welke interne server je request daadwerkelijk afhandelt. Bovendien wordt het rekenwerk voor https dan op die plek gedaan, waardoor de webservers zich daar niet mee bezig hoeven te houden.
We zijn bij die zoektocht uitgekomen op Brocade Virtual Traffic Manager, kortweg vTM. Dat zijn softwarematige adc's die we op een drietal Dell R430's hebben geïnstalleerd. Die Dells hebben ieder twee Intel Xeon E5-2623 v3's met 4x 3GHz-cores, in totaal 24x cores en 48x threads, en daarmee ruim voldoende rekencapaciteit om naast de reguliere adc-taken ook al het verkeer te versleutelen.
We hebben deze nieuwe adc's al een paar weken geleden in gebruik genomen, zodat we in ieder geval zeker wisten dat ze technisch goed werken.
/i/2001095821.png?f=imagenormal)
Screenshot uit Brocades datasheet. Klik voor een grotere versie.
In tegenstelling tot bij onze vorige opstelling hebben nu alle drie de loadbalancers 'actief' verkeer. Het voordeel daarvan is dat we alle loadbalancers continu benutten en we er niet eentje niets laten doen zolang er geen problemen zijn. Helaas betekent dit ook dat we drie losse ip-adressen hebben, voor elke loadbalancer een. Dat betekent verder dat ieder van onze domeinen drie losse ip-adressen kent. Statistisch gezien zou daardoor slechts zo'n tien procent van alle bezoekers daadwerkelijk alle requests van tweakers.net, tweakimg.net en ic.tweakimg.net vanaf hetzelfde ip-adres krijgen. Daarmee zou opnieuw het voordeel van de enkele verbinding van http/2 wegvallen.
Gelukkig konden we de global server loadbalancing in de vTM's uitbreiden met wat extra scripting om zo afhankelijk van het ip-adres van de gebruiker een specifiek ip-adres van onze kant terug te geven. Een loadbalancer mag daarmee nog steeds uitvallen, dan wordt vanzelf een andere gebruikt, maar het betekent wel dat een bezoeker normaal gesproken uiteindelijk hetzelfde ip-adres en hetzelfde certificaat voor ieder van onze losse (sub)domeinen krijgt.
Het werkt in de praktijk helaas niet perfect zoals hier beschreven. Dat komt onder andere doordat gebruikers meestal meer dns-servers gebruiken, waarbij elke nameserver een ander adres van onze dns-server kan krijgen, waardoor de gebruiker uiteindelijk alsnog verschillende ip-adressen krijgt voor tweakers.net en tweakimg.net. We zullen daarom op den duur waarschijnlijk alsnog die extra domeinen opheffen. Eigenlijk moeten we dan ook gathering.tweakers.net opheffen, maar de vraag of we dat willen, vereist nog wat diepe bezinning 
Overigens kunnen we met deze vTM's ook automatisch nieuwe certificaten uploaden in de api, waardoor we, hoewel Brocade het zelf nog niet ondersteunt, wel al Let's Encrypt kunnen gebruiken in de ssl-offloading.
Mixed content
Het grootste praktische probleem met https is het concept 'mixed content'. Bij mixed content zijn er 'onveilige' elementen geladen in een 'veilige' pagina. Anders gezegd, er zitten elementen vanaf http-servers tussen. Hierbij bestaat er onderscheid tussen actieve en passieve mixed content. De lijst die gezien wordt als passief, is expliciet gespecificeerd tot onder andere plaatjes, video- en audiotags. Actieve mixed content is alle andere content die niet via https binnenkwam, zoals javascript, stylesheets, fonts, flash-files en iframes.
De passieve elementen worden door de meeste browsers alsnog getoond, hoewel ze onveilig waren geladen. Dat gaat dan wel gepaard met een indicatie dat de pagina niet goed beveiligd was. De actieve mixed content, zoals javascript en stylesheets, wordt door browsers geblokkeerd.
Met de introductie van https wilden we dat gelijk goed doen, dus geen actieve mixed content en zelfs geen passieve mixed content of simpel gezegd: overal op Tweakers een (groen) slotje in je browser.
Onze artikelen en de door gebruikers gemaakte content, zoals reacties, tweakblogs en forumtopics, bevatten doorgaans allerlei plaatjes. Bijna al die plaatjes komen vanaf http-urls. Als we niets zouden doen, zou bij al die content de 'niet veilig'-markering in browsers verschijnen.
/i/2001114537.png?f=imagenormal)
De Pricewatch-portal vóór deze aanpassing (links, met mixed content) en erna (zonder mixed content).
Van boven naar beneden: Firefox, Chrome en Edge.
Om dat te voorkomen moesten we flink aan de slag. Om te beginnen moeten alle url's die wij genereren, in onze code met https werken. Anders krijg je onnodige redirects van http naar https en worden afbeeldingen alsnog verkeerd aangeboden. Dat was een van de makkelijkere taken.
De moeilijkste taak was het aanpassen van alle bestaande artikelen en door gebruikers gemaakte content. Daarin moesten alle afbeeldingen, video's en andere elementen worden aangepast. We hebben flink wat code moeten schrijven om alle generaties van oude content om te zetten. Een voorbeeld zijn de oude artikelen waarin YouTube-video's staan. Daarin werd vaak nog de oude flash-based player gebruikt. Die hebben we niet alleen omgezet in https, maar ook gelijk in de nieuwe methode met iframes en html5-video.
Het moeilijkste was het aanpassen van alle bestaande artikelen en door gebruikers gemaakte content
Overigens hebben we elementen van sommige heel oude of zelden gebruikte sites vervangen door een linkje naar dat specifieke element. Het kan dus zijn dat er in oude artikelen of forumposts nu linkjes staan waar voorheen video's of andere elementen ingevoegd waren.
Https-camouflage-proxy
Het meest voorkomende type mixed content is afbeeldingen. Omdat ze zo belangrijk zijn voor de gebruikerservaring, wilden we die blijven tonen, maar dan wel via https. Die afbeeldingen komen echter niet alleen van onze eigen servers, maar van duizenden verschillende webservers. We weten van veel daarvan helemaal niet of ze https ondersteunen, en het testen daarop is een tijdrovende en lastige aangelegenheid. Bovendien zou er dan alsnog een deel overblijven zonder (goed werkende) https.
We konden daarom niet zomaar van elke afbeelding in de url het stukje 'http://' vervangen door 'https://'. Om die bijbehorende afbeeldingen toch te kunnen tonen, kregen we in een discussie met onze bezoekers de tip om een proxy te gebruiken. Wij kozen uiteindelijk voor de camouflage-proxy die Github heeft ontwikkeld om hetzelfde probleem op te lossen.
Deze zorgt ervoor dat onze servers de niet-https-afbeeldingen downloaden en daarna, vanuit ons netwerk, via https doorsturen naar de gebruiker. Om te voorkomen dat we alle afbeeldingen steeds opnieuw downloaden en jullie daarop moeten wachten, worden ze een tijdje in onze eigen loadbalancers gecachet. Hopelijk zien de bronsites ons op die manier niet te veel als scraper. Die time-out kunnen we uiteraard zelf kiezen; op dit moment hebben we hem op vierentwintig uur gezet.
Voor nieuwe forumposts doen we twee dingen. Net als de controle op de hoogte en breedte van afbeeldingen, controleren we nu ook of ze via https worden aangeboden. Is dat niet het geval, dan testen we gauw even met wat javascript in je browser of het plaatje wellicht toch via https werkt. Als dat niet zo is, komt er een melding om je te wijzen op die afbeelding. Omdat we begrijpen dat niet alle afbeeldingen via https werken, kun je die melding negeren en dan zetten wij 'm alsnog automatisch om via de camouflage-proxy.
Voor andere content willen we natuurlijk nog steeds graag dat je https gebruikt, maar hadden we nog geen eenvoudig toepasbaar meldingsysteem. Daarom zal daarvoor in principe altijd de camouflage-proxy gebruikt worden als er geen sprake is van https. Uiteraard kan dit in de toekomst nog veranderen.
Referrers en conclusie
Er zijn diverse gebruikers die eigen artikelen linken op Tweakers en gewend zijn om dan in hun analytics of serverlogs precies terug te kunnen zien waar hun bezoekers vandaan kwamen. Voor hen hebben we slecht nieuws; dat wordt een stuk minder informatief vanaf Tweakers.
Voorheen stuurden de meeste browsers een referrer mee met de url waar ze vandaan kwamen. Dat gedrag is anders zodra de bronpagina een https-pagina is en de doelpagina via http gaat. Dan sturen de meeste browsers juist helemaal geen referrer mee. Door te vertellen waar iemand vandaan komt, wordt tenslotte een stukje privé-informatie uitgelekt via die onbeveiligde verbinding. Voor links van https-pagina naar https-pagina worden standaard wel referrers doorgestuurd. Er zijn uiteraard instelmogelijkheden en plug-ins die dit gedrag veranderen, waardoor de meegegeven informatie nooit helemaal betrouwbaar was voor eigenaars van websites.
Wij hebben nu ook referrer-metatags toegevoegd. Dat hebben we enerzijds gedaan om het gedrag tussen http en https gelijker te maken, maar anderzijds om de privacy-impact in beide situaties te reduceren. Daarmee verzoeken we browsers om de referrer aan te passen aan de origin, bijvoorbeeld https://tweakers.net of https://gathering.tweakers.net, zonder verdere padinformatie. Het is dus nog wel zichtbaar dat iemand van Tweakers komt, maar niet meer precies vanaf welke pagina.
Het is nog wel zichtbaar dat iemand van Tweakers komt, maar niet meer vanaf welke pagina
Deze metatags zijn overigens een verzoek aan de browser. De browser kan zich via plug-ins of instellingen alsnog anders gedragen. Ook kunnen we niet precies specificeren wat de referrer moet worden, enkel welke stukjes van de referrer (niets, domein+protocol, alles) wat ons betreft mogen worden meegestuurd.
De enige uitzondering zijn de prijslijsten. Daarbij hebben we een zekere verantwoordelijkheid tegenover de diverse webshops. Als we melden dat honderd bezoekers hebben doorgeklikt, dan willen de winkels dat natuurlijk kunnen terugvinden in hun eigen informatie. De referrer is een van de methoden om dat te herleiden. Daarom laten we specifiek bij die prijslijsten de volledige referrer meesturen. Aangezien winkels toch al weten welk product aan hun kant werd opgevraagd, is het triviaal om te bepalen vanaf welke pagina dat op Tweakers had moeten zijn; de privacy-impact is dus erg beperkt. Door toch de hele referrer mee te laten sturen, ook naar http, maken we het voor de webwinkels wel makkelijker om te controleren of we de juiste bedragen in rekening brengen. Specifiek voor die pagina's plaatsen we daarom niet onze standaard-origin-when-cross-origin, maar de markering die vergelijkbaar is met het gedrag van vóór de https-site: unsafe-uri.
Conclusie
Al met al was het een behoorlijke klus om https goed te ondersteunen. Vooral het verhelpen van mixed content in de bijna achttien jaar aan forumposts en nieuwsberichten was een uitdaging. Daarin zaten verschillende generaties html-stijl en allerlei verwijzingen naar sites of afbeeldingen die ondertussen al lang niet meer bestaan.
Het is goed mogelijk dat we iets hebben gemist. Als dat zo is, dan horen we dat graag. In dit topic kun je ons daarvan op de hoogte brengen.
Ook kan de 'geef feedback'-knop met het i-tje gebruikt worden. Daarin kunnen specifieke elementen worden geselecteerd. Die knop is overigens voor niet-ingelogde bezoekers wat groter. Ook kan hij afhankelijk van de schermresolutie en tracker-instellingen juist verborgen zijn. In dat geval kan ook de 'Feedback'-link helemaal onder aan de pagina worden gebruikt.
/i/2001070375.png?f=imagegallery)
/i/2001095821.png?f=imagegallery)
/i/2001558181.png?f=fpa)
:strip_exif()/i/2001073909.jpeg?f=fpa)
/i/2000809531.png?f=fpa)
/i/1316504693.png?f=fpa)
En waarom letsencrypt? Je mag hier toch wel een deftig EV certificaat verwachten?
/u/1830/acm.png?f=community){kind=small}
/u/411953/crop6089ca36ea4b5_cropped.png?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}
:strip_icc():strip_exif()/u/343187/avatar.jpg?f=community){kind=avatar}
Juist omdat het Tweakers is verwacht ik een LetsEncrypt certificaat in plaats van een commerciele SSL boer.:strip_icc():strip_exif()/u/10917/crop562b75f07b9fd_cropped.jpeg?f=community){kind=small}
)
:strip_exif()/u/116104/opteron64_logo_180x196.thumbnail2.gif?f=community){kind=logo}
:strip_icc():strip_exif()/u/27548/php_60.jpg?f=community){kind=small}
:strip_exif()/u/7689/Copicon.gif?f=community){kind=small}
/u/89414/crop601ef6957a87f_cropped.png?f=community){kind=small}
/u/49730/babby%2520tux.png?f=community){kind=small}
/u/479292/Administrator_60x60.png?f=community){kind=small}
/u/507029/crop56967733a9fb9_cropped.png?f=community){kind=small}
:strip_exif()/u/56159/archer.gif?f=community){kind=small}
/u/407403/WAhack.png?f=community){kind=small}
:strip_icc():strip_exif()/u/86747/gonzo60.jpg?f=community){kind=small}
/u/94596/crop643fb12fd4e6d.png?f=community){kind=small}
/u/34216/avatar-60x60.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/25867/no_bugs_small.jpg?f=community){kind=small}
/u/246423/crop5979eb9e5c60f_cropped.png?f=community){kind=small}
/u/25932/icon.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/111342/crop59c23ae9896fe_cropped.jpeg?f=community){kind=small}
/u/67020/avatar_ec.png?f=community){kind=avatar}
/u/508326/02fe8676b9194155ae0a61dd1cfc9f8c.png?f=community){kind=small}
:strip_icc():strip_exif()/u/669180/crop5904ddeb1c8c8_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/94317/crop5ddbd733006db_cropped.jpeg?f=community){kind=small}
/u/304058/koku.png?f=community){kind=small}
/u/468514/crop67a52a3ca0480_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/781629/crop575fafd38556b_cropped.jpeg?f=community){kind=small}
/u/423394/avatar_60x60.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
/u/107495/godzilla%252060x60.png?f=community){kind=small}
:strip_icc():strip_exif()/u/109036/crop580efea56f6f9_cropped.jpeg?f=community){kind=small}
/u/148661/crop559fd5b259ff4.png?f=community){kind=small}
/u/115763/Untitled-4.png?f=community){kind=small}
:strip_icc():strip_exif()/u/61625/seph_ffvii.jpg?f=community){kind=small}
:strip_exif()/u/356502/crop5b17f4bc39e72_cropped.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/162143/crop5b6d888e9cc79_cropped.jpeg?f=community){kind=small}
/u/241825/Avatar_for_terrorist.png?f=community){kind=avatar}