http supporta la crittografia senza https (come STARTTLS)?

Question

http supporta la crittografia senza https (come STARTTLS)?

#1 da (12 voti)
#2 da (3 voti)
#3 da (1 voti)
#4 da (-1 voti)

4

http supporta la crittografia senza https , simile a STARTTLS in smtp ?

Potrebbe sembrare una domanda stupida, ma pensaci.

Le banche richiedono una crittografia strong e non possono fare affari senza di essa.

Tuttavia, i normali siti web potrebbero non necessariamente farlo, ma trarrebbero comunque vantaggio dalla crittografia casuale, evitando molti tipi di attacchi, proprio come avviene con STARTTLS in smtp .

Pertanto, per un normale sito Web, se il browser ha problemi con ssl (che si tratti di incompatibilità del protocollo, dispositivo mobile sottodimensionato o preferenza esplicita dell'utente), dovrebbe procedere in modo sicuro senza crittografia senza troppi problemi extra.

Esiste un'estensione del protocollo HTTP che consentirebbe la crittografia senza l'uso esplicito di https ? Per esempio. qualcosa di simile Accept-Encoding: gzip e Content-Encoding: gzip ? O STARTTLS in smtp ? Se no, perché no? Viene in mente persino WPA2 di WiFi, che fa la crittografia, ma non si preoccupa dei certificati o delle autorità di certificazione.

Fondamentalmente, sto pensando a qualcosa come l'estensione HTTPS-Everywhere, ma che funziona automaticamente senza la propaganda virale dello schema di indirizzi https:// - senza forzare le persone che non vogliono farne parte essere parte di esso, come fa lo schema di indirizzi https:// , senza dividere lo schema dell'indirizzo e senza richiedere al provider di contenuti di impegnarsi a supportare sempre https:// da esso.

http tls certificates certificate-authority

posta cnst 01.04.2014 - 19:48

fonte

4 risposte

Leggi altre domande sui tag http tls certificates certificate-authority

Quali regole dovrebbero essere applicate agli utenti per creare una password sicura? Information Security Career track - Certificazioni accademicamente rispetto a quelle IT

score 12 · Answer 1

C'è un standard per STARTTLS in un semplice HTTP. Nota che "STARTTLS" è ancora SSL; modifica semplicemente la dinamica , ma in questo modo non viene evitata la complessità dell'implementazione.

In generale, nessuno usa STARTTLS per HTTP, soprattutto perché è meno sicuro . In effetti, una parte molto importante dei browser SSL-per-Web è il feedback visivo, grazie al quale l'utente viene informato della crittografia (la famosa "icona del lucchetto"). Senza di esso, l'utente non avrebbe modo di sapere se ha veramente SSL, o se sta navigando in un sito falso che saccheggia le sue password e conti bancari.

"incompatibilità del protocollo" e "dispositivo sottodimensionato" sono miti. Qualsiasi dispositivo di abilitante alla navigazione attualmente in esecuzione sa almeno come eseguire SSL 3.0, e questo è sufficiente per una sicurezza decente. Per quanto riguarda il potere, ho personalmente implementato ed eseguito SSL su una CPU ARM embedded a 33 MHz; questo è il tipo di dispositivo che non riterresti degno come un orologio da polso. Anche una semplice smart card di banca, il piccolo chip incorporato in un rettangolo di plastica, ha più potere di quello. Quando la gente dice che non supporta SSL a causa della mancanza di potere, questa è una bugia; quello che dovrebbero dire è che non supportano SSL perché sono pigri.

Come per "preferenza utente": beh, quella è una specie di intangibile. Tuttavia, le cinture di sicurezza sono obbligatorie nelle auto e per buone ragioni. Infatti, la Società nel suo insieme ha il diritto di imporre le cinture di sicurezza indipendentemente dalle "preferenze dell'utente", perché la stessa Società nel suo insieme dovrà sostenere le conseguenze di un guidatore distratto che ha avuto un lieve incidente trasformato in una disabilità drammatica perché lui non aveva la cintura addosso Lo stesso ragionamento vale per SSL: io non voglio permettere agli utenti di "disattivare" SSL quando tale scelta è dannatamente stupida.

score 3 · Answer 2

Tu non dovresti .

Essendo il motivo, lo schema di https:// URI segnala sia all'utente che al browser che sta agendo in un ambiente sicuro, e devono essere prese precauzioni per impedire che le informazioni protette perdano in un ambiente non protetto. Questo è ben compreso e un sistema piuttosto strong. Il meccanismo che un server userebbe per passare da una connessione non sicura a una sicura è un reindirizzamento all'URL sicuro. Il meccanismo che userebbe un client è di richiedere l'URL usando https anziché http. Di norma, questa intera cosa funziona .

Ma per rispondere alla tua domanda in modo più accurato, si esiste una cosa del genere. È l'HTTP / 1.1 Aggiornamento dell'intestazione . Ciò consente al client e al server di negoziare direttamente un protocollo. L'aggiornamento a TLS è descritto in RFC 2817 .

Un client potrebbe inviare un messaggio come questo per scoprire se il server supporta l'aggiornamento (esempio tratto dalla RFC):

   OPTIONS * HTTP/1.1
   Host: example.bank.com
   Upgrade: TLS/1.0
   Connection: Upgrade

Mentre una risposta del server che indica che un aggiornamento è richiesto per visualizzare la risorsa richiesta sarà simile a questo (di nuovo, da RFC):

   HTTP/1.1 426 Upgrade Required
   Upgrade: TLS/1.0, HTTP/1.1
   Connection: Upgrade

Questi sono quasi completamente inutilizzati per le ragioni sopra esposte; dovresti utilizzare l'URI HTTPS. Il meccanismo di "upgrade" è un'opzione inferiore nell'interesse della sicurezza.

Tuttavia, il meccanismo di "upgrade" è usato per altri scopi: in particolare, è come vengono avviate le prese web , e anche uno dei modi in cui un client e un server possono passare al SPDY protocollo.

score 1 · Answer 3

Penso che tu abbia frainteso STARTTLS. Questo comando dice semplicemente all'altro server che i client vogliono eseguire TLS e dopo che il server ha accettato il normale handshake TLS verrà avviato, ad es. con certificati e tutto il materiale - come con https. La differenza principale è che non si esegue il commit a TLS subito dopo la connessione TCP, ma solo dopo aver scambiato alcuni dati di testo normale (messaggio di benvenuto, EHLO ...). E che l'URL non ti dice se viene utilizzato TLS, che potrebbe essere una buona o una cattiva cosa.

Ma sì, HTTP ha un meccanismo simile che è anche ampiamente usato: la richiesta CONNNECT quando si esegue il tunneling attraverso i proxy. Questo è defned RFC2818 e nella stessa RFC è definito anche un altro meccanismo per l'aggiornamento, usando l'intestazione 'Upgrade'. Questo aggiornamento può essere facoltativo (il client vuole ma accetta se il server non lo supporta) o obbligatorio (il server richiede https).

Mentre l'intestazione Upgrade è utilizzata oggi per creare una connessione WebSockets, non l'ho mai vista utilizzata per l'aggiornamento SSL e dubito che tutti i browser lo supportino.

score -1 · Answer 4

Sì, è attualmente in pista per essere definito come un'estensione di HTTP / 2 da link e il supporto effettivo del browser è scritto / impegnato / supportato (bmo # 1003448) e attivato (bmo # 1113790) a fine 2014 e inizio 2015, come per link , che indica che è imminente Mozilla Firefox 37 può essere la prima spedizione del prodotto con Opportunistic Encryption (OE).