Come è giustificato il pericolo / badidea / thisisunsafe?

Naviga le tue risposte
1

Lo standard HSTS afferma quanto segue:

12.1. No User Recourse

Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.

link

Posso capire perché per gli host non HSTS (come i dispositivi di rete) sarebbe utile avere un modo per ignorare rapidamente l'avviso, per impostare e distribuire un certificato valido, poiché questi dispositivi potrebbero venire fuori dalla scatola con un certificato non valido.

Dato che lo standard HSTS afferma che non dovrebbe esserci ricorso da parte dell'utente e che esiste già un --ignore-certificate-errors flag che raggiunge lo stesso obiettivo, qual è la giustificazione per dare agli utenti un modo più semplice per aggirare i problemi dell'HSTS, piuttosto di limitare il bypass agli host non HSTS?

    
posta jrtapsell 14.10.2018 - 14:11
fonte

2 risposte

0

Probabilmente è all'interno della specifica. La frase è cambiata regolarmente , e non è qualcosa che ti capita per caso. Devi sapere cosa stai cercando (ad es. Google 'chrome hsts bypass'), che indica che sei consapevole del rischio.

La barra per l'utilizzo di questo è un lotto più alto di fare clic su "Procedi", in quanto non è documentato nel messaggio di errore mostrato all'utente.

Inoltre, non esiste un'autorità di certificazione quando si tratta di RFC. Alcune parti sono aperte all'interpretazione e non esiste un organismo ufficiale che ti dirà se rispetti o meno una RFC.

Avere un modo per aggirarlo per gli utenti che fanno capiscono che le implicazioni sono a mio parere saggi, in quanto rende più facile analizzare se il tuo sito è sotto attacco o se stai semplicemente indagando per esempio un attacco di phishing contro la tua organizzazione.

In breve: è un atto di equilibrio tra l'essere impossibile e veramente oscuro . Penso che il thisisunsafe sia un ragionevole equilibrio. Improbabile che venga utilizzato da utenti non esperti, ma disponibile quando necessario.

    
risposta data 08.12.2018 - 21:11
fonte
1

È assolutamente è giustificato. Lo standard HSTS è rigorosamente errato, sebbene il suo esatto testo aggiunga almeno due avvertimenti che chiaramente consentono varie opzioni, incluse tali caratteristiche "nascoste" come passphrase segrete, o una flag da riga di comando, o forse anche la possibilità di registrare un sito / indirizzo / certificato / etc. come di fiducia. Tutto ciò che davvero non consente è il pulsante "continua" diretto.

Ovviamente si dovrebbe usare qualsiasi soluzione alternativa di sicurezza se si sa esattamente cosa si sta facendo.

Non sono d'accordo sul fatto che la passphrase segreta attualmente usata da Chrome sia comunque ideale; e penso che il blank --ignore-certificate-errors sia un martello molto grande e inutilizzabile. Credo che il meccanismo utilizzato originariamente (almeno su macOS e penso che Windows) per cui un certificato possa essere registrato come affidabile (forse solo per siti e / o utenti specificati) è stato infinitamente migliore, e il fatto che Chrome ignori silenziosamente tali impostazioni ora è comportamento aberrante e un enorme errore di UX.

In effetti, penso che il solo pulsante "procedere comunque" sia rimasto nascosto per tutte le pagine di avviso, anche se forse avrebbe dovuto chiedere la tua password o qualche altro fastidio.

La parte più noiosa dell'attuale UX in Chrome è lo stupido e inutile suggerimento che l'utente possa "aspettare e riprovare".

    
risposta data 15.11.2018 - 22:55
fonte

Leggi altre domande sui tag

SSH su VPN bloccato su determinate reti Proteggi l'app da Http Proxy come Charles [duplicato]