Wikimedia indfører HTTPS på alle projekter

Jeg får en certifikat fejl når jeg vil gå ind på
https://da.wikipedia.org

edit: Nå det gik væk nu... Men jeg får stadig en advarsel i både chrome og ie9 om insecure content.

#1 yep, ikke smart :=)

Nogen, der lige kan forklare årsagen, der er vel i sagens natur ikke meget hemmeligt at skulle beskytte hos wiki ...? Forstår ikke lige helt årsagen til at bruge ssl, men bruger nok bare siden for lidt

#1: Det gør du da også hvis du hopper ind på borger.dk og su.dk for tiden pga. deres certifikat misser. Det gør ikke certifikatet mindre brugbart. Men ja - det er ikke det bedste budskab at sende at få en rød advarselsside (Chrome) når du prøver at logge ind på f.eks. SU's side)

webwarp (2) skrev:

Forstår ikke lige helt årsagen til at bruge ssl

Jeg forstår omvendt ikke helt årsagen til ikke at bruge SSL, uanset hvilken side man skal ind på.

#2

Alle sider burde bruge SSL.

Alrekr (4) skrev:

Jeg forstår omvendt ikke helt årsagen til ikke at bruge SSL, uanset hvilken side man skal ind på.

Overhead, server-side processor load, etc....

HerrMansen (3) skrev:

#1: Det gør du da også hvis du hopper ind på borger.dk og su.dk for tiden pga. deres certifikat misser. Det gør ikke certifikatet mindre brugbart. Men ja - det er ikke det bedste budskab at sende at få en rød advarselsside (Chrome) når du prøver at logge ind på f.eks. SU's side)

Så vidt jeg kan se har borger.dk og min.su.dk da fået styr på deres certifikater.

gensplejs (1) skrev:

Jeg får en certifikat fejl når jeg vil gå ind på
https://da.wikipedia.org

Jeg får fejl når jeg bruger linket i artiklen, men det virker når jeg bruger dit link. Det skyldes en kombination af bugs i newz heuristik til at identificere links og en dum måde at håndtere domænenavne i SSL certifikater.

Man afslutter en sætning med et punktum. Men hvis en sætning slutter med en URL kan newz tro at det punktum er en del af URLen som det skete i artiklen.

Nu er der som sådan ikke noget galt i at sætte et punktum ind i URLen på det sted. Faktisk kunne man sige at det ville være mere korrekt at bruge URLen med punktum i forhold til den uden. Det fører os så tilbage til dumheden i SSL certifikater.

Domæner kan enten slås op som et absolut navn eller som et relativt navn. Hvis man slår et navn op som et relativt navn gør man det under ens eget domæne. Som regel kigger klienten på antallet af punktummer i navnet for at beslutte om den skal prøve at bruge det som et relativt navn eller som et absolut navn først.

Hvis du bruger URLen http://www/ er der ingen punktummer, og din browser vil derfor starte med at bruge det som et relativt navn. Hvis www findes som underdomæne til det domæne din computer er sat op til at søge under kommer du derind. Det vil sige at forskellige brugere vil ende forskellige steder hvis de følger det link, og for mange vil linket nok slet ikke virke.

Hvis man afslutter domænenavnet med et punktum er det et absolut navn, og det vil aldrig blive slået op som et relativt navn.

SSL certifikater indeholder et navn som er tiltænkt at skulle bruges som et absolut navn, men de indeholder ikke det afsluttende punktum som ville angive at det er et absolut navn. Certifikatet indeholder wikipedia.org selvom det aldrig skulle bruges med wikipedia.org som underdomæne under et andet domæne. Certifikatet burde have indeholdt wikipedia.org. i stedet for, men det er ikke det som software forventer.

Når browseren sammenligner bruger den domænet som det så ud i URLen og ikke domænet som den slog op. Det betyder at hvis en https URL indeholder et absolut navn så fejler sammenligningen.

