Spørsmål:
Hvordan skal jeg lagre SSL-nøkler på serveren?
Randomblue
2013-01-12 01:33:27 UTC
view on stackexchange narkive permalink

Jeg har en Node.JS HTTPS-webserver som instantieres som følger: 

  var privateKey = fs.readFileSync ('./../ ssl / localhost.key'). toString (); var sertifikat = fs.readFileSync ('./../ ssl / localhost.crt'). toString (); https.createServer ({nøkkel: privateKey, cert: sertifikat}, server). listen (80, 'localhost') ;

Min private nøkkel er på serveren min som Node.JS leser for å opprette HTTPS-webserveren. Hvis en hacker har lesetilgang til serverfiler, kan han få tilgang til den private nøkkelen og utgi seg for webserveren.

Bør den private nøkkelen lagres på serveren? Bør den ødelegges når HTTPS-serveren er instantiert?

Jeg har det samme spørsmålet, men for andre hemmeligheter (f.eks. Googles klienthemmelighet) som forventes å bare leses av applikasjonen.
To svar:
Thomas Pornin
2013-01-12 01:46:11 UTC
view on stackexchange narkive permalink

Du vil ikke ødelegge din private nøkkel: du trenger den igjen hvis serveren starter på nytt. Omstart skjer noen ganger ...

Det er en generell observasjon: du vil serveren din skal kunne starte på nytt uten tilsyn. Derfor må den inneholde den private nøkkelen, og den private nøkkelen må være tilgjengelig for serverprogramvaren.

Hvis en angriper kaprer hele maskinen din, så han får en kopi av nøkkelen din. Det er et faktum i livet. Leve med det. Det er imidlertid begrensninger:

  • Du kan bruke "DHE" krypteringsserier for SSL. Med disse krypteringssuitene brukes servernøkkelen til signaturer, ikke til kryptering. Dette betyr at angriperen som stjeler nøkkelen din deretter kan utgi serveren din (dvs. kjøre en falsk server), men ikke dekryptere SSL-økter som han tidligere har spilt inn. Dette er en god eiendom kjent som Perfect Forward Secrecy.

  • Hvis du lagrer nøkkelen i en Hardware Security Module så nøkkelen blir ikke stjålet. Angriperen kan spille med nøkkelen så lenge han har effektiv kontroll over serveren, men ikke trekker den ut. Dette reduserer hans plage (men HSM er dyre).

I praksis vil du bare sørge for at filen som inneholder den private nøkkelen bare kan leses for systemkontoen som kjører serveren ( chown og chmod på Unix-lignende systemer, NTFS tilgangsrettigheter i Windows).

Kan ikke en ny privat / offentlig nøkkel genereres ved hver omstart?
@Justin: du kan generere et nytt nøkkelpar, men hva med sertifikatet? SSL-klienter (nettleser) foretrekker sertifikater utstedt av kjent CA; selvsignerte sertifikater utløser skumle advarsler; og selvsignerte sertifikater _som endres etter hver omstart_ utløser _ mange flere_ skumle advarsler.
Hvis du investerer i SSL, bør en HSM betraktes som en del av den totale kostnaden for SSL, selv om du bruker Microsofts gratis Certificate Authority for interne sertifikater.
hm, er det mulig å ha HSM-modul som skal simuleres for XEN-servere?
@EICTO: Hvis CPU / north bridge-kombinasjonen din støtter IOMMU, kan du presentere PCI-enheten for gjesten, jeg tror ikke det er virtuelle HSM-er tilgjengelig, selv om en nettverksløsning ville være ganske enkel å lage (også "HSM-modul" er det samme som "PIN-nummer" og "ATM-maskin", vennligst ikke si det)
@HubertKario Jeg mener HSM for virtuelle maskiner, ingen maskinvare i det hele tatt, bare noe mykt som støtter samme API og gir det til virtuelle maskiner.
@eicto: som jeg sa, jeg vet ikke om noen virtuelle HSM-er, det er ganske enkelt å lage en tilpasset nettverksløsning som vil støtte din brukstilfelle (private nøkler lagret i vertsmaskinen). Så selv om det kanskje ikke finnes klare til bruk, bør det være enkelt å lage en som har samme effekt. Å lage en som implementerer en PKCS # 11 API ville være litt vanskeligere, men da ville det være en reell drop-in-erstatning for en ekte HSM.
Det virker tryggere å ha den private nøkkelen bare lesbar av root, i stedet for av "systemkontoen som kjører serveren". Node.js kan starte som root, lese nøkkelfilen og deretter sette bruker-ID og gruppe-ID til den systemkontoen. På den måten hvis noen hakker webapp, har de bare tillatelsene til den systemkontoen og kan ikke lese nøkkelfilen.
bessbd
2015-09-11 03:44:47 UTC
view on stackexchange narkive permalink

