L'imposizione di un sito Web per offrire richieste SSL impedisce solo il funzionamento di SSLstrip?

2

Comprendo che l'esecuzione di un sito Web con HSTS può aiutare a impedire a un utente malintenzionato che utilizza KRACK di eseguire il downgrade del sito Web per soddisfare le richieste HTTP.

Cosa succede se il nostro server Web non supporta HSTS?

IIS ha un'impostazione per un sito web in cui può richiedere solo richieste SSL.

Sarà sufficiente a impedire all'utente malintenzionato di utilizzare SSLstrip per eseguire il downgrade di HTTPS su HTTP? Presumo che il server web non riuscirà a fornire traffico non HTTPS, corretto?

    
posta cflyer 17.10.2017 - 18:39
fonte

2 risposte

3

Will that be sufficient enough to prevent the attacker from using SSLstrip to downgrade HTTPS to HTTP?

No.

I would assume the webserver will fail to serve non HTTPS traffic, correct?

No.

Il MitM parlerà https con il tuo server e http con il client.

L'unica vera difesa contro sslstrip è HSTS.

Secondo il link puoi configurare HSTS con IIS con il Finestra di dialogo "Aggiungi intestazione risposta HTTP personalizzata".

Nota: HSTS è attivo solo dopo le prime visite https riuscite. Per proteggere la prima visita, puoi utilizzare il meccanismo del preload: link ma fai attenzione, non è possibile disattivarlo dopo!

    
risposta data 17.10.2017 - 18:42
fonte
3

Solo HTTPS non ti aiuta a proteggerti in questo caso. Questa altra domanda dovrebbe aiutare a illustrare il perché. In breve, se un utente malintenzionato può forzare un client a comunicare su HTTP, l'utente malintenzionato può interagire tra te e il client e agire come un relay, comunicando al client in HTTP e al server in HTTPS.

Sarebbe bello se ci fosse un modo per forzare il client a non tentare mai una chiamata HTTP al tuo server - per fortuna puoi farlo con HSTS. Ma la tipica configurazione HSTS protegge i tuoi utenti se, e solo se, puoi stabilire una connessione sicura prima di un tentativo di attacco. Questo perché HSTS fa affidamento su un Fiducia al primo utilizzo , o TOFU, modello. Se è possibile ottenere un'intestazione HSTS sul computer del cliente prima di qualsiasi attacco, il client sarà al sicuro. Se un utente malintenzionato è già sul posto, può rimuovere l'intestazione HSTS e continuare il suo attacco al client.

Questo può essere evitato se si precarica l'intestazione HSTS. HSTS pre-laoding significa che tu registri il tuo dominio con i fornitori di browser e che codificheranno i loro browser per non consentire mai una connessione non protetta al tuo server. Questo rende molto difficile un attacco SSLstrip perché il client non invierà mai una richiesta HTTP al tuo server. Ma attenzione, il precarico HSTS ha una serie di rischi. Questo altra domanda ha alcuni ottimi riferimenti a HSTS e HSTS Preloading, per favore leggi le domande e le prime 3 risposte per tutti i dettagli.

Come Tom ha menzionato nella sua risposta, puoi configurare HSTS con un'intestazione di risposta HTTP personalizzata. Puoi anche farlo nel tuo file Web.Config:

<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" value="max-age=31536000" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

Nota: questo non include l'attributo preload. Esclude anche l'attributo includeSubDomains che potresti volere anche tu. Ancora una volta, sii molto attento con entrambi questi attributi. Non implementarli ingenuamente.

    
risposta data 17.10.2017 - 22:32
fonte

Leggi altre domande sui tag