Hvis URLen indeholder et relativt navn, så vil browseren stadig tilføje søgedomænet til navnet og prøve at slå det op. Derefter vil den sammenligne det relative navn med det fulde navn i certifikatet. Det kommer aldrig til at virke, og derfor burde man aldrig have tilladt relative navne i https URLer i første omgang.

Det vil sige at en URL som https://www/ altid vil give en certifikatfejl med mindre det fejler tidligere fordi www ikke er navnet på en https server under ens søgedomæne.

Alrekr (4) skrev:

Jeg forstår omvendt ikke helt årsagen til ikke at bruge SSL, uanset hvilken side man skal ind på.

Omkostningen til at købe et SSL certifikat er nok en af årsagerne. Der er nok mange som ikke er klar over hvor billige certifikater man kan få hvis man søger efter dem.

Der er måske også en utilfredshed med en fundamentalt forkert model omkring tillid til CAer, som får nogen til at synes det ikke er besværet værd.

Og endeligt er der nok nogen som tror SSL kun drejer sig om at kryptere data og ikke har forstået at integritet og autencitet altid er vigtigere end kryptering. Hvis man ikke har forstået koncepterne tænker man måske at man ikke har brug for kryptering (hvilket i mange tilfælde er korrekt), men overser at man har bryg for integritet og autencitet.

Bemærk at ovenstående indlæg indeholder flere forskellige renderingsfejl pga. førnævnte fejlbehæftede heuristikker som newz anvender til at identificere links.

Af fejl kan nævnes:
- Alle links efterfølges af .. som ikke burde have været der. Dog kun i teksten, hvis man holder musen over linket kan man stadig se hvad jeg skrev.
- Alle https links vises som http links. Dog kun i teksten, hvis man holder musen over linket kan man stadig se hvad jeg skrev.
- Hver gang jeg skrev navnet www uden at det var del af et link ses www og det efterfølgende ord som et link. Men hvis man holder musen over det kan man se at det ikke peger på noget.

gensplejs (1) skrev:

Jeg får en certifikat fejl når jeg vil gå ind på
https://da.wikipedia.org

edit: Nå det gik væk nu... Men jeg får stadig en advarsel i både chrome og ie9 om insecure content.

webwarp (2) skrev:

#1 yep, ikke smart :=)

Nogen, der lige kan forklare årsagen, der er vel i sagens natur ikke meget hemmeligt at skulle beskytte hos wiki ...? Forstår ikke lige helt årsagen til at bruge ssl, men bruger nok bare siden for lidt

Grunden er blot at i newz.dk's link er der et punktum efter .org, der er ikke noget i vejen med certifikatet.

Edit: kasperd var lidt hurtigere (Selv om han skrev en hel roman)

#7: Det har du vist ret i - jeg får ikke længere selv certifikatfejl hér :)

#4
Pris måske????? ~4000kr per domain? Subdomains er ikke inkluderet, betal venligst per subdomain du vil have. Og så er vi endda i den billige ende.
Skal du have et wildcard certifikat snakker vi i omegnen 100.000kr per domain.
Har du så lige et alternativt domæne hoster du lige 100.000kr mere per styk op.

Til dem der ser den røde advarsel skyldtes det et . (punktum) i slutningen af domænet i OP. Hvilket gør at domænet ikke er det samme som det som certifikatet gælder for.

#11

Åh, skal vi nu ikke lige tage det roligt.
Så meget koster det absolut ikke.

Yderligere er der noget der hedder SSL gateways, du behøver ikke et certifikat til hvert sub domæne.

#12
Post gerne links og noget mere info :)
Vil jeg gerne høre om.

Seriøst ment.

webwarp (2) skrev:

Nogen, der lige kan forklare årsagen, der er vel i sagens natur ikke meget hemmeligt at skulle beskytte hos wiki ...? Forstår ikke lige helt årsagen til at bruge ssl, men bruger nok bare siden for lidt

I DK er der ikke så meget brug for det (måske med undtagelse af login/pass). Men i lande uden så meget ytringsfrihed kan det nok være meget godt.

cyberdude (11) skrev:

#4
Pris måske?

