HTTP status codes but as cats:
https://http.cat/

HTTP status codes but as cats:
https://http.cat/
HTTP/3 is everywhere but nowhere
Link: https://httptoolkit.com/blog/http3-quic-open-source-support-nowhere/
Discussion: https://news.ycombinator.com/item?id=43360251
iX-Workshop API-Sicherheit: OWASP Top 10 API Security Risks
Lernen Sie hands-on, wie Sie Schwachstellen in der API-Implementierung vermeiden und Angriffe abwehren.
System Administration
Week 7, HTTP and CDNs
After discussing the DNS, we now move on to #HTTP and HTTPS. While we don't have videos for these sections, hopefully the lecture slides can help you get an idea of what we're covering there. We review the basic HTTP protocol, peek at #QUIC and H3, and talk about load balancing and content delivery networks:
nee, dat is beslist niet stom! Er zijn maar weinig mensen die hier iets van snappen, en dat is precies het probleem.
Ook ervaren idioten zoals ik moeten te vaak diep graven om te zien of een website echt is of nep, en soms blijkt dat onmogelijk (zoals bij sommige webshops).
Als we naar het centrum gaan en daar een pand zien waarop "ING" of "HEMA" staat, dan zijn we *GEWEND* dat daar géén oplichtersbende in zit.
Ons risico om te worden belazerd is laag, omdat kwaadwillenden niet eenvoudig een pand kunnen huren, zoiets snel aan het licht komt en de pakkans groot is.
Maar zou jij geld pinnen uit een Geldmaat bevestigd aan de buitengevel van een pand van de Hells Angels gevestigd tussen een autosloperij en een pallethandel?
Op internet is de *ENIGE* aanwijzing die we hebben over de identiteit van een website, de domeinnaam die we zien in de adresbalk van de browser. We hebben géén idee meer waar een server staat en wat de nationaliteit van de huurder van de domeinnaam is.
On precies te zijn, een in DNS geldige website-domeinnaam is een (potentieel nietszeggende of juist misleidende) reeks karakters hooguit bestaande uit:
1) kleine letters (a-z);
2) cijfers (0-9);
3) het minteken;
4) de punt als *scheidingsteken*.
Een domeinnaam is een *alias* voor een IP-adres, net als "Maartje" in mijn lijst met contacten een alias is voor een telefoonnummer (ik vermoed een ander telefoonnummer achter "mijn" Maartje).
Stel Maartje neemt morgen een ander telefoonnummer, en een ander krijgt haar oude nummer. Als ik vervolgens "Maartje" bel, krijg ik een ander aan de lijn (als ik pech heb is dat iemand die m.b.v. AI de stem van Maartje exact imiteert en mij misleidt). Dit is een van de problemen met domeinnamen: soms vallen ze in verkeerde handen (zie https://security.nl/search?origin=frontpage&keywords=verlopen+domeinnaam).
Domeinnamen hebben een bijzondere eigenschap: ze zijn (als alles goed gaat) wereldwijd uniek - in tegenstelling tot "Maartje" of "Erik van Straten".
DNS is het wereldwijde "telefoonboek" om (onder meer), gegeven een domeinnaam, het huidige IP-adres van de server (waar de website actief op is) op te zoeken. Want computers op internet communiceren met elkaar middels IP-adressen, net zoals mobieltjes daar telefoonnummers voor gebruiken.
Het probleem blijft dat domeinnamen nietszeggend of bewust misleidend kunnen zijn (enkele "verse" voorbeelden in de screenshot onderaan deze toot).
Precies daarom gebruiken de meeste banken EV (Extended Validation) website-certificaten. Het laatste certificaat voor rabobank.nl zie je in https://crt.sh/?id=16445752040 (merk op dat dit certificaat geldig is voor maar liefst 155 verschillende domeinnamen, die je vindt door in die pagina te zoeken naar DNS: ).
Een website-certificaat kun je prima vergelijken met een *kopie* van een paspoort. De server stuurt dit ongevraagd naar de browser.
Er volgt echter een slimme wiskundige truc: de server *bewijst* aan de browser over het *originele* paspoort te beschikken (feitelijk een "private key"). Een crimineel heeft dus niets aan zo'n kopie.
In dat paspoort kunnen minder of meer gegevens staan (V staat voor Validated):
a) Domain V: alleen de domeinnaam (of meerdere domeinnamen).
b) Organization V: de domeinnaam/namen plus matig betrouwbare identificerende gegevens van de eigenaar van de website.
c) Extended V: de domeinnaam/namen plus redelijk betrouwbare identificerende gegevens van de eigenaar van de website.
d) QWAC (https://en.wikipedia.org/wiki/Qualified_website_authentication_certificate): de domeinnaam/namen plus maximaal betrouwbare identificerende gegevens van de eigenaar van de website.
Alles valt of staat met de betrouwbaarheid van de *certificaatuitgever* (een gemeenteambtenaar die valse paspoorten aan criminelen verkoopt kan ook desastreus zijn voor het vertrouwen in het systeem, voorbeeld: https://www.security.nl/posting/800253/Ambtenaar+die+valselijk+paspoorten+opmaakte+veroordeeld+tot+32+maanden+cel).
——————
Technisch uitstapje (als je nog zin hebt):
DNS snapt niets van IDN's (International Domain Names). Punycode is een truc in browsers om toch met "nep" domeinnamen zoals
https://münchen.de
en
https://βιβλιοχαρτοπωλειον.ελ (een Griekse "domeinnaam")
te kunnen werken. "Onder water" wordt daarvoor Punycode gebruikt, volgens https://www.charset.org/punycode zijn dat resp.
https://xn--mnchen-3ya.de
en
https://xn--mxabanrbcmcwrbdkn2c8b1b.xn--qxam
In certificaten voor IDN's vind je (stom genoeg) uitsluitend de Punycode representatie. Het is allemaal zo gemaakt dat het simpel *lijkt* - maar niet is, en dat is meestal iets waar criminelen van profiteren.
Ten slotte nog een wijdverbreid fabeltje: "met een certificaat wordt de https:// verbinding versleuteld". Dat is, al vele jaren, pertinente onzin.
Een (server- of client-) certificaat wordt uitsluitend gebruikt voor authenticatie (van de server of de client), het leveren van *bewijs* van identiteit.
Bij de moderne TLS v1.3 (waar steeds meer servers gebruik van maken voor https://) wordt de verbinding zelfs éérst versleuteld; pas dáárna stuurt de server diens kopie-paspoort (een kopie van het certificaat) naar de browser - over de reeds versleutelde verbinding dus.
P.S. emojies toegevoegd in een poging om de droogte van het technische geneuzel te beperken
In #HTTP land, this paper has surfaced and is being discussed:
"HTTP Conformance vs. Middleboxes: Identifying Where the Rules Actually Break Down"
Document:
Curiously old versions of most components were used as basis. Also relevant is @mnot's comments on the httpbis list:
https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0227.html
#videoclip #http #opendirectories
Indice de /
http://104.251.123.41/
Took the #Vim (and #Neovim) syntax highlighting plugin for #Hurl (https://hurl.dev/) files from their repo's contrib/ directory and made it into an actual Vim package that can be installed by simply cloning the repo, or adding a submodule to your dotfiles, whatever.
Ever wonder how the web actually works? It's all thanks to #HTTP — the secret sauce making everything from pet videos to API calls possible. My latest post breaks it all down in plain English. Check it out!
https://woodruff.dev/http-demystified-the-secret-sauce-of-the-web/
Au fait, connaissez-vous le code HTTP 451 ?
Wake, Boot, Repeat: Remote OS Selection with GRUB and ESP - What do you do when you need to choose an OS at boot but aren’t physically near yo... - https://hackaday.com/2025/03/03/wake-boot-repeat-remote-os-selection-with-grub-and-esp/ #networkhacks #linuxhacks #wakeonlan #esp8266 #network #linux #boot #grub #http #esp #wol
iX-Workshop: API-Design und -Entwicklung mit HTTP, REST und OpenAPI
Lernen Sie, wie man effiziente und benutzerfreundliche APIs entwickelt, HTTP- und REST-Standards anwendet und standardisierte Referenzdokumentationen erstellt.
There isn't much point to HTTP/2 past the load balancer
Link: https://byroot.github.io/ruby/performance/2025/02/24/http2-past-the-load-balancer.html
Discussion: https://news.ycombinator.com/item?id=43168533
I'm investigating HTTP Compression Dictionary Transport, where you can create a custom compression dictionary for your content and then send responses compressed with it. How large a dictionary helps? At least for my data, larger is better, but the gain diminishes quickly. https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ #http
Explication de ce que signifie l'origine d'une page web, concept essentiel pour bien comprendre les CORS qui donnent des sueurs froides à tant de développeurs alors qu'elles (ils ? ) sont essentielles pour la sécurité.
https://www.alsacreations.com/article/lire/1938-La-notion-d-origine-web-et-CORS.html
Which #HTTP status code do you expect, if you connect to a #IPv6 only Webserver via #IPv4.
Talking about the situation, where the Website only has an #AAAA record, but the Webserver is also addressable via IPv4 (for other Websites). So one could contact the Webserver via IPv4 and pass the the #DNS name of the IPv6 only Website as Host header, which is the scenario that i want to reject - but what status code is appropriate?