Weben er mye sikrere enn for et år siden

[Harald Brombach (digi.no)]

Mer enn halvparten av sidelastingene er kryptert.

Weben er mye sikrere enn for et år siden

[tommyb]

Nettleseren brukes kanskje mest til å lese nyheter, og foreløpig er det få nettaviser som leverer alt innhold over HTTPS.

Men dette kommer.

 

@ http://www.digi.no/artikler/weben-er-mye-sikrere-enn-for-et-ar-siden/363979

 

Just do it™ 

[endrebjo]

https://letsencrypt.org/

[ignoreme]

 

Nettleseren brukes kanskje mest til å lese nyheter, og foreløpig er det få nettaviser som leverer alt innhold over HTTPS.

Men dette kommer.

 

@ http://www.digi.no/artikler/weben-er-mye-sikrere-enn-for-et-ar-siden/363979

 

Just do it™ 

Det kommer nok. Jeg ser at tek.no er i gang, selv om de enda leverer en hel del innhold over http, spesielt fra img.gfx.no og sentry.tu.no.

 

Det jeg derimot virkelig IKKE forstår, er at de ikke rewriter alle HTTP requester til HTTPS på diskusjon.no! All trafikk på diskusjon.no burde gå over https, eksplisitt.

 

Tek.no bør også fjerne støtten for RFC4 cipheren. Alle er enig om at den er utrygg.

[Bjørn A. Johansen]

Ulempene med HTTPS er primært økt kompleksitet og ressursbehov.

 

Jeg har migrert flere store, komplekse nettsteder over til HTTPS i noen år og holder en del foredrag om hvordan man gjør dette. Jeg lurer derfor på hva dere legger i økt kompleksitet og ressursbehov?

 

Det mest «komplekse» jeg har erfart består gjerne i å konfigurere lastbalanserere/reverse proxies og applikasjoner riktig hvis TLS termineres tidlig og webapplikasjonen mottar ukryptert trafikk. Dette er normalt veldig fort gjort, og vil deretter spille helt fint. Det kan være utfordrende å migrere alt innholdet på et komplekst nettsted til HTTPS, men når det først er gjort, har jeg ikke opplevd at HTTPS fører til noen økt kompleksitet.

 

Noen økte ressursbehov har jeg aldri vært borti, heller ikke hørt om noen andre som har opplevd det, så det hadde vært interessant å høre mer om hva dere har erfart eller hørt om. Hvis dere mener CPU-/RAM-/nettverksbelasting er dette neglisjerbart.

[Harald Brombach (digi.no)]

Jeg har migrert flere store, komplekse nettsteder over til HTTPS i noen år og holder en del foredrag om hvordan man gjør dette. Jeg lurer derfor på hva dere legger i økt kompleksitet og ressursbehov?

Det mest «komplekse» jeg har erfart består gjerne i å konfigurere lastbalanserere/reverse proxies og applikasjoner riktig hvis TLS termineres tidlig og webapplikasjonen mottar ukryptert trafikk. Dette er normalt veldig fort gjort, og vil deretter spille helt fint. Det kan være utfordrende å migrere alt innholdet på et komplekst nettsted til HTTPS, men når det først er gjort, har jeg ikke opplevd at HTTPS fører til noen økt kompleksitet.

 

Noen økte ressursbehov har jeg aldri vært borti, heller ikke hørt om noen andre som har opplevd det, så det hadde vært interessant å høre mer om hva dere har erfart eller hørt om. Hvis dere mener CPU-/RAM-/nettverksbelasting er dette neglisjerbart.

 

Bare det å huske å fornye sertifikater, utgjør økt kompleksitet for nettsteder som ikke har gjort dette tidligere. Ikke all kompleksitet er teknisk handler om bits og megahertz.

 

Det gjelder også ressursbruk. Arbeidstimer er også en ressurs. Per Buer hos Varnish skrev nylig et kommentar her om at det for mange ikke bare er å skru det på: 

 