God pointe - det anede jeg ikke.

#15 Ifølge #12 er jeg helt forkert på den åbenbart...

cyberdude (16) skrev:

#15 Ifølge #12 er jeg helt forkert på den åbenbart...

https://www.startssl.com/ De tilbyder billige ssl certifikater. Men ved dog ikke hvor gode de er.

cyberdude (16) skrev:

#15 Ifølge #12 er jeg helt forkert på den åbenbart...

Muligvis - men hvis du skal betale for certifikatet vil det altid blive dyrere end den gratis ikke-sikre protokol.

#17
http://news.netcraft.com/archives/2011/06/22/start...

#12
Efter at søge lidt rundt kan jeg se at der er langt billigere alternativer end dem jeg kender Thawte og VeriSign. Har personlig erfaring med VeriSign i forbindelse med et offentligt projekt.

Jeg er dog stadig meget interreseret i noget information omkring SSL gateways, det eneste jeg kan sådan lige kan finde er noget VPN eller Betalings løsninger.

#19 Bluecoat, Netscaler etc? hvis det er SSL offload du tænker på?

Tror ikke prisen er den største ulempe ved SSL certs. Hos StartCom kan man så vidt jeg husker, få et gratis cert (som er gyldigt i 2 år).

Har man en virksomhed/organisation og vil have et lidt mere "seriøst" cert, så koster det (self) mere at få en "grøn bar" i toppen, men det kan stadigt gøres for relativt små penge.

