Con la imminente deprecazione di TLS 1.0 per la conformità PCI , ho pensato di confermare qualcosa: quali categorie di risorse referenziate esternamente (se presenti) potrebbero causare un errore di conformità se le loro connessioni TLS 1.0 di dominio ancora accettate dopo il giugno 2018?
La mia ipotesi sarebbe "tutto" dal momento che tutte queste cose sono state utilizzate come vettori di exploit in passato, ma sono curioso di sapere se c'è qualcosa di ufficiale.
Fino ad ora non c'è nulla di ufficiale, ma quasi certamente dipenderà dal giudizio dell'ASV individuale. Questo è quasi sempre il caso di proposito, perché consente alle valutazioni di adattarsi di fronte ai nuovi vettori di attacco e ai diversi contesti.
Ad esempio, in un dominio isolato in cui non è stata immessa alcuna informazione e non è possibile eseguire azioni stateful (ad esempio un portale di collegamento statico all'interno dell'ambiente PCI) nessuno di questi casi è particolarmente critico e mi sbaglierei sul lato di lasciare passa finché l'azienda è in grado di dimostrare un piano a lungo termine per migrare verso una configurazione più sicura.
Al contrario, su un sistema che accetta dati finanziari ed esegue transazioni finanziarie, quasi certamente fallirò per nessuno di questi casi. Script e CSS sono noti per essere vettori XSS, quindi quelli sono i più alti rischi qui. I caratteri, storicamente, sono stati rischiosi per l'endpoint del cliente, ma in genere sono più difficili da sfruttare al di fuori di scenari estremamente mirati. Le immagini sono il rischio più basso qui.
In teoria , PCI richiede solo il rilascio di TLS 1.0 "per salvaguardare i dati sensibili dei titolari di carta durante la trasmissione su reti pubbliche aperte" e per "tutto l'accesso amministrativo non da console" ". Quindi si potrebbe sostenere che cose come le immagini statiche non sono soggette alla proibizione del "primo TLS".
In realtà , tuttavia, la configurazione TLS è un problema per server / applicazione. Se il tuo sito pubblica sia contenuti sensibili che non sensibili, non puoi negoziare TLS iniziale in base al tipo di richiesta, poiché la richiesta viene solo dopo che è stata negoziata TLS. E con HTTP / 1.1, ad esempio, puoi avere una connessione che pipeline più richieste, tutte con lo stesso TLS negoziato. Non è possibile negoziare in anticipo TLS e quindi accettare o rifiutare richieste in base alla loro sensibilità. E anche se tu potessi, se si tratta di una richiesta POST che ti invia dati PAN, il danno è stato fatto dal momento in cui vedi la richiesta.
Quindi scoprirai che gli ASV richiedono la rimozione a livello dell'intero TLS iniziale per qualsiasi sito che abbia contenuti sensibili.
Personalmente, penso che scoprirai che il primo divieto TLS verrà distribuito per coprire tutti gli host e i servizi, interni o esterni, sensibili o meno. Perché l'ASV non vuole rivedere i singoli casi e dire "Oh, hai ragione, questa è l'interfaccia ILO per la tua macchina da caffè, va bene se ha TLS 1.0, perché è solo caffè". Quando SSL 3 è stato vietato alcuni anni fa, la mia esperienza è stata che è stato spogliato universalmente.