Certificati SSL interni?

10

Come sviluppatore mi piace molto l'idea di usare OpenSSL per ottenere certificati SSL perfettamente validi e gratuiti. Sfortunatamente, da tutte le ricerche / analisi che ho svolto fino ad ora, non sembra che ci sia un modo per utilizzare OpenSSL in modo tale che i browser dei miei utenti web si fideranno dei certificati che genera per me.

Sembra che, al fine di evitare che i miei utenti ricevano brutti messaggi di avviso dai loro browser (lamentandosi del fatto che i miei certificati generati da OpenSSL non sono attendibili / verificati), dovrò utilizzare un fornitore importante come Trustwave, VeriSign, ecc.

Mi chiedo se esiste un tale concetto di certificati SSL "pubblici" rispetto a "privati"? Con ciò, voglio dire, comprerei un certificato SSL "pubblico" da uno di questi venditori e lo userei per tutte le comunicazioni tra i browser dei miei utenti e i miei server HTTP pubblici. Ma una volta consumato un messaggio sul lato server, esso comunica con il resto del back-end utilizzando certificati "privati" (generati da OpenSSL) diversi.

L'idea alla base di questo è di mantenere i dati in movimento attraverso il mio back-end usando trasporti sicuri, ma non dobbiamo pagare per un multiplo di diversi certificati SSL.

Questo è inaudito o del tutto inutile? O è questa pratica standard?

Perché dovrei aver bisogno che i dati siano sicuri tra 2 dei miei server di back-end? Non lo so. Probabilmente non ha bisogno di , ma probabilmente non potrebbe far male. Pensieri?

    
posta zharvey 02.07.2012 - 16:56
fonte

2 risposte

12

Sì, per il tuo back-end puoi semplicemente generare certificati autofirmati con OpenSSL come hai già fatto. La differenza è che devi quindi istruire i tuoi server di front-end a fidarti di quei certificati (in che modo dipende dalla piattaforma utilizzata).

In alternativa puoi impostare la tua CA privata (autorità di certificazione, ad esempio Verisign) e avere i tuoi server di front-end in grado di fidarti del suo certificato di origine, quindi usarlo per generare certificati per i tuoi server di back-end. Ciò rende più semplice l'utilizzo di molti certificati, a parte il fatto che non c'è differenza.

Questo è esattamente il modo in cui i certificati "pubblici" funzionano, tranne per il fatto che i certificati radice delle ben note CA sono forniti in bundle con ad es. i browser. Sono affidabili perché eseguono controlli ad es. la tua identità, e questo è quello che fanno pagare, non per gli aspetti tecnici della creazione di un certificato.

Ovviamente, c'è la domanda se la comunicazione frontend-backend debba essere protetta. Qualcuno ha la possibilità di ascoltare sulla linea? Dipende dalla tua configurazione di hosting.

    
risposta data 02.07.2012 - 17:02
fonte
6

The idea behind this is to keep data moving through my backend using secure transports, but not have to pay for a bazillion different SSL certs.

Puoi utilizzare link per emettere i tuoi certificati . Li ho usati prima e funziona bene (mostra un lucchetto verde) su tutti i browser che ho provato finora. Il certificato gratuito ti consente anche un sottodominio gratuito.

Se sei disposto a sborsare un po 'di soldi, allora i certificati Classe 2 da loro permetteranno i caratteri jolly, il che significa che puoi avere un certificato per *.yourdomain.com e puoi usarlo per convalidare tutti i tuoi sottodomini per esempio. mail.yourdomain.com , ftp.yourdomain.com ecc. con un singolo certificato.

Anche in questo caso è possibile utilizzare i certificati OpenSSL per le comunicazioni interne come suggerito da Bart. Il modo in cui funzionerà è:

  • Il tuo sito web esterno utilizza un certificato (fornito da startSSL o verisign).
    • I tuoi visitatori accedono ad esso utilizzando https://www.yourdomain.com/whateverpage
    • Poiché proviene da una CA valida (riconosciuta e attendibile dai browser), gli utenti non vedranno mai un avviso SSL. Periodo.
  • Ora supponiamo dal tuo codice, devi chiamare un interno (REST / SOAP) api ospitato su un computer interno.
    • Lo chiami dal tuo codice (usando un resto / soap / qualsiasi client) come https://10.23.42.23/getDetails?user=blah . Supponendo che questo servizio sia in esecuzione su un'istanza di server Web diversa, può utilizzare un certificato SSL openSSL che hai creato. Quando il tuo codice da yourdomain.com interroga questa API su https, sarà su SSL (quindi crittografato) e poiché l'API non viene utilizzata da un browser, ovviamente non segnalerà alcun errore SSL all'utente.
    • Potrebbe tuttavia essere richiesto di configurare il codice (client REST / SOAP) per ignorare eventuali avvisi SSL.

A causa della mancanza di conoscenza della tua esatta architettura, ho fatto generalizzazioni nel mio esempio, tuttavia trasmette le nozioni di base.

Is this unheard of or completely unnecessary? Or is this standard practice?

Non è raro vedere questo tipo di installazione, quindi stai sicuramente pensando nella giusta direzione.

Why would I need that data to be secure between 2 of my own backend servers? I don't know. Probably doesn't need to be, but probably couldn't hurt. Thoughts?

Non danneggerà il fatto che i dati scorrano tra i server di back-end su SSL. Ci sono un paio di vantaggi.

  • Non si può desiderare che un dipendente interno colleghi un tcpdump su una macchina intermedia (attraverso la quale i flussi di dati) e spii il traffico. Con SSL, è sfortunata.
  • Che cosa succede se si desidera spostare la funzionalità di una delle macchine back-end dalla rete (ad esempio cloud - amazon / rackspace). Indovina, non dovrai fare nulla in più per garantire la comunicazione. Questo è già coperto. (Nascono nuovi problemi di MITM, ma questa è una storia diversa)
  • Defense in Depth predica di avere più livelli di sicurezza. Preferirei sicuramente la comunicazione interna su SSL se fosse fattibile. Uno studio pratico stabilisce che SSL / TLS non è più costoso dal punto di vista computazionale . Quindi gravare sul server non è più un problema.
risposta data 03.07.2012 - 00:26
fonte

Leggi altre domande sui tag