https://www.diskusjon.no/index.php?showtopic=1744314&do=findComment&comment=23524085

 

Det er godt mulig at økt bruk av maskinvareressurser er en myte, men jeg kjenner til nettsteder som har ment at det er nødvendig å bytte servere før HTTPS kan skrus på. Samtidig er det mulig at serverne deres var på nippet til å være overbelastet i utgangspunktet ...

[endrebjo]

Bare det å huske å fornye sertifikater, utgjør økt kompleksitet for nettsteder som ikke har gjort dette tidligere. Ikke all kompleksitet er teknisk handler om bits og megahertz.

Dere skal ikke trenge å huske å fornye sertifikater. Fornyelse av sertifikater er noe som bør skje automatisk.

For Let's Encrypt: https://certbot.eff.org/docs/using.html#renewing-certificates

[tommyb]

Dere skal ikke trenge å huske å fornye sertifikater. Fornyelse av sertifikater er noe som bør skje automatisk.

For Let's Encrypt: https://certbot.eff.org/docs/using.html#renewing-certificates

 

 

Min erfaring er at det er lettere å få hjelp av statlige tjenester, enn å fornye et sertifikat hos vår leverandør. Ikke bare den tekniske prosessen, men den organisatoriske prosessen er plagsom. Prosessen involverer hotseat-swapping mellom teknisk ansvarlig, fakturaansvarlig og oppringing fra amerikansk telefonbot som skal ha meg til å lese inn navnet mitt på tape. Og da har vi bare domenevalidert sertifikat (DV), ikke organisasjonsvalidert (OV) eller utvidet validering (EV). 

 

Jeg tviler ikke på at det kan gjøres mer automatisert men vår leverandør hadde ikke engang mulighet til å opprette brukerkonto for å huske kontaktinformasjon o.l., fram til forrige gang vi fornyet sertifikatene. 

[Bjørn A. Johansen]

 

Dere skal ikke trenge å huske å fornye sertifikater. Fornyelse av sertifikater er noe som bør skje automatisk.

For Let's Encrypt: https://certbot.eff.org/docs/using.html#renewing-certificates

 

 

Min erfaring er at det er lettere å få hjelp av statlige tjenester, enn å fornye et sertifikat hos vår leverandør. Ikke bare den tekniske prosessen, men den organisatoriske prosessen er plagsom. Prosessen involverer hotseat-swapping mellom teknisk ansvarlig, fakturaansvarlig og oppringing fra amerikansk telefonbot som skal ha meg til å lese inn navnet mitt på tape. Og da har vi bare domenevalidert sertifikat (DV), ikke organisasjonsvalidert (OV) eller utvidet validering (EV). 

 

Jeg tviler ikke på at det kan gjøres mer automatisert men vår leverandør hadde ikke engang mulighet til å opprette brukerkonto for å huske kontaktinformasjon o.l., fram til forrige gang vi fornyet sertifikatene. 

Hvis dere ikke bruker denne leverandøren av en spesiell grunn, slik som forsikringssum, er det bare å bytte leverandør – gjerne til en som er gratis og lar dere automatisere dette. Det er ingen kvalitetsforskjell på sertifikatene og så lenge rot-sertfikatet er godkjent hos Apple, Microsoft, Google og Mozilla er det helt fritt å velge leverandør.

[Bjørn A. Johansen]

Bare det å huske å fornye sertifikater, utgjør økt kompleksitet for nettsteder som ikke har gjort dette tidligere. Ikke all kompleksitet er teknisk handler om bits og megahertz.

 

 

Personlig mener jeg «kompleksitet» blir litt drøyt å kalle det, men OK, det er en ekstra oppgave. Hvis man automatiserer det med f.eks. Let’s Encrypt må man sette opp en cronjob som innimellom kjører certbot med renew-parameteret og en post-hook som laster inn nye sertifikater/nøkler evt. distribuerer disse til alle noder først. Hvis man ikke automatiserer det, må man huske på å gjøre dette manuelt hvert 3. år.

 

