Gå til innhold

Mozilla: – For første gang er mer enn halvparten av sidevisningene krypterte


Anbefalte innlegg

Videoannonse
Annonse

Digi og diskusjon.no skal begynne når? Diskusjon.no har jo ikke en gang når de sender brukernavn og passord, noe som er skandaløst fra noe som opprinnelig var et IT-diskusjonsforum. 

 

Skal ikke protestere på det. Vi har konkrete planer om HTTPS på alle sitene til mediehuset. "I løpet av høsten" er det siste jeg hørte.

  • Liker 3
Lenke til kommentar

 

Digi og diskusjon.no skal begynne når? Diskusjon.no har jo ikke en gang når de sender brukernavn og passord, noe som er skandaløst fra noe som opprinnelig var et IT-diskusjonsforum. 

Skal ikke protestere på det. Vi har konkrete planer om HTTPS på alle sitene til mediehuset. "I løpet av høsten" er det siste jeg hørte.

 

 

I løpet av høsten? Jeg vet det har vært snakk om det en stund. Å bytte protokoll tar normalt sett ikke mer enn noen minutter per side, så sant sidene som kjøres er godt skrevet og ikke er laget med "http" hardkodet over alt. Om de er det så må jo noen gå gjennom det og bytte, men selv det burde ikke tar veldig lang tid, og er garantert gjort på en dag.

 

Jeg hadde vært ganske flau om jeg hadde drevet en nettside med så lite respekt for brukerne. Nå snakker jeg hovedsakelig om diskusjon.no der brukerne kan sende "private" meldinger til hverandre og har brukerkontoer. Jeg ser det er veldig mange som er superaktive på forumet og har brukt mye tid på brukerne sine, men selv om dere tjener penger på at folk bruker forumet så viser dere ingen respekt for brukerne når dere ikke bidrar til å holde folk sine brukere sikre eller meldinger "privat".

 

Nå vet jeg ikke om det bare er brukerne det er slik for eller om alle de ansatte har det like ille. I så fall vil det ta seg ut om det plutselig dukker opp en artikkel eller foruminnlegg fra noen som utgir seg for å være en ansatt, for det er virkelig ikke usannsynlig i 2016.

Lenke til kommentar

 

I løpet av høsten? Jeg vet det har vært snakk om det en stund. Å bytte protokoll tar normalt sett ikke mer enn noen minutter per side, så sant sidene som kjøres er godt skrevet og ikke er laget med "http" hardkodet over alt. Om de er det så må jo noen gå gjennom det og bytte, men selv det burde ikke tar veldig lang tid, og er garantert gjort på en dag.

 

Skjønner at du er frustrert, men syns du skyter lovlig mye på budbringeren her. Jeg er ikke involvert i beslutningene. Men jeg ser at du konkluderer med vel mye uten å kjenne detaljene i vår infrastruktur. Jeg er sikker på at vår teamleder utvikling, Erlend Blakstad, kan fortelle deg mer om dette dersom du tar kontakt. Du finner kontaktinfo her: http://www.tu.no/artikler/kontakt-oss/277192
Lenke til kommentar

 

I løpet av høsten? Jeg vet det har vært snakk om det en stund. Å bytte protokoll tar normalt sett ikke mer enn noen minutter per side, så sant sidene som kjøres er godt skrevet og ikke er laget med "http" hardkodet over alt. Om de er det så må jo noen gå gjennom det og bytte, men selv det burde ikke tar veldig lang tid, og er garantert gjort på en dag.

Det er faktisk en god del integrasjon som må være på plass. En side som serveres over TLS kan ikke laste ressurser over klartekst. Dermed må alt av innhold på siden gå over TLS eller så dukker det opp advarsler. Så alt fra fonter, til annonser (adwords, cxsense) og analyseverktøy (linkpulse, google analytics) må være tilgjengelig. Jeg vet ikke hvordan Digi og de andre nettstedene gjør krysspublisering, men siden krysspublisering foregår må antageligvis alle nettstedene taes på en gang. Ellers mister du informasjon (referer-headeren blir blank).

For all del; det er ikke en uoverkommelig oppgave, men det er faktisk en god del jobb og teste alt sammen se påse at det fungerer. I tillegg er ytelsesbiten mer kritisk. Ting som OCSP Stapling og session sharing/resumption er jo ting en ikke trenger å tenke på uten TLS. Initial congestion window er heller ikke så viktig som med TLS. Latensen blir jo skrekkelig mye viktigere enn TLS - siden du har 5 pakker som utveksles før en er igang.

 

Og så må en passe på alt sammen. Om en av nettstedene du trekker innhold fra glemmer å oppdatere sertifikatet sitt så får brukeren advarlser og greier. Så en må gjerne opp med en haug med ny overvåking. 

 

Siden mesteparten av verden bruker OpenSSL-biblioteket til TLS og OpenSSL har omtrent en eller to nye exploits hver måned så øker også risikoen for at noe skal gå galt.

For et selskap eller en personlig nettside er TLS trivielt. For media er det ikke-trivielt. Absolutt gjørbart. Men det er ikke skrekkelig mye media, hverken her til lands eller i utlandet som bruker TLS dessverre.

Endret av Per Buer
  • Liker 1
Lenke til kommentar

 

 

I løpet av høsten? Jeg vet det har vært snakk om det en stund. Å bytte protokoll tar normalt sett ikke mer enn noen minutter per side, så sant sidene som kjøres er godt skrevet og ikke er laget med "http" hardkodet over alt. Om de er det så må jo noen gå gjennom det og bytte, men selv det burde ikke tar veldig lang tid, og er garantert gjort på en dag.

