Un server web (diciamo Apache 2.4) implementa SNI. È configurato con un certificato Wildcard firmato SHA384 a 4096 bit (* .land.org) con un nome soggetto alternativo (land.org). L'Autorità di certificazione ha un percorso attendibile per un certificato radice firmato SHA-2 e un secondo percorso fidato per un certificato radice firmato SHA-1. Diciamo anche che questo server web implementa quella che è attualmente considerata una rinegoziazione sicura.
Il server web è configurato per un host virtuale predefinito (wonder.land.org) con solo SSLv3 abilitato, con un certificato SSL contenente una chiave DH1024 univoca e tutti gli antichi e insicuri cifrari nel libro (112 bit fino a cifrari per l'esportazione, ecc. - così accomodante che persino Netscape Communicator sarebbe felice). L'altro host virtuale è land.org con TLSv1.2 e TLSv1.0 abilitati, con 128+ bit cifrari e una chiave DH2048 unica. Gli ordini di cifratura per entrambi gli host virtuali sono dal più strong al più debole in base alle vulnerabilità e alla potenza di crittografia note.
Bob è un utente con un browser moderno che supporta la crittografia Elliptic Curve TLSv1.2 con paranoia contemporanea. Accede quotidianamente al link .
Alice è una curatrice di musei dello Smithsonian che utilizza un browser Web antico che supporta la crittografia delle esportazioni su SSLv3. Accede quotidianamente al link per assicurarsi che la connessione 10BASE2 funzioni ancora sul 486DX2. Poiché il browser Web non supporta SNI, la richiesta di Alice cade attraverso un "foro SNI", restituendo l'host virtuale predefinito (wonder.land.org), che è una pagina HTML 2.0 statica che afferma "Il tuo client web non supporta Server Indicazione del nome ed è vulnerabile a un attacco da barboncino. Ti consigliamo di aggiornare la tua mostra al museo, tuttavia la tua connessione internet funziona davvero. "
Domanda (Sì / No): questo server Web compromette la sicurezza di Bob o la sua (la sicurezza del server)? Prendi in considerazione solo le vulnerabilità attualmente note.