Det gjelder også ressursbruk. Arbeidstimer er også en ressurs. Per Buer hos Varnish skrev nylig et kommentar her om at det for mange ikke bare er å skru det på: 

 

https://www.diskusjon.no/index.php?showtopic=1744314&do=findComment&comment=23524085

 

 

Jeg har respekt for Per Buer, men dette innlegget er på kanten til FUD. OCSP Stapling og session sharing/resumption tar nesten 30 sekunder å konfigurere hvis du gjør det manuelt og skriver sakte, og når det er satt opp trenger du ikke tenke mer på det. I alle nyere operativsystemer er cwnd initielt satt til 10, og er hverken noe du styrer med eller tenker på. Dette er uansett mer enn nok til å utføre TLS-handshake. Latensen er, som han nevner, viktig, men med en tilkobling over Atlanteren fører det til ~150 ekstra ms. Med TLS 1.3 blir det kun 1 ekstra RTT for nye tilkoblinger og tilkoblinger med session resumtion ingen i det hele tatt. Dette er uansett ikke ting vanlige nettsteder som må barbere millisekunder trenger å tenke på. Med TLS kan du ta i bruk HTTP/2 og dermed er de initielle millisekundene fort tjent inn og totaltiden for sideinnlastingen gått _ned_ med HTTPS.

 

Og ingen ting av dette trenger du å passe på.

 

Det er godt mulig at økt bruk av maskinvareressurser er en myte, men jeg kjenner til nettsteder som har ment at det er nødvendig å bytte servere før HTTPS kan skrus på. Samtidig er det mulig at serverne deres var på nippet til å være overbelastet i utgangspunktet ...

 

Med forbehold om at jeg husker dette riktig, gikk Google over på 100% HTTPS for Gmail i årskiftet 2009/2010. CPU-bruken økte med 1% og nettverksforbruket med 2%. Det høres mer ut som om HTTPS ble brukt som en unnskyldning for å oppgradere overbelastede servere, ja.

[endrebjo]

Min erfaring er at det er lettere å få hjelp av statlige tjenester, enn å fornye et sertifikat hos vår leverandør. Ikke bare den tekniske prosessen, men den organisatoriske prosessen er plagsom. Prosessen involverer hotseat-swapping mellom teknisk ansvarlig, fakturaansvarlig og oppringing fra amerikansk telefonbot som skal ha meg til å lese inn navnet mitt på tape. Og da har vi bare domenevalidert sertifikat (DV), ikke organisasjonsvalidert (OV) eller utvidet validering (EV). 

 

Jeg tviler ikke på at det kan gjøres mer automatisert men vår leverandør hadde ikke engang mulighet til å opprette brukerkonto for å huske kontaktinformasjon o.l., fram til forrige gang vi fornyet sertifikatene.

Hele idéen bak Let's Encrypt er at både sertifikatutstedelse og -fornyelse skal være så enkelt og fullstendig automatisert at alle kan ta i bruk TLS. Tjenesten er gratis og rot-sertifikatet er akseptert av Mozilla/Google/etc. Som tidligere sagt, kan fornyelse av sertifikatet enkelt legges i en cronjob, og alt vil deretter gå helt av seg selv. Endret 8. november 2016 av endrebjo

[tommyb]

Første gang jeg sjekket opp gratis-tjenester, var det adskillig dårligere produkter, selv om man holder forsikringer utenfor. Dette var lenge før Let's Encrypt var et samtaleevne. Når jeg senere ble oppmerksom på Let's Encrypt sjekket jeg det ut og måtte avskrive det ganske raskt. Browserstøtten var på det tidspunktet jeg ble klar over tjenesten langt tydelig under de store sertifiseringstjenestene. Og vi har kunder med gamle versjoner av Windows, etc. Perioden på sertifikatene var også svært kort. (Men det er jo ikke relevant hvis vi slipper unna den organisatoriske prosessen.) Så det var ikke et reelt alternativ. 

 

