Usa HTTP per OCSP come potenziale vulnerabilità? [duplicare]

Question

Usa HTTP per OCSP come potenziale vulnerabilità? [duplicare]

#1 da (21 voti)
#2 da (4 voti)

11

Durante l'ispezione del mio certificato di approvazione CA, ho notato le seguenti stranezze:

Estensioni / Punti di distribuzione CRL:

  Not Critical
  URI: http://crl2.alphassl.com/gs/gsalphasha2g2.crl

Accesso alle informazioni sulle estensioni / autorità:

Not Critical
CA Issuers: URI: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
OCSP: URI: http://ocsp2.globalsign.com/gsalphasha2g2

Le informazioni OCSP non dovrebbero essere pubblicate tramite HTTPS (cioè protetto con TLS), per proteggere contro MITM? Quel campo è solo rumore che non dovrebbe essere usato da un client?

So che sta pubblicando i CRL su HTTP come una potenziale vulnerabilità ? spiega che i CRL sono sempre firmati, quindi non è una vulnerabilità pubblicare i CRL su HTTP. Che mi dici di OCSP?

(In qualche modo correlato a Qualche tecnologia evitare che una CA revochi un certificato unilateralmente? )

tls certificate-authority

posta Phil Lello 21.03.2016 - 14:15

fonte

2 risposte

Leggi altre domande sui tag tls certificate-authority

Come proteggermi dai servizi DDoS a pagamento? Che cosa fanno le varie "modalità private" del browser?

score 21 · Answer 1

Le risposte al CRL e anche a quelle OCSP sono firmate dalla CA. Ciò significa che qualsiasi tipo di manipolazione verrà già rilevata anche se la risposta CRL o OCSP viene trasferita utilizzando un trasporto non sicuro. Pertanto, la protezione contro la manomissione offerta da https non è necessaria.

score 4 · Answer 2

CRL / OCSP è (a mio avviso) il collegamento debole nel modello di sicurezza CA; il fatto che siano firmati dalla CA impedisce a un utente malintenzionato di rendere un certificato revocato apparentemente legittimo, ma può sempre inviare a DOS un certificato legittimo intercettando / bloccando la risposta CRL / OCSP. Senza un CRL / OCSP valido, il certificato non dovrebbe convalidare.

Per le CA pubbliche, non c'è niente che puoi fare a riguardo, ma per gli PKI aziendali privati puoi ospitare i tuoi CRL su una condivisione di rete autenticata all'interno di una VPN (e trucchi simili per OCSP) rendendo quasi impossibile per l'attaccante sapere quale restituire il pacchetto da bloccare, a meno di bloccare l'intera connessione VPN.