autenticazione ssl client: verifica un solo certificato VS firmato da un ca

0

Sto per garantire un servizio web con l'autenticazione del client. (apache2, mod_ssl, openssl).

da quello che ho cercato su google, ho scoperto che è più comune avere un ca, che firma i certificati del client, che verranno quindi controllati.

ho anche scoperto che dovrebbe essere possibile con l'aiuto della direttiva sslrequire (nella configurazione di apache) per controllare qualcosa , credo che il DN dell'emittente e del soggetto del certificato cliente, o ci sarebbe un campo migliore per questo, al fine di verificare se il cliente ha un certo certificato.

qualcosa come (pseudocodice): sslrequire issuer_dn = 'issuer_dn_from_client_cert' AND subject_dn = 'subject_dn_from_client_cert'

la mia domanda è: funzionerebbe davvero? Voglio dire, se un utente malintenzionato indovinerebbe l'emittente e il DN soggetto - non potrebbe creare un certificato valido?

    
posta frisbee23 02.04.2014 - 13:01
fonte

1 risposta

1

I certificati sono firmati . Quando un server autentica i client tramite certificati, si verificano le seguenti tre cose:

  1. Il client dimostra la padronanza della chiave privata corrispondente alla chiave pubblica contenuta nel suo certificato. Questa parte avviene all'interno di SSL; come parte del protocollo, una firma viene calcolata dal cliente su una sfida dal server. Non devi preoccupartene perché la libreria SSL che usi già lo fa.

  2. Il server convalida il certificato. La convalida consiste nell'assicurarsi che i contenuti del certificato siano autentici. Per convalidare un certificato, il server verifica la firma sul certificato, per quanto riguarda la sua chiave pubblica CA emittente. La chiave pubblica della CA viene ottenuta tramite il certificato CA, che deve essere convalidato, e così via. Questo processo alla fine si lega a una chiave pubblica conosciuta a priori , chiamata trust anchor o root CA .

    Apache SSLCACertificateFile e SSLCACertificatePath vengono utilizzate per configurare quale CA radice verrà utilizzata dal server.

  3. Il server decide se l'utente autenticato dovrebbe avere accesso o meno. Questo è ciò che la direttiva SSLRequire di Apache riguarda: un filtro sulle identità autenticate.

Il primo passo è il metodo con cui il server si assicura che il client sia "chiunque possieda la chiave pubblica K p " (come si trova nel certificato inviato). Il secondo passo è il meccanismo che rivela al server l'identità I del proprietario di K p . Il primo e il secondo passo insieme danno al server una certa garanzia sull'identità del cliente. Ora che il server sa chi sta chiamando, il server deve comunque verificare che il chiamante possa effettivamente effettuare la chiamata. Se vogliamo utilizzare una terminologia rigorosa, i primi due passaggi sono authentication di per sé, mentre il terzo passo è authorization .

Un'analogia:

  • Il cliente è Bob.
  • La chiave privata è la faccia di Bob.
  • Il certificato è la carta d'identità di Bob.
  • La direttiva SSLRequire è l'elenco degli ospiti previsti, nelle mani della guardia di sicurezza.

Bob dimostra che la proprietà di è faccia in virtù del fatto che quel viso è saldamente attaccato al suo corpo (la guardia controlla che la faccia non sia una maschera); questo è il primo passo.

Le guardie della sicurezza ispezionano la carta d'identità, conclude che la carta è autentica (assumiamo qui che le carte d'identità non possono essere falsificate) e che la foto sulla carta d'identità corrisponda al volto della persona che si trova di fronte a lui. Dal momento che il nome di Bob appare sulla carta d'identità, la guardia di sicurezza ora sa che sta parlando con il vero "Bob". Questo è il secondo passo.

Quindi la guardia di sicurezza controlla se il suo elenco di ospiti consentiti contiene il nome di Bob. Se lo fa, lascerà entrare Bob. Altrimenti, manderà via Bob.

Dave, un crasher del partito, vuole far passare la guardia di sicurezza. Per riuscirci, deve sfondare uno di questi passaggi: o prendi una falsa faccia di Bob (con una maschera così perfetta da far ingannare la guardia), o prendi una carta d'identità falsa (con la faccia di Dave ma il nome di Bob), o modificare la lista delle guardie (semplicemente aggiungendo il proprio nome alla lista). Tornando al server Apache, questo significa rubare la chiave privata del client (ad esempio tagliandola crittograficamente - buona fortuna con quella!), Ottenendo un certificato falso (che comporta la corruzione o l'hacking di una CA che Apache è stata configurata per accetta) o modifica la configurazione di Apache (la sua direttiva SSLRequire ). Dal momento che alterare la configurazione di Apache significa che Dave ha già accesso root alla macchina, questo di solito non è un attacco rilevante.

Conoscere il nome di Bob non è sufficiente per Dave. Questa è la risposta alla tua domanda: no, sapere cosa mettere in un certificato falso (l'emittente e il DN soggetto richiesti da SSLRequire ) non consente di creare un certificato falso; l'autore dell'attacco deve ancora corrompere alcuni CA in modo da ottenere il suo certificato firmato (in modo che il server accetti).

    
risposta data 02.04.2014 - 14:44
fonte

Leggi altre domande sui tag