Je ne vois que des images en HTTPS pour ma part...

Moi non plus.

Bon, le principe du mécanisme de sécurité est quand même de résister à une attaque, ici une attaque sur le réseau, en général près du client (souvent sur un Wifi ou 1er routeur NAT). Donc il faut supposer qu'on est face à un certificat révoqué pour fraude avec un attaquant qui intercepte les échanges, y compris les échanges OCSP.

Il faut imaginer alors :
1) qu'une attaque MITM a lieu
2) qu'elle utilise un certificat attribué par erreur par une autorité reconnue
3) que le certificat est révoqué
4) que le protocole OCSP est utilisé pour tenter de découvrir ce statut révoqué

Dans cas, rien n'empêche d'intercepter les messages OCSP, sauf que bien sûr les messages sont authentifiés : une réponse OCSP "non révoqué" doit être signée. En revanche, la réponse "mon chien a mangé la liste de révocation" n'est pas authentifiée - et surtout OSEF puisque ça veut dire que le statut de révocation ne peut pas être établi.

Donc un attaquant peut faire échouer la vérification OCSP.

Quoi d'autre peut faire échouer de la même manière la vérification?

- Un problème de connectivité vers le serveur OCSP.
- Une surcharge de ce serveur.
- Donc une attaque DDoS de ce serveur.
- Mais aussi une panne temporaire.

Cela signifie que le serveur OCSP est un gros point central de vulnérabilité du système TLS, tout comme les serveurs DNS sont des points centraux du net, mais bien sûr les serveurs DNS les plus importants sont répartis géographiquement, très fortement redondants, et ils n'ont qu'un tache triviale à accomplir avec précisèment zéro travail cryptographique.

C'est un très gros souci de conception protocolaire. Les protocoles Internet sont conçus pour ne pas créer de telles dépendances.

Cela doit "interpeller" comme on dit.

Et ça a une conséquence pour les concepteurs de logiciels : comment doivent-ils réagir à une indisponibilité d'un serveur OCSP?

Pour vulgariser en faisant une analogie,
Cela pose la question du tiers de confiance et sa "signature", comment donner AAA à un tiers de confiance ?
Sachant que comme le notariat, la signature notariale authentifie envers tous les tiers, l'authenticité de l'acte.
Si on falsifie un acte, le notariat sert de "juge de paix"
Si le notaire est "malade" cela retarde tous les actes notariés et leurs conséquences.
Si le notaire est "malhonnête" que valent ses actes ?
Qui en dernier ressort est à même de qualifier les actes ?

Si on imite ta signature quel recours ?
Si on usurpe ton identité, comment s'en prévenir ?

Pour rendre plus robuste le protocole, on échappe pas à une analyse réelle de ces questions,cela va un peu au delà de la cryptographie en tant que telle.

Je te rejoins sur ces aspects.
Tu sais aussi bien que moi, que le navigateur ne donnera pas d'alerte si l'autorité de certification, ou tiers de confiance est validée par ceux qui éditent les navigateurs.
Rien n'empêche d'être sa propre autorité de certification,cela veut il dire que l'on peut moins y faire confiance ?

Sur le gauchisme et la médiocrité, tu sais déjà depuis longtemps que nous ne sommes pas d'accord,il faut éduquer les gens, c'est la seule arme contre les dérives liées à l'ignorance.

OCSP Stapling permet de répondre a ce cas (attaque DDOS pour faire échouer la vérification OCSP) => c'est le serveur web qui stocke la preuve que le certificat n'est pas révoqué. Effet bonus le temps de chargement est plus rapide vu qu'il n'est pas nécessaire de se connecter a un serveurs tiers.

Autrement dit : OCSP Stapling est la SEULE façon viable de faire de OCSP.

Rien de ce que j'affirme n'est contestable ou même débattable!

MDR

C'est bien pour cela, qu'il est préférable d'être son propre organisme de certificats.
Faire appel à un tiers de confiance même gratuit, cela enlève la procédure d'insertion de clefs dans son trousseau, mais cela s'arrête bien là.
C'est comme "un contrat bilatéral sous sein privé entre deux protagonistes".