Sannsynligvis du leter etter en omvendt proxy som nginx. Det regnes som beste praksis ™.

Programmer som kjører i produksjon, trenger vanligvis å kjøre på port 80 (HTTP), port 443 (HTTPS) eller begge deler. Dette kan være en utfordring hvis flere komponenter i applikasjonen din samhandler med brukeren, eller hvis du bruker en webserver på port 80 for å levere andre eiendeler. Dette gjør det nødvendig å proxy til Socket.IO-serveren, og NGINX er den beste måten å gjøre det på. - Bruk av NGINX og NGINX Plus med Node.js og Socket.IO, WebSocket API - nginx blogg

eller HARDENING NODE.JS FOR PRODUKSJONSDEL 3: ZERO DOWNTIME DEPLOYMENTS WITH NGINX

I utgangspunktet leter du mest sannsynlig etter en stabil løsning også for lastbalansering, forespørselsbegrensning osv. Mens du prøver å lagre den private nøkkelen sikkert.

Jeg er ikke sikker på hvordan svaret ditt adresserer spørsmålet. Det diskuteres lagring av private nøkler i en Node.JS SSL-server. Svaret ditt og de to koblingene ser ikke ut til å adressere lagring av private nøkler i det hele tatt.
På denne måten må ingen "betalt" privat nøkkel lagres på vertsserveren. (Antar at det er en bekymring.)
Ahh. Jeg forstår. Bra svar. Kanskje å endre den første setningen til noe sånt som "Ved å bruke en omvendt proxy som nginx for å avslutte SSL, kan du unngå å lagre din private nøkkel på Node.JS helt." Vil gjøre det mindre sannsynlig at folk blir forvirret slik jeg var.
@NeilSmithline: Nå som du har påpekt det, er jeg ganske sikker på at jeg savnet en setning der eller to ...
Kan jeg slette den private nøkkelen når nginx er startet?
Hva ville være brukssaken der, @AmitKumarGupta?
Anta at jeg oppretter 2 brukere på serveren min: sikkerhetsvakt og arbeider.Sikkerhetsvakt håndterer ngnix, SSH-nøkler og andre kreditter.Han driver også sikkerhetstjenester for kryptering / dekryptering.På den andre siden bruker arbeidstaker sikkerhetstjenester uten å være klar over konfidensiell informasjon.For et ekstra sikkerhetslag tenker jeg å slette SSH-nøklene så snart nginx startes, da jeg føler at de ikke er nødvendige.Jeg er imidlertid ikke sikker på om det vil forårsake problemet med autoskalering.
@AmitKumarGupta: husk at SSH og SSL ikke er de samme (https://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl-especially-in-terms-of-sftp-vs-ftp-over-ssl).Jeg tror også at Thomas Pornins svar på dette spørsmålet (https://security.stackexchange.com/a/27890/86513) bør avklare problemet med sletting av den private nøkkelen.


ⓘ
Denne spørsmålet ble automatisk oversatt fra engelsk.Det opprinnelige innholdet er tilgjengelig på stackexchange, som vi takker for cc by-sa 3.0-lisensen den distribueres under.
Loading...