• Let’s Encrypt kortar livslängden på SSL-certifikat – stora förändringar väntar för webbplatser

    Från februari 2027 kommer Let’s Encrypt att börja utfärda SSL-certifikat som bara gäller i 64 dagar, jämfört med dagens 90 dagar. Under 2028 ska giltighetstiden kortas ytterligare, till 45 dagar. Förändringen ska göra internet säkrare, men innebär också att webbservrar måste förnya sina certifikat betydligt oftare.

    Varför behövs SSL-certifikat?

    När du besöker en webbplats som börjar med https:// används ett digitalt certifikat för att skapa en säker, krypterad förbindelse mellan din webbläsare och webbservern.

    Certifikatet hjälper webbläsaren att kontrollera att den kommunicerar med rätt webbplats. Samtidigt skyddar krypteringen information som skickas mellan användaren och servern, exempelvis lösenord, personuppgifter och betalningsinformation.

    En av världens största utfärdare av sådana certifikat är Let’s Encrypt, en kostnadsfri certifikattjänst som har gjort det möjligt för miljontals webbplatser att använda HTTPS utan att behöva köpa dyra certifikat.

    Hittills har Let’s Encrypt normalt utfärdat certifikat med en giltighetstid på 90 dagar. Men nu är det dags för nästa steg i utvecklingen.

    Från 90 dagar till 64 – och därefter 45

    Den 10 februari 2027 börjar Let’s Encrypt utfärda certifikat med en standardgiltighet på 64 dagar.

    Det innebär att alla nya certifikat som utfärdas från detta datum får den kortare giltighetstiden. Certifikat som redan har utfärdats påverkas däremot inte, utan fortsätter fungera fram till sina ordinarie utgångsdatum.

    Det sista certifikatet med 90 dagars giltighet förväntas löpa ut den 11 maj 2027.

    Under 2028 planeras ytterligare en förändring. Då ska standardgiltigheten kortas till endast 45 dagar.

    För en webbplatsägare innebär det att certifikaten behöver bytas ut allt oftare. Med 90 dagars giltighet handlar det teoretiskt om ungefär fyra certifikat per år. Med 45 dagars giltighet ökar antalet till drygt åtta.

    I praktiken behöver certifikaten dessutom förnyas innan de löper ut, vilket innebär ännu tätare förnyelsekontroller.

    Varför blir internet säkrare med kortare certifikat?

    Det kan verka märkligt att ett certifikat blir säkrare bara för att det slutar fungera tidigare. Förklaringen ligger i vad som händer om ett certifikat eller dess tillhörande privata nyckel hamnar i fel händer.

    Ett SSL-certifikat fungerar ungefär som en digital identitetshandling för en webbplats. Till certifikatet hör en privat krypteringsnyckel som webbservern använder för att bevisa sin identitet.

    Om en angripare lyckas stjäla den privata nyckeln kan den under vissa förutsättningar användas för att utge sig för att vara den riktiga webbplatsen.

    Ju längre certifikatet är giltigt, desto längre kan det potentiellt missbrukas.

    Genom att minska giltighetstiden från 90 till 45 dagar begränsas den maximala tiden då ett stulet certifikat kan vara användbart. Det ersätter inte behovet av att återkalla komprometterade certifikat, men ger ett extra skydd.

    Kortare giltighetstider minskar också konsekvenserna av certifikat som har utfärdats av misstag eller med felaktiga uppgifter.

    Automatisering blir allt viktigare

    För de flesta vanliga internetanvändare kommer förändringen inte att märkas alls.

    För webbplatsägare och systemadministratörer blir däremot fungerande automatisering ännu viktigare.

    Många Linuxservrar använder redan programmet Certbot för att automatiskt hämta och förnya certifikat från Let’s Encrypt.

    Certbot kommunicerar med certifikattjänsten genom ett standardiserat protokoll som heter ACME (Automatic Certificate Management Environment).

    När ett certifikat närmar sig sin förnyelsetid kan Certbot automatiskt begära ett nytt certifikat, genomföra nödvändig domänkontroll och installera det nya certifikatet.

    Om förnyelsen fungerar korrekt behöver administratören normalt inte göra någonting.

    Problemen kan däremot uppstå på servrar där någon har skrivit egna skript med fasta tidsintervall.

    Ett skript som exempelvis försöker förnya certifikatet var 80 dag kan fungera med dagens 90-dagarscertifikat, men kommer att misslyckas när certifikaten bara gäller i 64 dagar. Då hinner det gamla certifikatet löpa ut innan nästa förnyelseförsök.

    Resultatet kan bli att besökare möts av webbläsarens varning om att webbplatsens säkerhetscertifikat har gått ut.

    Ny teknik talar om när certifikatet ska förnyas

    För att göra övergången enklare rekommenderar Let’s Encrypt stöd för en funktion som heter ACME Renewal Info, förkortat ARI.

    Tekniken gör det möjligt för certifikatutfärdaren att meddela en ACME-klient när det är lämpligt att förnya ett visst certifikat.

    I stället för att klienten själv försöker gissa rätt tidpunkt kan den alltså få förnyelseinformation direkt från Let’s Encrypt.

    För system som saknar stöd för ARI rekommenderas i stället att certifikat förnyas när ungefär två tredjedelar av giltighetstiden har passerat.

    För ett certifikat som gäller i 64 dagar motsvarar det ungefär 42 dagar.

    Det är också viktigt att skilja mellan hur ofta ett förnyelseprogram körs och hur ofta certifikatet faktiskt byts ut. Certbot kan exempelvis kontrollera förnyelsebehovet varje dag utan att ett nytt certifikat behöver utfärdas vid varje kontroll.

    Även kontrollen av domännamn förändras

    När Let’s Encrypt utfärdar ett certifikat måste tjänsten först kontrollera att den som begär certifikatet verkligen har kontroll över det aktuella domännamnet.

    Kontrollen kan exempelvis ske genom att en särskild fil görs tillgänglig på webbservern eller genom att en särskild DNS-post skapas.

    I dag kan en godkänd domänkontroll återanvändas under en begränsad period på 30 dagar.

    Den perioden ska kortas till 10 dagar och senare, under 2028, till endast sju timmar.

    Det innebär att äldre domänkontroller inte kan återanvändas lika länge som tidigare.

    För moderna ACME-klienter som automatiskt kan genomföra nya kontroller väntas förändringen normalt inte innebära några större problem.

    Viktiga datum att hålla reda på

    DatumFörändring
    14 oktober 202664-dagarscertifikat införs i Let’s Encrypts testmiljö.
    10 februari 2027Nya certifikat får som standard 64 dagars giltighet.
    11 maj 2027De sista 90-dagarscertifikaten väntas löpa ut.
    Under 2028Standardgiltigheten kortas till 45 dagar.

    Vad behöver du som driver en webbserver göra?

    Driver du en webbserver med exempelvis Apache eller Nginx under Linux är det klokt att redan nu kontrollera hur certifikatförnyelsen fungerar.

    Använder du Certbot kan du exempelvis testa förnyelseprocessen med kommandot:

    sudo certbot renew --dry-run

    Kommandot genomför ett test av certifikatförnyelsen utan att ersätta de certifikat som används i produktion.

    Du kan också kontrollera vilka certifikat Certbot hanterar och när de går ut:

    sudo certbot certificates

    På system som använder systemd kan du undersöka om automatisk förnyelse är aktiverad:

    systemctl list-timers --all | grep certbot

    Om förnyelsen sker genom cron bör du kontrollera att schemaläggningen inte bygger på ett fast intervall som riskerar att vara längre än certifikatets giltighetstid.

    Det är också viktigt att kontrollera att webbservern använder de nya certifikaten efter förnyelsen. I vissa konfigurationer krävs en automatisk omladdning av Apache eller Nginx.

    En förändring som visar vart internet är på väg

    När HTTPS började bli vanligt kunde SSL-certifikat ha en giltighetstid på flera år. Det innebar att samma certifikat och ibland samma privata nyckel kunde användas under mycket lång tid.

    Utvecklingen har därefter gått mot allt kortare giltighetstider.

    Let’s Encrypts kommande övergång till 64 och senare 45 dagar är en del av denna utveckling.

    Förändringen innebär visserligen att certifikat behöver förnyas oftare, men målet är också att minska beroendet av manuellt underhåll.

    I framtiden är tanken att certifikathantering ska fungera ungefär som andra automatiska säkerhetsuppdateringar: systemet sköter arbetet i bakgrunden, utan att användaren behöver tänka på det.

    För webbplatsbesökaren är målet enkelt: säkrare anslutningar utan någon märkbar förändring. För serveradministratören är budskapet lika tydligt – tiden för manuell certifikatförnyelse håller på att rinna ut.

    > FAKTA: LET’S ENCRYPT_

    TJÄNST: Let’s Encrypt

    FUNKTION: Kostnadsfria TLS/SSL-certifikat för HTTPS

    NUVARANDE GILTIGHET: 90 dagar

    10 FEBRUARI 2027: 64 dagar

    UNDER 2028: 45 dagar

    TESTMILJÖ: 64-dagarscertifikat från 14 oktober 2026

    PROTOKOLL: ACME

    AUTOMATISERING: Certbot och andra ACME-klienter

    REKOMMENDATION: Automatisk förnyelse med stöd för ACME Renewal Info (ARI)

    root@linux:~# certbot renew –dry-run
    # Testar automatisk certifikatförnyelse
  • Hur skulle världen se ut utan öppen källkod?

    Föreställ dig att din mobiltelefon, din TV, din router och stora delar av internet plötsligt måste byggas om från grunden. Inte därför att tekniken har försvunnit, utan därför att ingen längre får dela med sig av programkod.

    Tänk dig att du var tvungen att åka tillbaka till 90-talet, där du bara kunde spela ”Snake” på din Nokia-telefon och där telefonens mjukvara var mer stängd än Nordkoreas gränser.

    Eller tänk dig att du var tvungen att åka tillbaka till 70-talet, där du bara kunde se sovjetisk dockteater som Drutten och Krokodilen , eller knäpp dårar som satt och lekte att de var vilse i en pannkaka som barnprogram. Det fanns bara statlig skit-TV att titta på. Att kunna välja valfritt innehåll på din smart-TV var bara att glömma.

    Bilden ovan är inspirerad av Kalle Anka-filmen Der Fuehrer’s Face.

    Det låter kanske som ett tankeexperiment långt från vardagen. Men en stor del av den digitala värld vi använder varje dag bygger just på idén att programmerare, företag och universitet kan dela programkod med varandra.

    Det är det som brukar kallas öppen källkod, eller open source.

    De flesta tänker kanske först på Linux. Någon kanske föreställer sig en dator med ett lite ovanligt skrivbord och en terminal full av kommandon.

    Men Linux på en vanlig PC är bara en liten del av historien.

    Öppen källkod finns i mobiltelefoner, smart-TV-apparater, routrar, webbservrar, bilar, nätverksutrustning, datacenter och mängder av elektroniska apparater.

    Ofta märker vi det inte alls.

    Linux finns redan i din ficka

    Den som använder en Androidtelefon använder i praktiken Linux varje dag.

    Android bygger nämligen på Linuxkärnan.

    Kärnan är den del av ett operativsystem som arbetar närmast själva hårdvaran. Den sköter exempelvis minnet, processorn, lagringen och kommunikationen mellan olika delar av datorn eller telefonen.

    När du startar en app, ansluter till ett trådlöst nätverk eller tar ett fotografi finns det därför Linuxkod långt nere i systemet som hjälper till att få allt att fungera.

    Det betyder inte att Android och Linux är samma sak. Android består av många fler delar, varav Google och andra företag har utvecklat en stor del.

    Men längst ned i systemet finns Linux. Det är en ganska anmärkningsvärd utveckling.

    Ett operativsystem som började som ett hobbyprojekt i början av 1990-talet kom så småningom att bli en av grundstenarna i världens mest använda mobilplattform.

    TV:n är egentligen en dator

    Den moderna TV-apparaten har också förändrats dramatiskt.

    Förr tog en TV emot en signal och visade en bild. I dag är en smart-TV i praktiken en dator med stor bildskärm.

    Den har processor, arbetsminne, lagring, nätverkskort, grafikkrets, appar och ofta en webbläsarmotor.

    Och bakom kulisserna finns ofta Linux och andra open source-komponenter.

    När du startar SVT Play, Netflix eller YouTube på en TV kan programvaran alltså vila på samma typ av teknisk grund som en webbserver eller en Androidtelefon.

    För konsumenten spelar det kanske ingen större roll vilket operativsystem som finns inuti apparaten.

    För tillverkaren spelar det desto större roll.

    Att utveckla ett komplett operativsystem från början är ett mycket omfattande arbete.

    Genom att använda Linux kan en TV-tillverkare börja med en redan fungerande kärna och koncentrera sig på det som gör den egna produkten speciell.

    Routern i hallen innehåller mer programvara än man tror

    Samma sak gäller den lilla routern som står hemma i hallen.

    Den kanske ser ganska enkel ut, men den måste klara förvånansvärt mycket.

    Den ska bland annat hantera:

    • trådlösa nätverk
    • Ethernet
    • IP-adresser
    • DNS
    • DHCP
    • brandvägg
    • IPv4
    • IPv6
    • webbgränssnitt för inställningar

    Dessutom ska allt fungera stabilt dygnet runt.Det finns onda makte

    Många routrar bygger därför på Linux och små open source-program som exempelvis BusyBox.

    BusyBox kan beskrivas som en verktygslåda med många klassiska Unix-kommandon i ett mycket kompakt format. Det gör programmet användbart i små apparater där minne och lagringsutrymme är begränsade.

    Så när internetanslutningen hemma fungerar som den ska kan en betydande del av arbetet utföras av öppen källkod utan att användaren någonsin ser det.

    Internet byggdes inte av ett enda företag

    Öppen källkod har kanske haft allra störst betydelse för internet.

    När man besöker en webbplats ser man bilder, text, menyer och formulär.

    Bakom sidan finns däremot ofta en lång kedja av program.

    Servern kan köra Linux eller FreeBSD.

    Webbservern kan vara Apache eller Nginx.

    Webbplatsen kan vara skriven i PHP eller Python.

    Informationen kan lagras i MariaDB, MySQL eller PostgreSQL.

    Kommunikationen kan skyddas av kryptografiska bibliotek som bygger på öppen källkod.Det innebär att en mycket stor del av den moderna webben har kunnat byggas utan att varje företag först behövt köpa ett helt paket av proprietär serverprogramvara.

    Det förändrade spelreglerna.

    Plötsligt kunde en vanlig PDet finns onda makteC bli en server

    Under 1980-talet och början av 1990-talet var Unix ofta förknippat med stora och dyra arbetsstationer från företag som Sun, HP och IBM.

    Sedan kom Linux och de fria BSD-systemen.

    Plötsligt kunde en ganska vanlig persondator fungera som en riktig Unix-liknande server.

    En student kunde installera Linux eller FreeBSD och använda datorn som:

    • webbserver
    • e-postserver
    • DNS-server
    • router
    • brandvägg
    • filserver
    • databasserver

    Det var betydelsefullt av två skäl. För det första blev tekniken billigare. För det andra blev den tillgänglig för människor som ville lära sig.

    Man behövde inte längre arbeta på ett universitet eller ett stort företag för att få tillgång till ett avancerat fleranvändarsystem med nätverk, programmeringsverktyg och serverprogramvara.

    En gammal PC hemma kunde bli ett komplett laboratorium för internet.

    Det skapade en generation programmerare och systemadministratörer som kunde experimentera på egen hand.

    FreeBSD – den mindre kända släktingen

    Linux får ofta mest uppmärksamhet, men det finns andra fria Unix-liknande system som också har haft mycket stor betydelse.

    Ett av de viktigaste är FreeBSD.

    FreeBSD har sina historiska rötter i BSD, Berkeley Software Distribution, som utvecklades vid University of California, Berkeley.

    BSD kom att spela en viktig roll i Unixhistorien och i utvecklingen av nätverksteknik.

    Än i dag används FreeBSD och BSD-baserad teknik i servrar, lagringssystem, nätverksutrustning och konsumentprodukter.

    BSD-systemen använder dessutom licenser som gör det relativt enkelt för företag att använda koden i egna kommersiella produkter.

    Det har bidragit till att BSD-teknik ibland finns på platser där användaren aldrig ser namnet BSD.

    Till och med Apple står på Unixgrund

    Apple brukar knappast förknippas med öppen källkod på samma sätt som Linux.

    Ändå finns där tydliga kopplingar.

    macOS och iOS bygger på Darwin, som innehåller teknik med rötter i bland annat BSD och Unix.

    Apple har naturligtvis utvecklat stora mängder egen programvara ovanpå denna grund.

    Men det illustrerar en viktig poäng:

    Öppen källkod och kommersiell programvara är inte motsatser.

    De existerar ofta tillsammans. Ett företag kan använda öppen teknik längst ned i systemet och bygga en egen produkt ovanpå. Det är ungefär som att bygga ett hus.

    Det är sällan ekonomiskt rimligt för varje byggföretag att börja med att uppfinna sitt eget tegel, sina egna skruvar och sin egen betong.

    På samma sätt behöver inte varje teknikföretag skriva en egen nätverksstack, kompilator eller operativsystemkärna.

    Molnet består också av vanliga datorer

    Vi talar ofta om ”molnet” som om det vore någon abstrakt plats där information svävar omkring. I verkligheten består molnet av enorma mängder fysiska servrar i datacenter. Och en stor del av dessa servrar kör Linux.

    När du använder en app i mobilen kan något ganska intressant därför hända. Telefonen kör Android ovanpå Linux. Den ansluter till en router som kanske också kör Linux. Trafiken passerar nätverksutrustning som kan innehålla öppen programvara. Till slut når den en server i ett datacenter som mycket väl också kör Linux. Linux kan alltså finnas i flera steg i samma kommunikation utan att användaren någonsin ser det.

    En viktig anledning till internets snabba utveckling

    På 1990-talet och 2000-talet blev en särskild kombination av program mycket vanlig på webbservrar:

    • Linux
    • Apache
    • MySQL
    • PHP

    De fyra begynnelsebokstäverna gav namnet LAMP.

    Det var en enkel men kraftfull idé. Man kunde bygga en komplett webbplattform utan att först betala stora licensavgifter. Det gjorde det möjligt för små företag, föreningar, studenter och privatpersoner att starta webbtjänster med mycket små ekonomiska resurser. En idé kunde provas på en gammal dator. Fungerade den kunde verksamheten växa.

    Misslyckades den hade man åtminstone inte lagt stora summor på programlicenser. Detta bidrog till den snabba experimentlusta som kännetecknade internets utveckling.

    Verktygen bakom programmen är också öppna

    När man talar om öppen källkod är det lätt att bara tänka på färdiga program. Men minst lika viktiga är verktygen som används för att skapa program. Kompilatorn GCC har exempelvis spelat en central roll i utvecklingen av fria operativsystem.

    LLVM har senare blivit en annan mycket viktig kompilatorplattform.

    Programspråk som Python, PHP och Ruby har gjort programmering tillgänglig för miljontals människor.

    Och Git har förändrat hur programmerare samarbetar. Git skapades ursprungligen för utvecklingen av Linuxkärnan. I dag används det av företag och utvecklare över hela världen.

    Ett verktyg som skapades för ett öppet projekt blev alltså en standardteknik i stora delar av programvaruindustrin.

    Databasen du använder utan att veta om det

    En annan nästan osynlig open source-produkt är SQLite.

    SQLite är en mycket liten databas som kan byggas direkt in i ett program. Den behöver ingen separat databasserver och är därför lämplig i mobiltelefoner, webbläsare och andra program.

    Det gör SQLite till ett av de tydligaste exemplen på hur öppen källkod kan bli så framgångsrik att användaren slutar märka den.

    Man kanske aldrig installerar SQLite själv. Man kanske aldrig ser dess namn. Ändå kan flera program på datorn eller telefonen använda den varje dag.

    Öppen källkod handlar egentligen om att dela kunskap

    Det är lätt att beskriva open source som ”gratis program”. Men priset är egentligen inte den mest intressanta delen. Det viktigaste är möjligheten att återanvända kunskap. Tänk dig att hundra företag behöver lösa samma tekniska problem.

    Om alla arbetar helt isolerat måste samma problem lösas hundra gånger. Om de däremot kan samarbeta kring en gemensam grund behöver arbetet bara göras en gång. Sedan kan varje företag bygga vidare på resultatet.

    Det innebär inte att alla företag måste dela allt. De kan fortfarande konkurrera med design, funktioner, tjänster och egna lösningar. Men den gemensamma grundtekniken behöver inte uppfinnas om och om igen.

    Det är en av de viktigaste anledningarna till att öppen källkod har fått så stor betydelse.

    Vad skulle hända om den försvann?

    Det går förstås inte att veta exakt hur världen hade sett ut utan open source.

    Mobiltelefoner hade förmodligen fortfarande funnits.
    Internet hade funnits. Smarta TV-apparater hade sannolikt också utvecklats. Men mycket hade blivit dyrare och mer omständligt. Fler företag hade behövt utveckla egna operativsystem.

    Fler hade varit beroende av licenser från stora programvaruföretag.

    Små företag hade haft högre kostnader för att starta nya tjänster.

    Studenter och hobbyprogrammerare hade haft svårare att experimentera med avancerad teknik.Och en större del av den digitala infrastrukturen hade sannolikt kontrollerats av ett mindre antal företag.

    Det betyder inte att öppen källkod alltid är bättre

    Samtidigt ska man inte göra open source till någon universallösning. Öppen källkod kan innehålla buggar precis som annan programvara. Projekt kan överges.

    Säkerhetsproblem kan finnas oupptäckta under lång tid.

    Att källkoden är öppen betyder att den kan granskas.

    Det betyder inte automatiskt att någon faktiskt har granskat varje rad.

    Den verkliga styrkan ligger snarare i att ingen enskild aktör behöver ha fullständig kontroll över tekniken.

    Koden kan studeras, förbättras, vidareutvecklas och i många fall leva vidare även om ett företag eller en ursprunglig utvecklare försvinner.

    Den största framgången äDet finns onda makter att vi knappt märker den

    Det kanske mest fascinerande med open source är att dess största framgång samtidigt gjort den nästan osynlig.

    Ingen tänker på Linux när en smart-TV startar.
    Ingen funderar på BSD när en nätverksapparat skickar ett paket över internet.
    Ingen tänker på SQLite när telefonen sparar information.
    Ingen tänker på Git när ett företag publicerar en ny version av ett program.

    Tekniken bara finns där. Och kanske är det just så man känner igen verkligt grundläggande infrastruktur.
    Vi tänker inte på elnätet varje gång vi tänder en lampa.
    Vi tänker inte på avloppssystemet varje gång vi öppnar en kran. På samma sätt tänker vi sällan på den enorma mängd öppen programvara som håller den digitala världen igång.
    Linux, FreeBSD, GNU och tusentals andra projekt skapade inte ensamma den moderna IT-världen. Men utan dem hade den sannolikt varit dyrare, mer sluten och betydligt svårare för vanliga människor att lära sig, förändra och bygga vidare på.
    Och kanske är det den viktigaste betydelsen av öppen källkod:

    Den gjorde avancerad datorteknik till något fler människor kunde delta i – inte bara använda.

    > FAKTARUTA: ÖPPEN KÄLLKOD_

    > Linux
    Finns i allt från Androidtelefoner och servrar till routrar, smart-TV-apparater och annan elektronik.

    > FreeBSD och BSD
    Har haft stor betydelse för Unix, nätverksteknik, servrar, lagringssystem och kommersiella produkter.

    > Internet
    En stor del av internet bygger på öppen källkod som Linux, FreeBSD, Apache, Nginx, PHP, Python, PostgreSQL och MariaDB.

    > Android
    Android använder Linuxkärnan och har gjort Linux till en del av vardagen för miljarder mobilanvändare.

    > Utvecklingsverktyg
    Git, GCC, LLVM och mängder av öppna bibliotek används varje dag för att utveckla både fria och kommersiella program.

    > Den stora skillnaden
    Öppen källkod gör det möjligt att studera, förbättra och återanvända teknik i stället för att uppfinna samma lösningar om och om igen. █

  • HTTP/2 Bomb – ny attack kan få webbservrar att krokna på sekunder

    En ny attack mot HTTP/2, kallad HTTP/2 Bomb, visar hur moderna webbprotokoll kan utnyttjas på oväntade sätt. Genom att missbruka komprimering och flödeskontroll kan en angripare få webbservrar som Nginx, Apache, IIS, Envoy och Pingora att snabbt förbruka stora mängder minne – i vissa fall på bara några sekunder.

    En ny typ av överbelastningsattack mot HTTP/2 visar hur en till synes effektiv webbteknik kan vändas mot de servrar den är tänkt att hjälpa. Attacken kallas HTTP/2 Bomb och kan i värsta fall få stora webbservrar att snabbt förbruka enorma mängder minne.

    Det handlar inte om ett klassiskt angrepp där angriparen skickar enorma datamängder mot en server. I stället utnyttjas funktioner som redan finns i HTTP/2-protokollet. Med relativt små mängder trafik kan en angripare få servern att lägga beslag på stora mängder RAM-minne. När minnet tar slut börjar tjänsten svara långsamt, krascha eller sluta svara helt.

    Vad är HTTP/2?

    HTTP är protokollet som webbläsare och webbservrar använder för att prata med varandra. När du öppnar en webbsida skickar webbläsaren förfrågningar till servern, som sedan svarar med HTML, bilder, skript, stilmallar och annan data.

    HTTP/2 är en modernare version av HTTP. Den infördes för att göra webben snabbare och mer effektiv. Bland annat kan flera förfrågningar skickas över samma anslutning, och sidans olika delar kan hanteras mer parallellt än tidigare.

    För vanliga användare betyder HTTP/2 oftast snabbare webbplatser. För serveradministratörer betyder det bättre prestanda – men också en mer komplicerad teknikstack.

    Så fungerar HTTP/2 Bomb

    HTTP/2 Bomb bygger på två delar som tillsammans blir farliga.

    Den första delen handlar om HPACK, den metod som HTTP/2 använder för att komprimera HTTP-huvuden. Huvuden är metadata som skickas med varje webbförfrågan, exempelvis information om webbläsare, cookies, språk och vilken sida som efterfrågas.

    Komprimering är normalt en bra sak. Den gör trafiken mindre och snabbare. Men i det här fallet kan angriparen skicka små komprimerade referenser som får servern att skapa betydligt större interna datastrukturer i minnet.

    Den andra delen handlar om flödeskontroll i HTTP/2. Flödeskontroll används för att styra hur snabbt data får skickas mellan klient och server. Attacken utnyttjar detta för att få servern att hålla kvar svar och minnesobjekt längre än normalt.

    Resultatet blir att servern tvingas reservera minne, men inte får möjlighet att frigöra det i tid. Attacken fungerar därför ungefär som att någon fyller ett lager med paket, men samtidigt blockerar utgången så att inget kan skickas vidare.

    Varför är attacken allvarlig?

    Det allvarliga är att attacken inte kräver extrem bandbredd. En angripare behöver inte nödvändigtvis ha ett stort botnät eller skicka enorma mängder trafik. Poängen är i stället att få servern att göra mycket mer arbete än klienten själv gör.

    I tester har forskarna visat att flera välkända webbservrar och HTTP/2-implementationer kan pressas till mycket hög minnesanvändning på kort tid. Bland de berörda nämns Nginx, Apache HTTP Server, Microsoft IIS, Envoy och Cloudflare Pingora.

    Det gör attacken särskilt oroande för publika webbplatser, API, lastbalanserare och reverse proxies som exponerar HTTP/2 direkt mot internet.

    Problemet ligger inte bara i stora headers

    Många skydd mot den här typen av attacker bygger på att begränsa hur stora HTTP-huvuden får vara. Det är logiskt: om en klient skickar för mycket metadata kan servern avvisa förfrågan.

    Men HTTP/2 Bomb visar att det inte alltid räcker.

    Attacken kan använda många små headerfält i stället för ett fåtal stora. Varje litet fält kan verka ofarligt, men tillsammans skapar de mycket intern hantering i servern. Minnesförbrukningen kommer alltså inte bara från den faktiska datamängden, utan även från serverns egna objekt, tabeller och bokföring.

    Särskilt cookie-hantering har pekats ut som en faktor i vissa implementationer. HTTP/2 tillåter att Cookie-huvuden delas upp i flera fält. Om dessa inte räknas korrekt mot serverns gränser kan angriparen skapa väldigt många interna headerobjekt utan att slå i de skydd som administratören tror finns på plats.

    Apache och Nginx har fått åtgärder

    För Apache HTTP Server spåras problemet som CVE-2026-49975. En åtgärd finns i mod_http2 2.0.41, där cookie-huvuden räknas mot gränsen för antal tillåtna requestfält. För miljöer som inte kan uppgradera direkt rekommenderas att HTTP/2 tillfälligt stängs av med:

    För Nginx har problemet åtgärdats i Nginx 1.29.8 genom en ny begränsning för maximalt antal headers. Den nya direktivet max_headers har ett standardvärde på 1000. För system där uppgradering inte är möjlig är en tillfällig åtgärd att stänga av HTTP/2:

    Det är viktigt att se detta som tillfälliga skydd. Den långsiktiga lösningen är att uppdatera berörda komponenter när säkerhetsfixar finns tillgängliga.

    Alla plattformar hade inte färdiga patchar direkt

    Vid den första publiceringen fanns inte bekräftade patchar för alla berörda system. För IIS, Envoy och Cloudflare Pingora var läget mer oklart i samband med offentliggörandet. Senare uppgifter pekade på att Envoy hade släppt patchar, men att validering fortfarande pågick.

    Det här visar ett återkommande problem i modern webbinfrastruktur: många tjänster är beroende av flera lager. En webbplats kan till exempel använda en CDN-tjänst, en reverse proxy, en lastbalanserare, en applikationsserver och ett internt API-lager. Alla dessa kan hantera HTTP/2 på olika sätt.

    Därför räcker det inte alltid att bara uppdatera “webbservern”. Administratören måste förstå var HTTP/2 faktiskt termineras och vilka komponenter som tar emot trafiken direkt från internet.

    Vad bör administratörer göra?

    Den som driver publika HTTP/2-tjänster bör kontrollera om Nginx, Apache, IIS, Envoy, Pingora eller andra HTTP/2-komponenter används i kedjan.

    Viktigast är att:

    • uppdatera till versioner där tillgängliga fixar finns,
    • införa tydliga gränser för antal headers per förfrågan,
    • kontrollera att Cookie-huvuden räknas korrekt,
    • övervaka ovanlig minnesanvändning,
    • och tillfälligt stänga av HTTP/2 om ingen säker fix finns tillgänglig.

    Att stänga av HTTP/2 kan påverka prestandan, men är i många fall bättre än att låta en publik tjänst vara sårbar för en attack som kan tömma serverns minne på kort tid.

    En påminnelse om att snabbare inte alltid betyder säkrare

    HTTP/2 Bomb är ett tydligt exempel på att optimeringar i protokoll kan få oväntade säkerhetskonsekvenser. Funktioner som komprimering, multiplexning och flödeskontroll är byggda för att göra webben snabbare och mer effektiv.

    Men när samma funktioner kombineras på fel sätt kan de skapa asymmetri: klienten skickar lite data, medan servern tvingas reservera mycket minne och hålla kvar resurser länge.

    Det är just den asymmetrin som gör HTTP/2 Bomb farlig. Attacken handlar inte om att skrika högst, utan om att få servern att arbeta ihjäl sig i tysthet.

    För vanliga användare är detta inget man själv kan skydda sig mot i webbläsaren. För driftansvariga är budskapet däremot tydligt: kontrollera HTTP/2-konfigurationen, uppdatera berörda komponenter och se till att gränser för headers verkligen fungerar i praktiken.

    https://www.openwall.com/lists/oss-security/2026/06/03/3

    Faktaruta: HTTP/2 Bomb

    Typ av hot: Denial-of-service-attack, DoS.

    Berörda tekniker: HTTP/2, HPACK, flödeskontroll och hantering av HTTP-headers.

    Berörda system: Nginx, Apache HTTP Server, Microsoft IIS, Envoy och Cloudflare Pingora.

    Så fungerar attacken: Angriparen skickar små HTTP/2-förfrågningar som får servern att skapa och behålla stora mängder data i minnet.

    Konsekvens: Servern kan snabbt få slut på RAM-minne och börja svara långsamt, krascha eller sluta svara helt.

    Viktiga åtgärder: Uppdatera berörda komponenter, sätt tydliga gränser för antal headers och stäng tillfälligt av HTTP/2 om ingen säker fix finns.

    Apache: Problemet spåras som CVE-2026-49975. Åtgärd finns i mod_http2 2.0.41.

    Nginx: Åtgärdat i Nginx 1.29.8 med direktivet max_headers.

    Rekommendation: Publika HTTP/2-tjänster bör kontrolleras och uppdateras så snart som möjligt.

  • Debian 13.5 släppt – 247 uppdateringar gör Trixie säkrare och stabilare

    Debian 13.5 är här – en underhållsutgåva som samlar 103 säkerhetsfixar och 144 stabilitetsuppdateringar för Debian 13 “Trixie”. Det handlar inte om nya funktioner eller ett nytt utseende, utan om något minst lika viktigt: ett tryggare och mer stabilt Linuxsystem. För den som redan uppdaterar regelbundet är mycket redan installerat, men för nya installationer blir Debian 13.5 den bästa och mest aktuella startpunkten.

    Debian 13, med kodnamnet Trixie, har fått sin femte punktutgåva: Debian 13.5. Det är ingen ny version med stora nyheter eller förändrat utseende, utan en samlad underhållsuppdatering som gör systemet säkrare, stabilare och mer pålitligt.

    Den nya utgåvan innehåller 103 säkerhetsfixar och 144 stabilitetsuppdateringar. För vanliga användare betyder det framför allt att kända sårbarheter täpps till och att problem i viktiga systemkomponenter rättas.

    Vad är en punktutgåva?

    Debian fungerar lite annorlunda än många andra operativsystem. När en stabil Debian-version har släppts kommer den inte hela tiden med nya funktioner. I stället prioriteras säkerhet och stabilitet.

    En punktutgåva, som Debian 13.5, kan därför beskrivas som en uppdaterad installationsskiva. Den samlar ihop rättningar som redan har skickats ut via Debians vanliga uppdateringskanaler.

    Det betyder att den som redan kör Debian 13 och regelbundet installerar uppdateringar troligen redan har fått de flesta ändringarna.

    Viktiga program har fått säkerhetsfixar

    Debian 13.5 innehåller uppdateringar för många centrala paket. Bland annat berörs:

    Apache, OpenSSH, Nginx, glibc, systemd, sudo, Python 3.13, FreeRDP, Exim, jq, X.Org Server, curl, rsync, firewalld, bubblewrap, libarchive, libcap2 och nano.

    Det handlar alltså inte bara om småprogram i marginalen, utan om komponenter som ofta används i servrar, arbetsstationer och nätverkstjänster.

    Apache, OpenSSH och systemd får viktiga rättningar

    Webbservern Apache får flera säkerhetsfixar. Dessa rör bland annat use-after-free-fel, möjlig privilegieeskalering, förbikoppling av autentisering, NULL pointer-problem, HTTP response splitting och läsning utanför minnesgränser.

    Även OpenSSH, som används för säker fjärrinloggning, har uppdaterats. Där finns rättningar kopplade till bland annat scp, kommandoexekvering, hantering av nyckelalgoritmer, ProxyJump och authorized_keys.

    En annan viktig komponent är systemd, som i Debian 13.5 uppdateras till version 257.13. Den uppdateringen åtgärdar bland annat problem som rör möjlig kodkörning och en sårbarhet där systemd-nspawn kunde användas för att ta sig ut från en isolerad miljö till värdsystemet.

    glibc och DNS-hantering förbättras

    Systembiblioteket glibc är en av de mest grundläggande delarna i ett Linuxsystem. Nästan alla program är på något sätt beroende av det.

    I Debian 13.5 rättas flera problem i glibc, bland annat sådant som rör DNS-svar, ogiltiga DNS-värdnamn och ett fel som kunde leda till ett så kallat assertion failure.

    Det kan låta tekniskt, men poängen är enkel: när grundläggande bibliotek blir mer robusta blir hela systemet mer driftsäkert.

    Även installationsprogrammet är uppdaterat

    Debian Installer har också uppdaterats. Det betyder att den som installerar Debian från nya Debian 13.5-avbilder får med de senaste rättningarna direkt från början.

    För servrar och nya installationer är detta praktiskt. Man slipper installera från en äldre avbild och sedan hämta en stor mängd uppdateringar direkt efter installationen.

    Inga nya funktioner – och det är poängen

    Debian 13.5 ska inte ses som en ny Debian-version i vanlig mening. Den introducerar inga stora nya funktioner och ändrar inte systemets grundläggande beteende.

    Det är i stället en klassisk Debian-uppdatering: försiktig, stabil och fokuserad på att hålla systemet tryggt över tid.

    För många användare är det just detta som gör Debian attraktivt. Man får inte alltid det senaste först, men man får ett system där stabilitet och säkerhet väger tungt.

    Så uppdaterar du ett befintligt Debian 13-system

    Om du redan kör Debian 13 räcker det normalt att uppdatera systemet som vanligt:

    sudo apt update && sudo apt upgrade
    

    Har du redan installerat säkerhetsuppdateringar löpande finns det troligen inte särskilt mycket nytt att hämta. Debian 13.5 samlar i stor utsträckning sådant som redan har skickats ut till användarna.

    Nya installationsavbilder finns tillgängliga

    För den som vill installera Debian från början finns nya netinst-avbilder för Debian 13.5. Dessa är avsedda för användare som vill installera ett grundsystem och sedan själva välja paket, skrivbordsmiljö och tjänster.

    Netinst finns för flera arkitekturer, bland annat:

    amd64, arm64, armhf, ppc64el, riscv64 och s390x.

    För den som vill ha ett mer färdigt skrivbordssystem finns även Live-avbilder med skrivbordsmiljöer som GNOME, KDE, LXDE, Xfce, Cinnamon och MATE. Dessa är tillgängliga för AMD64.

    Automatiska säkerhetsuppdateringar är klokt

    Debian 13.5 visar också varför regelbundna uppdateringar är viktiga. Många säkerhetshål märks inte direkt för användaren, men kan ändå vara allvarliga om de lämnas öppna.

    På servrar och datorer som alltid är uppkopplade kan det därför vara klokt att aktivera automatiska säkerhetsuppdateringar. Då installeras viktiga säkerhetsfixar snabbare, utan att man själv behöver komma ihåg att kontrollera varje dag.

    Sammanfattning

    Debian 13.5 är ingen spektakulär version, men den är viktig. Med 103 säkerhetsfixar och 144 stabilitetsuppdateringar stärker den Debian 13 “Trixie” på flera centrala områden.

    För befintliga användare är rådet enkelt: håll systemet uppdaterat. För nya installationer är Debian 13.5 den bästa startpunkten, eftersom den innehåller de senaste rättningarna redan från början.

    https://www.debian.org/News/2026/20260516

    Nerladdnings länkar finns linux.se wiki :

    https://wiki.linux.se/Debian

    Teknisk faktaruta: Debian 13.5

    Distribution: Debian GNU/Linux

    Version: Debian 13.5

    Kodnamn: Trixie

    Typ av utgåva: Punktutgåva / underhållsutgåva

    Innehåll: 103 säkerhetsfixar och 144 stabilitetsuppdateringar

    Fokus: Säkerhet, buggfixar och förbättrad systemstabilitet

    Berörda paket: Apache, OpenSSH, Nginx, glibc, systemd, sudo, Python 3.13, curl, rsync, Exim, X.Org Server och flera andra

    Nya funktioner: Nej, Debian 13.5 är främst en samlad uppdatering av befintliga paket

    Uppdateringskommando:

    sudo apt update && sudo apt upgrade
  • Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till.

    För de flesta internetanvändare är Nginx osynligt. Ändå är det ofta just Nginx som står mellan webbläsaren och den webbplats man besöker. Programmet fungerar som en effektiv trafikdirigent: det tar emot förfrågningar, skickar dem vidare till rätt server och ser till att svaren kommer tillbaka snabbt.

    Nginx har länge varit känt som webbserver och reverse proxy. En reverse proxy står framför en eller flera servrar och tar emot trafik från internet. Den kan till exempel skicka besökare vidare till rätt webbserver, avlasta systemet eller hantera krypterade HTTPS-anslutningar.

    Med Nginx 1.31 introduceras en funktion som gör att programmet även kan användas på ett annat sätt: som HTTP forward proxy.

    Vad är en forward proxy?

    En forward proxy fungerar från andra hållet jämfört med en reverse proxy. I stället för att skydda och styra trafiken in till en webbplats används den av klienter som vill nå ut till internet.

    Man kan likna det vid en reception. I stället för att varje dator kontaktar webben direkt skickar den sin begäran till proxyn. Proxyn gör sedan själva kontakten med omvärlden och skickar tillbaka svaret.

    Detta kan användas för att:

    samla internettrafik via en central punkt
    kräva inloggning innan trafik släpps vidare
    logga eller styra åtkomst
    skapa kontrollerade miljöer för företag, skolor eller labb

    Den nya modulen ngx_http_tunnel_module gör det möjligt för Nginx att hantera sådan trafik via CONNECT-metoden. CONNECT används ofta när HTTPS-trafik ska tunnlas genom en proxy.

    Det betyder att Nginx nu får en mer flexibel roll. Från att främst ha varit en servernära komponent kan den även användas som kontrollerad mellanhand för klienttrafik.

    Inloggning till proxyn

    En viktig del av den nya funktionen är stöd för proxyautentisering. Det innebär att användaren kan behöva logga in innan proxyn tillåter trafik.

    I Nginx 1.31 kan detta göras med direktiv som:

    auth_basic
    satisfy
    auth_delay

    För en administratör betyder det att forward proxy-funktionen inte behöver vara helt öppen. Det är viktigt, eftersom en öppen proxy snabbt kan missbrukas för anonym trafik, spam, attacker eller kringgående av nätverksregler.

    Med autentisering kan proxyn i stället användas i mer kontrollerade miljöer där bara godkända användare får tillgång.

    Smartare lastbalansering med least_time

    En annan nyhet i Nginx 1.31 är direktivet least_time i upstream-blocket. Det låter Nginx välja backend-server baserat på svarstid.

    Traditionell lastbalansering kan exempelvis bygga på att skicka varannan förfrågan till server A och varannan till server B. Det fungerar i enkla miljöer, men tar inte alltid hänsyn till hur servrarna faktiskt mår.

    Om en server är långsam, hårt belastad eller har problem kan svarstiden bli högre. Med least_time kan Nginx i stället väga in hur snabbt servrarna svarar och styra trafiken mot den som för tillfället verkar mest effektiv.

    Det är lite som att välja kö i mataffären. Man går inte nödvändigtvis till den kö som ser kortast ut, utan till den som faktiskt rör sig snabbast.

    Funktionen kan användas både för vanlig HTTP-trafik och för stream-trafik.

    ALPN för säkra upstream-anslutningar

    För stream-modulerna introduceras även direktivet proxy_ssl_alpn.

    ALPN står för Application-Layer Protocol Negotiation. Det är en teknik som används under TLS-anslutningar för att komma överens om vilket protokoll som ska användas.

    Det kan exempelvis vara relevant när en server kan tala flera olika protokoll över samma krypterade anslutning. Med proxy_ssl_alpn får administratören bättre kontroll över vilket protokoll Nginx ska välja när den ansluter till SSL-baserade upstream-servrar.

    Säkerhetsfixar i flera moduler

    Nginx 1.31 är inte bara en funktionsrelease. Den innehåller också flera säkerhetsfixar.

    En av de åtgärdade bristerna är CVE-2026-42926, en sårbarhet i HTTP/2-hanteringen i ngx_http_proxy_module. Problemet är kopplat till direktivet proxy_set_body och kan beskrivas som en request injection-sårbarhet.

    En sådan sårbarhet innebär att en angripare i vissa situationer kan påverka hur en förfrågan tolkas eller vidarebefordras. I proxyprogramvara är detta särskilt känsligt, eftersom proxyn står mitt i trafikflödet.

    En annan viktig fix gäller CVE-2026-42945, en heap buffer overflow i ngx_http_rewrite_module. Minnesfel av detta slag kan i värsta fall leda till att angripare får möjlighet att köra kod.

    Även följande sårbarheter har åtgärdats:

    CVE-2026-42946 – heap buffer overread i ngx_http_scgi_module och ngx_http_uwsgi_module
    CVE-2026-42934 – buffer overread kopplad till UTF-8-avkodning i charset_map i ngx_http_charset_module
    CVE-2026-40460 – adressförfalskning i HTTP/3 och QUIC connection migration
    CVE-2026-40701 – use-after-free vid DNS-svarshantering när ssl_ocsp används

    Det tekniska språket kan låta avskräckande, men i praktiken handlar det om samma grundproblem som ofta förekommer i systemprogramvara: data måste tolkas exakt rätt, minne måste hanteras korrekt och nätverkstrafik får inte kunna lura servern att göra något oväntat.

    HTTP/2 och HTTP/3 blir striktare

    HTTP/2 och HTTP/3 är modernare versioner av webbens grundprotokoll. De är byggda för högre prestanda och bättre hantering av många samtidiga anslutningar.

    Men när gamla och nya protokoll möts uppstår ibland risker. Vissa headers som används i HTTP/1.1 hör inte hemma i HTTP/2 och HTTP/3. Om de ändå släpps igenom kan det skapa oväntade beteenden i kedjan mellan klient, proxy och backend-server.

    Därför avvisar Nginx 1.31 nu HTTP/2- och HTTP/3-förfrågningar som innehåller anslutningsspecifika headers som:

    Connection
    Proxy-Connection
    Keep-Alive
    Transfer-Encoding
    Upgrade

    Headern TE tillåts bara när den är satt till trailers.

    Detta gör hanteringen mer strikt och minskar risken för felaktig tolkning av trafik.

    WebDAV får hårdare kontroller

    Även WebDAV-modulen har förstärkts. WebDAV gör det möjligt att hantera filer på en server via HTTP, till exempel kopiera, flytta eller ändra resurser.

    I Nginx 1.31 avvisas nu COPY– och MOVE-förfrågningar om källan och destinationen är samma plats, eller om de har ett förälder–barn-förhållande.

    Det kan låta som en liten detalj, men den typen av kontroller är viktiga. Utan dem kan filoperationer skapa logiska konflikter, oändliga kopieringsproblem eller andra oönskade effekter.

    Mindre brus i loggarna

    Versionen innehåller också mindre förändringar som påverkar drift och felsökning. Bland annat har loggnivån sänkts för vissa SSL-relaterade fel.

    För systemadministratörer kan detta vara välkommet. Alla fel är inte lika allvarliga, och för höga loggnivåer kan göra det svårare att hitta verkligt viktiga problem i stora loggfiler.

    Det finns även ett nytt configure-alternativ för att kunna inaktivera upstream sticky-modulen, samt fixar för HTTP/2 backend keepalive när proxy_set_body eller proxy_pass_request_body används.

    Varför är Nginx 1.31 viktig?

    Nginx 1.31 är intressant därför att den både breddar vad Nginx kan göra och stärker säkerheten i befintliga funktioner.

    Forward proxy-stödet gör att Nginx kan användas i fler nätverksroller än tidigare. Samtidigt visar säkerhetsfixarna hur komplex modern webbtrafik har blivit. HTTP/2, HTTP/3, TLS, OCSP, QUIC, WebDAV och olika proxyfunktioner skapar tillsammans ett kraftfullt men avancerat ekosystem.

    Ju fler lager som finns i trafikkedjan, desto viktigare blir det att varje del tolkar data på rätt sätt.

    Sammanfattning

    Nginx 1.31 är en viktig mainline-version för administratörer och tekniskt intresserade. Den stora nyheten är stödet för HTTP forward proxy via ngx_http_tunnel_module, men minst lika viktigt är de många säkerhetsfixarna i HTTP/2, HTTP/3, OCSP och flera centrala moduler.

    För den som driver Nginx i produktion är detta en version att granska noggrant. Särskilt gäller det installationer som använder avancerad proxyhantering, HTTP/2, HTTP/3, WebDAV, SCGI, uWSGI eller OCSP.

    Nginx fortsätter därmed att utvecklas från en snabb webbserver till ett allt mer mångsidigt verktyg för modern internettrafik.

    https://github.com/nginx/nginx/releases/tag/release-1.31.0

    Teknisk faktaruta: Nginx 1.31

    Version: Nginx 1.31

    Utgåva: Mainline-release

    Största nyheten: HTTP forward proxy-stöd via ngx_http_tunnel_module och CONNECT-metoden.

    Proxyautentisering: Stöd via auth_basic, satisfy och auth_delay.

    Lastbalansering: Nytt least_time-direktiv för att balansera trafik baserat på svarstid.

    Stream-moduler: Nytt proxy_ssl_alpn-direktiv för ALPN-val mot SSL-upstreams.

    Säkerhetsfixar: Åtgärdar sårbarheter i HTTP/2, HTTP/3, OCSP, WebDAV, rewrite-, proxy-, charset-, SCGI- och uWSGI-moduler.

    Berörda CVE:er: CVE-2026-42926, CVE-2026-42945, CVE-2026-42946, CVE-2026-42934, CVE-2026-40460 och CVE-2026-40701.

    Rekommendation: Administratörer som använder Nginx med HTTP/2, HTTP/3, OCSP, WebDAV eller avancerade proxyfunktioner bör granska uppdateringen noggrant.

  • NGINX 1.30 – snabbare, säkrare och smartare webb

    Den nya versionen av NGINX markerar ett viktigt steg för hur framtidens webb ska fungera. Med fokus på hastighet, säkerhet och modern teknik introducerar version 1.30 flera förbättringar som påverkar allt från hur snabbt webbsidor laddas till hur väl användarnas integritet skyddas.

    Den nya stabila versionen av NGINX, version 1.30, har släppts och för med sig en rad förbättringar som gör webben både snabbare och säkrare. NGINX är idag en av världens mest använda webbservrar och driver över 30 procent av alla webbplatser, vilket gör varje uppdatering betydelsefull för en stor del av internet.

    Snabbare webb med Early Hints

    En av de mest spännande nyheterna är stöd för HTTP Early Hints, även kallat statuskod 103. Det innebär att servern kan börja skicka information till webbläsaren innan hela sidan är färdigbehandlad.

    I praktiken betyder det att webbläsaren kan börja ladda viktiga resurser, som stilmallar och skript, tidigare än förut. Resultatet blir kortare laddningstider och en snabbare upplevelse för användaren.

    Starkare integritet med Encrypted ClientHello

    En annan viktig nyhet är stöd för Encrypted ClientHello (ECH). Trots att HTTPS redan krypterar mycket av trafiken har vissa delar tidigare varit synliga, till exempel vilken webbplats användaren försöker nå.

    Med ECH krypteras även denna information, vilket gör det svårare för utomstående att övervaka surfvanor. Det är ett viktigt steg mot en mer privat och säker internetanvändning.

    Smartare trafikhantering

    NGINX 1.30 introducerar också förbättrad hantering av trafik mellan servrar. En ny funktion är så kallade sticky sessions, som ser till att en användare konsekvent kopplas till samma server i ett kluster.

    Detta är särskilt viktigt för tjänster där sessioner spelar roll, som inloggningar eller e-handel. Dessutom har stödet för HTTP/2 utökats till kommunikationen mellan servrar, vilket gör interna system snabbare och mer effektiva.

    Förbättringar i HTTP/2 och HTTP/3

    Den nya versionen innehåller flera förbättringar för både HTTP/2 och HTTP/3. Dessa inkluderar bättre stabilitet, färre buggar och effektivare hantering av dataöverföring.

    Även tekniska problem som tidigare kunnat orsaka krascher eller ineffektiv kommunikation har åtgärdats, vilket bidrar till en mer robust webbupplevelse.

    Starkare kryptering och TLS-stöd

    NGINX 1.30 förbättrar också stödet för modern kryptering. Bland nyheterna finns certifikatkomprimering, vilket kan snabba upp säkra anslutningar, samt bättre kompatibilitet med framtida versioner av krypteringsbibliotek som OpenSSL.

    Dessutom introduceras nya variabler och förbättrad hantering av hur servrar identifieras vid säkra anslutningar.

    Små förbättringar med stor effekt

    Utöver de större funktionerna innehåller uppdateringen många mindre förbättringar. Till exempel är keep-alive nu aktiverat som standard, vilket förbättrar prestandan genom att återanvända anslutningar.

    Flera buggar har också rättats, bland annat inom gRPC, cachehantering och proxyfunktioner, vilket gör systemet mer stabilt i praktisk användning.

    Varför det spelar roll

    Eftersom NGINX används av en så stor del av internet får dessa förbättringar bred påverkan. För användare innebär det snabbare laddningstider, bättre säkerhet och en mer stabil upplevelse.

    För utvecklare och företag innebär det effektivare verktyg, modernare teknikstöd och färre tekniska problem att hantera.

    Sammanfattning

    NGINX 1.30 markerar ett tydligt steg framåt för webbteknik. Med förbättrad prestanda, starkare integritetsskydd och modernare protokollstöd bidrar uppdateringen till ett snabbare, säkrare och mer tillförlitligt internet.

    Teknisk fakta: NGINX 1.30

    Vad är NGINX?
    NGINX är en webbserver och reverse proxy som används för att leverera webbsidor, hantera trafik och agera mellanhand mellan användare och backend-servrar. Den är känd för sin höga prestanda, låga resursanvändning och förmåga att hantera många samtidiga anslutningar. NGINX används ofta även som lastbalanserare och cache för att snabba upp webbapplikationer.


    Version: 1.30

    Gren: Ny stabil branch

    Huvudfunktioner:
    HTTP Early Hints (snabbare laddning), Encrypted ClientHello (förbättrad integritet), sticky sessions (stabil sessionshantering), HTTP/2 till backend-servrar

    Transport: Multipath TCP

    Standard upstream: HTTP/1.1 med keep-alive aktiverat

    TLS/SSL:
    Certifikatkomprimering, stöd för OSSL_STORE, förbättrad SNI-hantering, nya variabler för signaturalgoritmer och kompatibilitet med framtida OpenSSL-versioner

    HTTP/2 & HTTP/3:
    Förbättrad stabilitet, buggfixar, bättre hantering av headers och anslutningar, samt förbättrad QUIC-integration

    Övrigt:
    Upstream keepalive aktiverat som standard, förbättrad cachehantering, fixar för gRPC och proxyfunktioner

  • Installera Wiki.js på debian eller Ubuntu

    Introduktion

    Wiki.js är en modern, snabb och modulär wiki-mjukvara med öppen källkod. Den bygger på Node.js, lagrar innehåll i Git och Markdown och stöder flera databasmotorer som PostgreSQL, MySQL och SQLite. Wiki.js kan distribueras lokalt, i molnet eller i containermiljöer (Docker/Kubernetes), och stöder autentisering via LDAP, OAuth2, SAML med flera.

    I denna guide installerar vi Wiki.js på Debian 12 eller Ubuntu 22.04, med val mellan PostgreSQL eller MySQL som databas, och Nginx eller Apache som webbserver. Vi visar också hur du aktiverar SSL med Let’s Encrypt.

    Förutsättningar

    • En Debian- eller Ubuntu-server med root eller sudo
    • Ett domännamn som pekar till servern (exempel: wiki.example.com)
    • Portarna 80 och 443 öppna i brandväggen

    Steg 1: Installera Node.js

    Wiki.js kräver Node.js version 16 eller senare. Här använder vi version 18:

    curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
    sudo apt install -y nodejs
    

    Bekräfta installationen:

    node -v
    

    Steg 2: Installera databas

    Alternativ A: PostgreSQL (rekommenderat)

    sudo apt install -y postgresql postgresql-contrib
    sudo -u postgres psql
    

    Inuti psql:

    CREATE DATABASE wikijs;
    CREATE USER wikijs WITH PASSWORD 'sakerlösenord';
    ALTER ROLE wikijs SET client_encoding TO 'utf8';
    ALTER ROLE wikijs SET default_transaction_isolation TO 'read committed';
    ALTER ROLE wikijs SET timezone TO 'UTC';
    GRANT ALL PRIVILEGES ON DATABASE wikijs TO wikijs;
    \q
    

    Alternativ B: MySQL / MariaDB

    sudo apt install -y mariadb-server
    sudo mysql -u root -p
    

    Inuti MySQL:

    CREATE DATABASE wikijs CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
    CREATE USER 'wikijs'@'localhost' IDENTIFIED BY 'sakerlösenord';
    GRANT ALL PRIVILEGES ON wikijs.* TO 'wikijs'@'localhost';
    FLUSH PRIVILEGES;
    EXIT;
    

    Steg 3: Installera Wiki.js

    sudo mkdir -p /opt/wikijs && cd /opt/wikijs
    sudo curl -s https://wiki.js.org/install.sh | sudo bash
    

    Fyll i databasuppgifter beroende på om du använder PostgreSQL eller MySQL.

    Steg 4: Testa att Wiki.js kör lokalt

    ss -tulpn | grep 3000
    

    Om Wiki.js körs, visas att Node.js lyssnar på 127.0.0.1:3000.

    Steg 5: Reverse proxy med Nginx eller Apache

    Alternativ A: Nginx

    sudo apt install -y nginx
    sudo nano /etc/nginx/sites-available/wikijs
    

    Innehåll:

    server {
        listen 80;
        server_name wiki.example.com;
    
        location / {
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
    
    sudo ln -s /etc/nginx/sites-available/wikijs /etc/nginx/sites-enabled
    sudo nginx -t && sudo systemctl reload nginx
    

    Alternativ B: Apache

    sudo apt install -y apache2
    sudo a2enmod proxy proxy_http proxy_wstunnel rewrite headers
    

    Skapa konfiguration:

    sudo nano /etc/apache2/sites-available/wikijs.conf
    

    Innehåll:

    <VirtualHost *:80>
        ServerName wiki.example.com
    
        ProxyPreserveHost On
        ProxyRequests Off
        ProxyPass / http://127.0.0.1:3000/
        ProxyPassReverse / http://127.0.0.1:3000/
    
        ErrorLog ${APACHE_LOG_DIR}/wikijs.error.log
        CustomLog ${APACHE_LOG_DIR}/wikijs.access.log combined
    </VirtualHost>
    
    sudo a2ensite wikijs.conf
    sudo systemctl reload apache2
    

    Steg 6: Aktivera HTTPS med Let’s Encrypt

    Installera Certbot:

    sudo apt install -y certbot python3-certbot-nginx python3-certbot-apache
    

    För Nginx:

    sudo certbot --nginx -d wiki.example.com
    

    För Apache:

    sudo certbot --apache -d wiki.example.com
    

    Testa automatisk förnyelse:

    sudo certbot renew --dry-run
    

    Steg 7: Slutför installationen i webbläsaren

    Öppna din webbläsare och gå till:

    https://wiki.example.com
    

    Skapa administratörsanvändare och slutför konfigurationen.

    Slutsats

    Du har nu installerat Wiki.js på Debian eller Ubuntu med PostgreSQL eller MySQL, samt Apache eller Nginx som reverse proxy. Med Let’s Encrypt är installationen säkrad via HTTPS. Wiki.js är redo att användas för både intern dokumentation och publika kunskapsbaser.

    Glöm inte att hålla systemet uppdaterat och konfigurera regelbundna säkerhetskopior.

    Mer information och dokumentation: https://docs.requarks.io/

    Fakta om Wiki.js

    Wiki.js är en modern wiki-motor med öppen källkod, utvecklad av Requarks. Den första versionen lanserades 2016 och har sedan dess blivit ett populärt val för både organisationer och enskilda användare som behöver en effektiv dokumentationsplattform.

    Funktioner

    • Byggd med Node.js för hög prestanda och låg resursförbrukning.
    • Stöd för databaser som PostgreSQL, MySQL och SQLite.
    • Versionshantering via Git – dokumenthistorik kan spåras och återskapas.
    • Modulbaserad arkitektur – välj själv vilka funktioner som ska aktiveras.
    • Stöd för användarautentisering via LDAP, OAuth2, SAML med flera.
    • Webbgränssnittet är responsivt och fungerar både på dator och mobil.
    • Kan installeras på egen server, i molnmiljö eller med Docker/Kubernetes.

    Vad är Markdown?

    Markdown är ett enkelt markeringsspråk som gör det möjligt att skriva strukturerad text med minimal syntax. Det används i Wiki.js för att skapa och redigera innehåll utan att behöva skriva HTML. Nedan är ett exempel:

    # Rubriknivå 1
    ## Rubriknivå 2
    
    **Fet text**, _kursiv text_
    
    - Punkt 1
    - Punkt 2
    
    [Länktext](https://exempel.se)
      

    Markdown är läsbart även i råform, vilket gör det smidigt att hantera dokument både via webben och i Git-repositorier.

    Mer information finns på js.wiki och daringfireball.net.

Etikett: Nginx

  • Let’s Encrypt kortar livslängden på SSL-certifikat – stora förändringar väntar för webbplatser

    Från februari 2027 kommer Let’s Encrypt att börja utfärda SSL-certifikat som bara gäller i 64 dagar, jämfört med dagens 90 dagar. Under 2028 ska giltighetstiden kortas ytterligare, till 45 dagar. Förändringen ska göra internet säkrare, men innebär också att webbservrar måste förnya sina certifikat betydligt oftare. Varför behövs SSL-certifikat? När du besöker en webbplats som…

  • Hur skulle världen se ut utan öppen källkod?

    Föreställ dig att din mobiltelefon, din TV, din router och stora delar av internet plötsligt måste byggas om från grunden. Inte därför att tekniken har försvunnit, utan därför att ingen längre får dela med sig av programkod. Tänk dig att du var tvungen att åka tillbaka till 90-talet, där du bara kunde spela ”Snake” på…

  • HTTP/2 Bomb – ny attack kan få webbservrar att krokna på sekunder

    En ny attack mot HTTP/2, kallad HTTP/2 Bomb, visar hur moderna webbprotokoll kan utnyttjas på oväntade sätt. Genom att missbruka komprimering och flödeskontroll kan en angripare få webbservrar som Nginx, Apache, IIS, Envoy och Pingora att snabbt förbruka stora mängder minne – i vissa fall på bara några sekunder. En ny typ av överbelastningsattack mot…

  • Debian 13.5 släppt – 247 uppdateringar gör Trixie säkrare och stabilare

    Debian 13.5 är här – en underhållsutgåva som samlar 103 säkerhetsfixar och 144 stabilitetsuppdateringar för Debian 13 “Trixie”. Det handlar inte om nya funktioner eller ett nytt utseende, utan om något minst lika viktigt: ett tryggare och mer stabilt Linuxsystem. För den som redan uppdaterar regelbundet är mycket redan installerat, men för nya installationer blir…

  • Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till. För de…

  • NGINX 1.30 – snabbare, säkrare och smartare webb

    Den nya versionen av NGINX markerar ett viktigt steg för hur framtidens webb ska fungera. Med fokus på hastighet, säkerhet och modern teknik introducerar version 1.30 flera förbättringar som påverkar allt från hur snabbt webbsidor laddas till hur väl användarnas integritet skyddas. Den nya stabila versionen av NGINX, version 1.30, har släppts och för med…

  • Installera Wiki.js på debian eller Ubuntu

    Introduktion Wiki.js är en modern, snabb och modulär wiki-mjukvara med öppen källkod. Den bygger på Node.js, lagrar innehåll i Git och Markdown och stöder flera databasmotorer som PostgreSQL, MySQL och SQLite. Wiki.js kan distribueras lokalt, i molnet eller i containermiljöer (Docker/Kubernetes), och stöder autentisering via LDAP, OAuth2, SAML med flera. I denna guide installerar vi…