Tror mere at den største ulempe ved HTTPS er at det giver en falsk tryghed (prøv at søge på hvordan man bliver CA'er - og de seneste angreb mod CA PKI) og så fordi HTTPS skaber en masse inkompatibilitet (staves?).
Jeg logger tit på et net hvor login løsningen er lavet sådan, at alle request bliver hijacked ind på en login side, men hvis man bruger en https://domain.tld side som startside, så kan man ikke logge ind (før man fjerner s'et, eller går ind på en anden side). Det er en dårlig løsning (uden tvivl), men det er et eksempel på bare én af de ting som ikke længere virker, hvis man hopper over på SSL only

cyberdude (19) skrev:

Efter at søge lidt rundt kan jeg se at der er langt billigere alternativer end dem jeg kender Thawte og VeriSign. Har personlig erfaring med VeriSign i forbindelse med et offentligt projekt.

Man bliver lidt bange, hvis det er de priser i har betalt til VeriSign i forbindelse med et offentligt projekt.

Vi valgte VeriSign fra, til fordel for GlobalSign, men pris forskellen var ikke kæmpe, og vi giver ca. 15k for et 5års wildcard cert, med 2 SANs. Det er ikke et EV, som generelt er ca. 2-3 gange dyrere.

SuperZorro (22) skrev:

Vi valgte VeriSign fra, til fordel for GlobalSign, men pris forskellen var ikke kæmpe, og vi giver ca. 15k for et 5års wildcard cert, med 2 SANs. Det er ikke et EV, som generelt er ca. 2-3 gange dyrere.

Vi har lige købt 5-års wildcard certifikat for 2.800,- hos RapidSSL (via GratisDNS). Det har ikke alle features (fx fuld mobilunderstøttelse), men formentlig nok til de fleste.

Vær op mærksom på om en certifikat-udsteder har egen trusted CA root i de produkter du bruger. Hvis de bruger en anden over dem, kan du få certifikater udstedt med to intermediate certifikater, og det er der en del produkter der ikke kan finde ud af.

CA kvalitet måles i hvor sikkert de verificerer et request, og hvor lidt hassle der er med det.

Der er ingen grund til ikke at køre ssl. Min gamle Pentium-M kan lave 256 bit AES ved 60 Mbyte-sek, så hvis man har én core ledig på en moderne server, så kan den også sagtens mætte et gigabit link - det er bare dårlige undskyldninger. Man kan offloade det hvis man kommer op i web-løsninger med 10G, hvor overhead kan mærkes. Er man i den kategori, så har man alligevel nok et balancer produkt der kan SSL-offloade alligevel.

Min mening, on topic, genial idé - det burde alle websites gøre. Så kan Villy Søvndal ikke vurdere, at jeg er terrorist og skal i fængsel for evigt, fordi jeg læser om ICMP ECHO, og for øvrigt kan opskriften på thermite i hovedet, efter jeg har læst det på Wikipedia.

Startcoms gratis certifikat er specifikt ikke anvendeligt til websites; det er til signing af mails - men man KAN lægge certifikatet på en webserver, de udsteder det gerne. Man opdager det først, når den CA der er i toppen af kæden f.eks. ikke er i Firefox

(det er 4-5 mnd siden jeg prøvede).

Man skal være class-2 verified ved dem, den gratis er kun class-1. Class to koster 59,99$

Nize (25) skrev:

Startcoms gratis certifikat er specifikt ikke anvendeligt til websites; det er til signing af mails - men man KAN lægge certifikatet på en webserver, de udsteder det gerne. Man opdager det først, når den CA der er i toppen af kæden f.eks. ikke er i Firefox

Sludder. Startcom har både gratis mail certifikater og gratis ssl.
Det er to forskellige ting.
Deres mail certs har enhanced key usage "Client Authentication (1.3.6.1.5.5.7.3.2), Secure Email (1.3.6.1.5.5.7.3.4)"
Deres gratis ssl certifikater har sjovt nok enhanced key usage"Server Authentication (1.3.6.1.5.5.7.3.1)"

Hvis det er lykkedes dig at instalere et af deres client certifikater på en web server har du en retarderet web server.... Det burde ikke være muligt. Men hvis det alligevel er lykkedes dig kan jeg sku godt forstå at firefox ikke vil acceptere det.

Men lægger du et gratis startcom ssl cert på kan jeg ikke se problemet. Startcoms root cert er blandt trusted root auth på windows og alle de linux distroer jeg har testet.

Du skal selvfølgelig selv sørge for at instalere startscoms intermediate cert på serveren da du ellers ikke har intakt chain op til det root cert som er på klient maskinerne...

Startcom kræver kun betaling hvis du vil bruge ha class 2 og ev certifikater. (de har desuden samme root cert så hvis dine klienter af en eller anden grund ikke kender det nytter de certs ikke en hat.)

#26

Jeg kan se vi/jeg/nogen blander startssl sammen med startcom - det er jf. lidt googlesøgning, rent CA teknisk, ikke det samme. Jeg er med på chainens betydning, og tumler med ssl til daglig fra thawte(lidt) og digicert(cursed digicert). :-)

Jeg gjorde som jeg plejer. Jeg ved ikke om lighttpd og Apache2 er specielt retarderede.

Jeg kan have lavet en seriøs blunder, så lad os lade det komme an på en prøve:

Hvis du har et website der bruger et af deres gratis certifikater (baseret på email validering og url validering), så giv os et link, så kan vi prøve med lidt browsere.

For en god ordens skyld, så er min definition på 'virker det' kun hvis de top 10 browsere der bruger eget certificate store har root trust, og Windows og MacOSX's eget certificate store ligeså. Gerne en håndfuld Linux distributioner også - der må altså ikke på Windows XP sp3 eller Windows 7, eller i en 'kendt browser' ikke være broken chain.

Jeg skal være den første til at indrømme at jeg tager fejl - hvis jeg tager fejl. :-)

starn (17) skrev:

De tilbyder billige ssl certifikater. Men ved dog ikke hvor gode de er.

For en webhost må kvaliteten af et SSL certifikat betyde hvor stor en procentdel af brugerne der kan validere det. For det fleste CAs er det ret tæt på 100%

Sikkerheden er stort set ligegyldig når man vælger hvilken CA man vil have sit certifikat fra. Det burde ikke være ligegyldigt, men pga. den måde tillidsmodellen er skruet sammen på er det.

