È possibile forzare un browser a utilizzare http in un sito Web abilitato a ssl (https)?

Non è possibile accedere a una pagina protetta da SSL (o TLS) tramite HTTP, poiché ciò significherebbe che la pagina non è più protetta.

Se riformulo la domanda: È possibile accedere a una determinata pagina di un sito Web protetto HTTPS tramite HTTP , quindi direi che è possibile, ma molto INsecure. Inoltre, il cookie con l'ID di sessione dovrà probabilmente essere inviato insieme a ogni richiesta di pagina, in quanto è necessario monitorare la sessione su più pagine. Ciò implicherebbe che è necessario servire quasi ogni pagina su HTTP, il che rende quindi il tuo sito non sicuro.

Nel caso in cui abbiate bisogno del cookie di sessione su una sola pagina, potreste dire al cliente di effettuare una richiesta HTTP a quella pagina, che verrà poi inviata insieme a tutti i cookie che non hanno il flag "sicuro". Tuttavia, ciò significa che tutti questi cookie sono vulnerabili a un attacco MITM e possono essere letti da chiunque ascolti le comunicazioni.

Il mio consiglio: non servire mai consapevolmente una pagina di un sito HTTPS su HTTP.

Quindi la domanda che devi porsi è perché il mio ID di sessione non può essere contrassegnato come sicuro solo . E 'la pigrizia, o c'è un altro motivo per cui non puoi etichettare questo cookie come sicuro?

Ad ogni modo, per forzare un browser a utilizzare sempre HTTPS per un sito Web (e non affidarsi ai reindirizzamenti 302 per visitare la versione HTTPS), è possibile utilizzare HTTP Strict Transport Security. Per ulteriori informazioni, fai riferimento a OWASP .

Sì, certo.

• L'esempio più semplice è l'utente che ha appena inoltrato la richiesta come http: // ..., inconsciamente o per volontà.
• Il server web (potenzialmente dannoso) potrebbe farlo anche solo inviando un reindirizzamento 30x o una pagina con tutti gli ulteriori collegamenti ipertestuali che puntano a http: // invece di https: //

Esempio per quest'ultimo: connettiti al link e atterri su una pagina senza alcuna protezione SSL.

Penso che tu chieda di crittografare i tuoi dati con ssl mentre accederai al tuo server tramite il protocollo http: //. Immagino che sarebbe una buona soluzione per evitare tutti gli avvisi di ssl mantenendo al tempo stesso i dati importanti.

Ho trovato molto interessante questa domanda e andrò avanti a provarlo sul mio server.

Ma, a proposito della domanda, il server non lo farà per impostazione predefinita. Anche se è possibile inviare dati ssl tramite l'interfaccia di ascolto del server http il browser non gestirà correttamente i dati richiesti. Pensa che il processo di decodifica dei dati ssl è in corso quando raggiungi un contenuto https: // url, quindi sicuramente non arriverò in alcun modo a recuperare la crittografia perché non capisco le richieste, in base alla progettazione.

Se l'obiettivo è di consentire alle persone normali (con un normale browser) di avvicinarsi al 100%, è sicuro che il browser non funzionerà con le tue richieste.

Se l'obiettivo è quello di inviare dati SSL utilizzando una connessione http procotol, è necessario modificare / modificare bot server e browser e, attraverso una scansione del traffico, verrà riconosciuta come una connessione http con dati crittografati ssl "illeggibili" su di esso .

Domanda molto interessante. Ho iniziato una piccola ricerca su questo.

Sì, è

Se la negoziazione TLS / SSL fallisce, il browser fallback su HTTP (rimanendo sulla porta HTTPS e sull'URL) , allo stesso modo in cui può eseguire il fallback su SSL3.
Ho preso questo screenshot mentre navigo su GitHub