Det er faktisk en god del integrasjon som må være på plass. En side som serveres over TLS kan ikke laste ressurser over klartekst. Dermed må alt av innhold på siden gå over TLS eller så dukker det opp advarsler. Så alt fra fonter, til annonser (adwords, cxsense) og analyseverktøy (linkpulse, google analytics) må være tilgjengelig. Jeg vet ikke hvordan Digi og de andre nettstedene gjør krysspublisering, men siden krysspublisering foregår må antageligvis alle nettstedene taes på en gang. Ellers mister du informasjon (referer-headeren blir blank).

For all del; det er ikke en uoverkommelig oppgave, men det er faktisk en god del jobb og teste alt sammen se påse at det fungerer. I tillegg er ytelsesbiten mer kritisk. Ting som OCSP Stapling og session sharing/resumption er jo ting en ikke trenger å tenke på med TLS. Initial congestion window er heller ikke så viktig som med TLS. Latensen blir jo skrekkelig mye viktigere enn TLS - siden du har 5 pakker som utveksles før en er igang.

 

Og så må en passe på alt sammen. Om en av nettstedene du trekker innhold fra glemmer å oppdatere sertifikatet sitt så får brukeren advarlser og greier. Så en må gjerne opp med en haug med ny overvåking. 

 

Siden mesteparten av verden bruker OpenSSL-biblioteket til TLS og OpenSSL har omtrent en eller to nye exploits hver måned så øker også risikoen for at noe skal gå galt.

For et selskap eller en personlig nettside er TLS trivielt. For media er det ikke-trivielt. Absolutt gjørbart. Men det er ikke skrekkelig mye media, hverken her til lands eller i utlandet som bruker TLS dessverre.

 

Det er likevel ingen unnskylding å ikke kryptere login til diskusjon.no. Det er helt ufattelig at de ikke har gjort noe med det for minst 10 år siden.

  • Liker 1
Lenke til kommentar

Det er faktisk en god del integrasjon som må være på plass. En side som serveres over TLS kan ikke laste ressurser over klartekst. Dermed må alt av innhold på siden gå over TLS eller så dukker det opp advarsler. Så alt fra fonter, til annonser (adwords, cxsense) og analyseverktøy (linkpulse, google analytics) må være tilgjengelig. Jeg vet ikke hvordan Digi og de andre nettstedene gjør krysspublisering, men siden krysspublisering foregår må antageligvis alle nettstedene taes på en gang. Ellers mister du informasjon (referer-headeren blir blank).

For all del; det er ikke en uoverkommelig oppgave, men det er faktisk en god del jobb og teste alt sammen se påse at det fungerer. I tillegg er ytelsesbiten mer kritisk. Ting som OCSP Stapling og session sharing/resumption er jo ting en ikke trenger å tenke på uten TLS. Initial congestion window er heller ikke så viktig som med TLS. Latensen blir jo skrekkelig mye viktigere enn TLS - siden du har 5 pakker som utveksles før en er igang.

 

Og så må en passe på alt sammen. Om en av nettstedene du trekker innhold fra glemmer å oppdatere sertifikatet sitt så får brukeren advarlser og greier. Så en må gjerne opp med en haug med ny overvåking. 

 

Siden mesteparten av verden bruker OpenSSL-biblioteket til TLS og OpenSSL har omtrent en eller to nye exploits hver måned så øker også risikoen for at noe skal gå galt.

For et selskap eller en personlig nettside er TLS trivielt. For media er det ikke-trivielt. Absolutt gjørbart. Men det er ikke skrekkelig mye media, hverken her til lands eller i utlandet som bruker TLS dessverre.

 

 

Nå vet jeg ikke jeg hva situasjonen deres er, men jeg kan ikke se for meg at det er spaghetti de jobber med, om det er det så synes jeg synd på de, men da gjør de vel aldri den feilen igjen.

 

Etter å ha sett på tek.no så ser det ikke ut som om de har så veldig mye jobb foran seg, men de har jo åpenbart gjort noen feil som gjør jobben med å skifte tyngre. Det meste du nevner er i hvert fall veldig simpelt å løse, spesielt om sidene deres er av høy kvalitet. Forsinkelsen ved tilkobling vil selvfølgelig bli høyere, men siden blir nok vesentlig raskere som følge av h2. Referrer? Det er heller ikke noe problem om sidene deres kjører på samme kode og infrastruktur, og om det er et problem så har vi referrer meta-taggen.

 

Bytter en til TLS og ting feiler så har en jo åpenbart gjort noe en ikke burde har gjort, og om en er avhengig av andre tjenester som ikke støtter TLS så lurer jeg veldig på hvilken kvalitetstjeneste det er om de ikke har en eneste kunde som bruker https.

 

At nyhetssider ikke bruker TLS bryr jeg meg ikke så mye om, men at de har et forum(!) uten TLS synes jeg er ganske ekstremt. Det er jo åpenbart ikke noen prioritet for de på noen som helst måte, og det går jo med sikkerhet ut over både brukerne deres og inntektene deres.

 

Det er mye ny, nyttig og morsom teknologi en får tilgang til å bruke ved å bytte.

 

Jeg ønsker de uansett lykke til med byttet, selv om jeg personlig mener at de burde skjerpe seg og prioritere det. Tar en i mot passordene til folk så har en et ansvar for å holde de hemmelig, det er i hvert fall min mening.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...