OCSP che graffia dettagli e dubbi

Question

OCSP che graffia dettagli e dubbi

#1 da (1 voti)

0

Sto cercando di capire i dettagli della pinzatura OCSP e come funziona. Come spesso il modo migliore è, ho avviato Wireshark e ho fatto una semplice richiesta a un server che ha abilitato la pinzatura OCSP.

Qualcuno può chiarire i seguenti dubbi che ho?

Richiesta
Dati di estensione del cliente Hello:

In Wireshark vedo l'estensione ciao del client come sotto
```
Extension: status_request
  Type: status_request (0x0005)
  Length: 5
  Certificate Status Type: OCSP (1)
  Responder ID list Length: 0
  Request Extensions Length: 0
```
Capisco la presenza dei primi due campi. Ma perché abbiamo bisogno del prossimo 3 ( Certificate Status Type , Responder ID list Length , Request Extensions Length ) poiché sono 0 comunque. Che tipo di dati possono contenere e come si suppone che il server elabori i dati in questi campi?
risposta
Parte della risposta è:
```
Certificate Status Type: OCSP (1)
ResponseType Id: 1.3.6.1.5.5.7.48.1.1 (id-pkix-ocsp-basic)
BasicOCSPResponse
tbsResponseData
responderID: byKey (2)
  byKey: f2026c2ad426a4a59cb2505b3962446034151e5b
```
Quali sono i campi byKey e ResponseType ID ? E come dovrebbe il cliente elaborare lo stesso? Il cliente deve abbinare il Certificate status type a ciò che è stato inviato nel client ciao?
a catena?
Comprendo che i controlli di revoca devono essere eseguiti per tutti i certificati della catena. In che modo si adatta alla pinzatura? Stiamo facendo una stretta di mano solo una volta. Il server è responsabile del mantenimento dello stato di revoca di tutti i certificati nella catena?

tls ocsp

posta Lazy Getter 08.01.2016 - 00:11

fonte

1 risposta

Leggi altre domande sui tag tls ocsp

Come proteggere la rete domestica wireless (Wi-Fi) [chiusa] Come crittografare i dati sull'unità flash per decrittografare su un altro sistema? [chiuso]

score 1 · Accepted Answer

1. Richiesta

[...] why do we need the next 3 (Certificate Status Type, Responder ID list Length, Request Extensions Length)[...]?

Il status_request è definito in RFC 6066, sezione 8. Richiesta di stato del certificato .

Certificate Status Type: OCSP (1)

noioso. È l'unico valore definito al momento. Il campo è per la futura estensibilità, immagino.

Responder ID list Length: 0

Da RFC:

In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement.

E questo è pensato soprattutto per i "client vincolati", come i sistemi embedded, che conoscono solo una manciata di CA.

Da RFC:

"Extensions" is imported from [RFC5280]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).

Non lo so. Non capisco veramente importato da RFC5280 . Ma suppongo che potrebbe riferirsi specificamente alla sezione 5.2.1 di quella RFC5280 . Ma non capisco nemmeno quella sezione.

2. Risposta

[...] What are the fields byKey and ResponseType ID? [...]

Il campo byKey è solo un identificatore per il risponditore OCSP. In modo che il cliente possa decidere se si fida del risponditore / firmatario o meno . E può essere byName o byKey

Does the client need to match the Certificate status type with what was sent in the client hello?

Assolutamente. Ma al momento esiste un solo tipo definito, non c'è altro che OCSP (1) che sarà indefinito / sbagliato / inutile comunque.

3. Catena?

I understand that revocation checks need to be done for all certificates in the chain. How does this fit in with stapling?

AFAIK: non troppo bene. Ma c'è uno sforzo per introdurre "Multi-Stapling" (dal 2013) :

With the necessary support in TLS clients and servers it would be possible to use OCSP stapling for the intermediate CA certificates, too. Checking this information in connection with a stapled OCSP response is referred to as “multi-stapling.”

Multi-stapling should have been as simple as defining a new method for the Certificate Status extension and including that method in the list of methods supported by the client. Unfortunately, that was not the case.