Sikkerheden af dit site kan aldrig blive bedre end den ringste CA som browserne supporterer. Den eneste risiko man vælger ved at vælge en CA er hvis de er så usikre at browserne en dag vælger at droppe dem (som det skete for Diginotar). Hvis det sker er straffen for at have valgt en usikker CA at man bliver nødt til at udskifte sit certifikat hurtigere end browserne kan få en opdatering ud til brugerne.

Nicolai (21) skrev:

Jeg logger tit på et net hvor login løsningen er lavet sådan, at alle request bliver hijacked ind på en login side, men hvis man bruger en https://domain.tld side som startside, så kan man ikke logge ind (før man fjerner s'et, eller går ind på en anden side). Det er en dårlig løsning (uden tvivl), men det er et eksempel på bare én af de ting som ikke længere virker, hvis man hopper over på SSL only

Det du beskriver er et meget udbredt fænomen. Nogen af dem hijacker også https, hvilket så resulterer i en storm af certifikatadvarsler (specielt hvis man bruger AJAX sites over https).

Under alle omstændigheder er det et grimt hack, og en dårlig løsning. Desværre er der mig bekendt ingen god løsning. Det burde ikke have været svært at udvide WIFI protokollen med en metode til at fortælle klienten hvilket domænenavn den skulle kontakte for at logge på. Er der ikke kommet opdaterede udgaver af WIFI protokollen flere gange siden det problem blev kendt?

Jeg kender i øvrigt i omegnen af 10 forskellige metoder til at bruge den slags netværk uden at logge på.

Nize (27) skrev:

#26

Jeg kan se vi/jeg/nogen blander startssl sammen med startcom - det er jf. lidt googlesøgning, rent CA teknisk, ikke det samme. Jeg er med på chainens betydning, og tumler med ssl til daglig fra thawte(lidt) og digicert(cursed digicert). :-)

Jeg gjorde som jeg plejer. Jeg ved ikke om lighttpd og Apache2 er specielt retarderede.

Jeg kan have lavet en seriøs blunder, så lad os lade det komme an på en prøve:

Hvis du har et website der bruger et af deres gratis certifikater (baseret på email validering og url validering), så giv os et link, så kan vi prøve med lidt browsere.

For en god ordens skyld, så er min definition på 'virker det' kun hvis de top 10 browsere der bruger eget certificate store har root trust, og Windows og MacOSX's eget certificate store ligeså. Gerne en håndfuld Linux distributioner også - der må altså ikke på Windows XP sp3 eller Windows 7, eller i en 'kendt browser' ikke være broken chain.

Jeg skal være den første til at indrømme at jeg tager fejl - hvis jeg tager fejl. :-)

Øøøøh Så vidt jeg er informeret er startssl bare den del af startcom som beskæftigere sig med ssl certifikater. Det er Eddy Nigg som styre begge dele anyway. Startssl bruger desuden startcoms intermediate og root certifikater så jeg tror de hænger ret meget sammen.

Jeg har kun nogle test sites men dem kan men ikke se ude fra. Det eneste jeg lige kan se jeg har på offentlig ip er en ret inholdsløs privat side. https://www.holstschumacher.dk

Startcoms har siden engang i 2009 været med i Windows root certificate program. Vista og Win 7 er født med deres root cert og med mindre du ikke har kørt win update på din xp siden oktober 2009 så er deres cert også med der.
(Jeg har dog oplevet at visse it afdelinger går ind og piller i de lister, vi mistede for eksempel trust til alle vores egne certifikater på hele domænet da en eller anden narhat praktikant for nylig fjernede entrust fra root ARGH).

Jeg skal ikke kunne udelukke at firefox i en eller anden version ikke kan lide startcom (der var engang for længe længe siden hvor de ikke kunne lide microsofts liste over CA'er og i stedet havde deres egen) Men så vidt jeg ved er det længe siden.

Forresten er samtlige mails jeg har modtaget omkring mine startssl certifikater afsendt af startcom cert master... det indikere også lidt at der er tale om samme firma :-)

certifikatet på mit link er forresten fra startssl og har ikke kostet en krone.