Quali sono le implicazioni per la sicurezza di abilitare un foro SNI su un server web?

8

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.

    
posta vallismortis 16.06.2015 - 03:05
fonte

1 risposta

3

Il mio intuito era che preferirei indirizzare le connessioni senza SNI a un server diverso (non lo stesso a servire Bob), e tramite mezzi esterni allo stesso server. Qualcosa come un firewall Deep Packet Inspection che guarda effettivamente alle versioni ClientHello e alla parte SNI.

Posso vedere due ragioni per cui il foro SNI viene analizzato nello stesso server:

1) L'indicazione del nome del server TLS e le intestazioni host sono funzioni completamente diverse a diversi livelli di protocollo, ma hanno uno scopo molto simile. Per questo motivo, potrebbe non essere nell'interesse dei creatori di software server interpretarli in modo diverso - e potrebbe essere un po 'difficile continuare a testare che il comportamento di selezionare l'host virtuale sta accadendo a livello di SNI TLS - quindi ad un aggiornamento futuro , Bob potrebbe finire nel server non sicuro con un cookie che non avrebbe dovuto essere inviato tramite questo metodo (o Alice potrebbe ricevere un errore invece di una spiegazione rilassante sulla sua connessione.)

2) Mantenendo tutti i cifrari deboli e le variazioni del protocollo nello stesso server, il software del server viene mantenuto complicato e probabilmente aperto per vettori di attacchi sconosciuti che in qualche modo riescono a ripristinare / eseguire il rollback su versioni non sicure del protocollo.

    
risposta data 19.12.2015 - 01:22
fonte

Leggi altre domande sui tag