At sertifikatene er gratis er ikke en viktig faktor for oss, det er den tidligere nevnte kompliserte prosessen som gjør størst utslag for oss sammenlignet med noen never dollars for wildcard-sertifikater. 

 

Men etterhvert som noen av de større tjenestene blir mer automatisert eller gratistjenestene blir bredere støttet, så må vi jo revurdere. Så neste gang sertifikatene løper ut, skal jeg sjekke opp alternativene igjen.

Endret 8. november 2016 av tommyb

[endrebjo]

For meg spiller det heller ikke noen rolle om sertifikatene koster 0 eller 500 kr. Men ved å unngå både fakturaer, betalinger og økonomiavdeling, så unngår du mye av det som forkludrer den automatiske prosessen. Derfor synes jeg at det er verdt å pushe tjenesten, spesielt når du sammenlikner det med litt "skitne" wildcard-sertifikater.

Tatt i betraktning at Let's Encrypt er såpass ung, synes jeg at de allerede har fått til veldig mye. Og siden de er kryssignert av et rot-sertifikat fra 2000 (DST Root CA X3) bør vel støtten for gamle OS være ganske OK, eller?

[Per Buer]

Jeg har respekt for Per Buer, men dette innlegget er på kanten til FUD. OCSP Stapling og session sharing/resumption tar nesten 30 sekunder å konfigurere hvis du gjør det manuelt og skriver sakte, og når det er satt opp trenger du ikke tenke mer på det. I alle nyere operativsystemer er cwnd initielt satt til 10, og er hverken noe du styrer med eller tenker på. Dette er uansett mer enn nok til å utføre TLS-handshake. Latensen er, som han nevner, viktig, men med en tilkobling over Atlanteren fører det til ~150 ekstra ms. Med TLS 1.3 blir det kun 1 ekstra RTT for nye tilkoblinger og tilkoblinger med session resumtion ingen i det hele tatt. Dette er uansett ikke ting vanlige nettsteder som må barbere millisekunder trenger å tenke på. Med TLS kan du ta i bruk HTTP/2 og dermed er de initielle millisekundene fort tjent inn og totaltiden for sideinnlastingen gått _ned_ med HTTPS.

 

Og ingen ting av dette trenger du å passe på.

 

Du har stort sett rett i alt du sier. For 95% er alt dette rimelig greit og default i Linux og hva en nå bruker som proxy fungerer glimrende. For de siste 5% - de som har en del trafikk og som faktisk har en sammenheng mellom ytelse og inntekt er det litt mer komplisert. Folk som gjør ting nøye og som liker å forstå de forskjellige tingene de roter med vil bruke litt mer tid enn 30 sekunder - men la gå. Jeg ville ikke migrert en stor avis eller e-commerce-sjappe til TLS uten å sette meg grundig i hva det er og hvordan det fungerer.

 

Men det er faktisk en ting som er komplisert med TLS. Hvordan unngår du å blande klartekst og innholder over TLS. Idag snakket jeg med et stort mediekonsern. De har et prosjekt hvor de kjører over flere publikasjoner over på TLS. Problemet er at journalistene har de siste tjue årene inkludert eksternt innhold, hvor mye er kun tilgjengelig i klartekst, i artiklene sine. Hvordan løser du det? Jo, du bygger støtte for dette inn i CMSen din og får på plass proxying av disse forespørslene gjennom den siten du prater med - og nå snakker vi om ting som tar mer enn 30 sekunder.

 

Så jeg synes det er forståelig at enkelte bruker litt tid på dette, jeg. Ikke forstå det dithen at jeg synes TLS er dumt. Jeg er fortsatt uenig i at TLS skal være påkrevet i HTTP-transporten - men jeg skulle ønske Varnish kunne lenke med OpenSSL og vi kunne shippet med native TLS-støtte. Men, men.