mboost-dp1
Host og SSL-certifikater
- Forside
- ⟨
- Forum
- ⟨
- Support
Hej :)
Host:
Jeg skal i gang med udviklingen af en større web-applikation baseret på Drupal. I den forbindelse er jeg lidt i tvivl om valget af host. Jeg regner med at køre det på en dedikeret virtuel server og har selv overvejet Meebox's Cloud Server-løsning. Meebox får god omtale de fleste steder og jeg er også personligt tilfreds med deres billige webhotel-løsning. Jeg er dog lidt i tvivl om, hvorvidt de stadigvæk er lidt for unge til at hoste et så seriøst projekt, som jeg skal i gang med. Så jeg ville lige høre, om nogen er jer kan anbefale en seriøst host til et seriøst formål.
SSL:
I forbindelse med samme projekt skal jeg have signeret et SSL-certifikat til applikationen, men jeg synes markedet for CAs er ret uoverskueligt og ikke mindst priserne. Hvilke CA benytter I jer af og hvorfor?
På forhånd tak,
qed.
Host:
Jeg skal i gang med udviklingen af en større web-applikation baseret på Drupal. I den forbindelse er jeg lidt i tvivl om valget af host. Jeg regner med at køre det på en dedikeret virtuel server og har selv overvejet Meebox's Cloud Server-løsning. Meebox får god omtale de fleste steder og jeg er også personligt tilfreds med deres billige webhotel-løsning. Jeg er dog lidt i tvivl om, hvorvidt de stadigvæk er lidt for unge til at hoste et så seriøst projekt, som jeg skal i gang med. Så jeg ville lige høre, om nogen er jer kan anbefale en seriøst host til et seriøst formål.
SSL:
I forbindelse med samme projekt skal jeg have signeret et SSL-certifikat til applikationen, men jeg synes markedet for CAs er ret uoverskueligt og ikke mindst priserne. Hvilke CA benytter I jer af og hvorfor?
På forhånd tak,
qed.
@SSL
Der er 3 ting der adskiller de billige og de dyre så vidt jeg kan se:
1. Hvilket årstal deres root cert er udstedt. (Jo ældre jo bedre da du så ikke kommer ud for nogle systemer der får cert warning pga. manglende root cert)
2. Godkendelse processen hvorved man kan få udstedt et certificat. (For nogle udstedere er det nok at de kan sende en mail til en modtager på domænet hvor andre skal have telefonisk kontakt og underskrifter)
3. Support
Der er 3 ting der adskiller de billige og de dyre så vidt jeg kan se:
1. Hvilket årstal deres root cert er udstedt. (Jo ældre jo bedre da du så ikke kommer ud for nogle systemer der får cert warning pga. manglende root cert)
2. Godkendelse processen hvorved man kan få udstedt et certificat. (For nogle udstedere er det nok at de kan sende en mail til en modtager på domænet hvor andre skal have telefonisk kontakt og underskrifter)
3. Support
#SSL
Nogle af de billigste udbydere er nok:
http://www.namecheap.com/ssl-certificates/comodo.a... (var det ikke dem der blev hacket? Ellers tag deres Geotrust)
http://www.startssl.com/
http://www.godaddy.com/
Til web tror jeg ikke betyder så meget hvilken udbyder man tager, da deres lister med CA'er der understøttes opdateres rimeligt tit.
Det er værre med sådan noget til Exchange og mobil telefoner.
Godkendelse processen afhænger også hvad type du vil have. Et EV: http://en.wikipedia.org/wiki/Extended_Validation_C... kræver noget mere bevis på du er hvem du er, men så får man også en grøn adresse linje, se fx: https://www.digitaltcertifikat.dk/
Nogle af de billigste udbydere er nok:
http://www.namecheap.com/ssl-certificates/comodo.a... (var det ikke dem der blev hacket? Ellers tag deres Geotrust)
http://www.startssl.com/
http://www.godaddy.com/
Til web tror jeg ikke betyder så meget hvilken udbyder man tager, da deres lister med CA'er der understøttes opdateres rimeligt tit.
Det er værre med sådan noget til Exchange og mobil telefoner.
Godkendelse processen afhænger også hvad type du vil have. Et EV: http://en.wikipedia.org/wiki/Extended_Validation_C... kræver noget mere bevis på du er hvem du er, men så får man også en grøn adresse linje, se fx: https://www.digitaltcertifikat.dk/
Mange tak for svar med SSL!
På http://www.startssl.com/ har de en gratis løsning. Den primær grund til, at jeg vil bruge SSL er for at sikre mig sikker overførsel af diverse info. Det med at verificere hvem vi er, har mindre betydning, da brugerne kender os og stoler på, hvem vi er. Vil I umiddelbart vurdere, at den gratis løsning i dette tilfælde er tilstrækkeligt?
Er der ingen, der har nogen tanker omkring valg af host, som de har lyst til at dele? :)
På http://www.startssl.com/ har de en gratis løsning. Den primær grund til, at jeg vil bruge SSL er for at sikre mig sikker overførsel af diverse info. Det med at verificere hvem vi er, har mindre betydning, da brugerne kender os og stoler på, hvem vi er. Vil I umiddelbart vurdere, at den gratis løsning i dette tilfælde er tilstrækkeligt?
Er der ingen, der har nogen tanker omkring valg af host, som de har lyst til at dele? :)
Lige et par kommentarer omkring sikkerheden.
Det er stort set ligegyldigt hvordan sikkerheden er hos den udbyder du vælger. Det lyder måske lidt mærkeligt, men sådan som sikkerhedsmodellen fungerer vil sikkerhedsniveauet afhænge af den ringste CA uanset hvilken CA du vælger.
Den største risiko du løber ved at vælge en CA med rod i sikkerheden er at browserleverandørerne vælger at fjerne den fra deres liste. Det vil være upraktisk for dig da du så vil være nødt til at få nyt certifikat hos en anden udbyder med kort varsel.
Jeg erindrer dog kun en episode hvor det middel er blevet taget i brug.
De allermest sikkerhedsbevidste brugere vil måske opdage hvis sitet skifter til en anden CA, hvilket kunne indikere et angreb. Dog er det mere sandsynligt at skiftet er fuldstændig legitimt og blot skyldes at sitet har valgt at skifte udbyder.
Den korrekte procedure er at du selv genererer et nøglepar og sender den offentlige nøgle til en CA for at få et certifikat udstedt. Hvis du oplever en CA der vil generere nøgleparret for dig og sende dig den hemmelige nøgle, eller de på anden måde kommer til at se den hemmelige nøgle, så ville jeg holde mig langt væk fra dem.
Det er ikke fordi det direkte gør et angreb nemmere, hvis CA har din hemmelige nøgle. Er CA kompromitteret kan både en lækket hemmelig nøgle og et forfalsket certifikat udnyttes til et aktivt angreb.
Et passivt angreb må intet kunne opdage uanset om angriberen har din hemmelige nøgle eller ej. Men en svaghed i SSL der tillader at anvende din hemmelige nøgle til at dekryptere trafikken efter passiv sniffning er langt mere sandsynligt end et angreb der tillader at gøre det uden din hemmelige nøgle. På den måde er det stadig en risiko hvis nogen andre kender din hemmelige nøgle. Desuden er aktive angreb noget sværere at opdage, hvis de kan gennemføres med nøjagtigt samme certifikat.
Om der findes nogen CA der anvender en procedure, hvor de kommer til at se din hemmelige nøgle ved jeg ikke. De bør ikke findes, da alle kunder burde undgå en CA der opererer på den måde.
Det er stort set ligegyldigt hvordan sikkerheden er hos den udbyder du vælger. Det lyder måske lidt mærkeligt, men sådan som sikkerhedsmodellen fungerer vil sikkerhedsniveauet afhænge af den ringste CA uanset hvilken CA du vælger.
Den største risiko du løber ved at vælge en CA med rod i sikkerheden er at browserleverandørerne vælger at fjerne den fra deres liste. Det vil være upraktisk for dig da du så vil være nødt til at få nyt certifikat hos en anden udbyder med kort varsel.
Jeg erindrer dog kun en episode hvor det middel er blevet taget i brug.
De allermest sikkerhedsbevidste brugere vil måske opdage hvis sitet skifter til en anden CA, hvilket kunne indikere et angreb. Dog er det mere sandsynligt at skiftet er fuldstændig legitimt og blot skyldes at sitet har valgt at skifte udbyder.
Den korrekte procedure er at du selv genererer et nøglepar og sender den offentlige nøgle til en CA for at få et certifikat udstedt. Hvis du oplever en CA der vil generere nøgleparret for dig og sende dig den hemmelige nøgle, eller de på anden måde kommer til at se den hemmelige nøgle, så ville jeg holde mig langt væk fra dem.
Det er ikke fordi det direkte gør et angreb nemmere, hvis CA har din hemmelige nøgle. Er CA kompromitteret kan både en lækket hemmelig nøgle og et forfalsket certifikat udnyttes til et aktivt angreb.
Et passivt angreb må intet kunne opdage uanset om angriberen har din hemmelige nøgle eller ej. Men en svaghed i SSL der tillader at anvende din hemmelige nøgle til at dekryptere trafikken efter passiv sniffning er langt mere sandsynligt end et angreb der tillader at gøre det uden din hemmelige nøgle. På den måde er det stadig en risiko hvis nogen andre kender din hemmelige nøgle. Desuden er aktive angreb noget sværere at opdage, hvis de kan gennemføres med nøjagtigt samme certifikat.
Om der findes nogen CA der anvender en procedure, hvor de kommer til at se din hemmelige nøgle ved jeg ikke. De bør ikke findes, da alle kunder burde undgå en CA der opererer på den måde.
Jo, Comodo og Diginotar. Comodo overlevede episoden fordi de valgte at være åbne omkring det. Da Diginotar et par måneder senere var ude for det samme prøvede de at skjule det. Der gik ca. to måneder fra Diginotar havde opdaget det før resten af verdenen fik noget at vide. Det resulterede i at ingen browsere ville stole på Diginotar, og de gik konkurs.freesoft (4) skrev:var det ikke dem der blev hacket?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.