Chrome, HTTPS sarà presto il protocollo di navigazione predefinito: come attivare la feature già adesso
Google ha annunciato che imposterà l'HTTPS come protocollo predefinito già dalla prossima versione di Chrome. Quali saranno i vantaggi, e come avere sin da subito l'opzione
di Nino Grasso pubblicata il 25 Marzo 2021, alle 17:21 nel canale WebGoogleChrome
Il browser di Google sceglierà presto l'HTTPS come protocollo predefinito su tutti gli URL inseriti nella barra degli indirizzi. La novità verrà implementata per tutti gli utenti a partire dalla prossima versione stabile di Chrome, dopo un periodo di test pubblico della durata di un mese avvenuto per alcuni utenti dei canali Canary, Dev o Beta del browser di Big G.
La modifica verrà distribuita su Chrome Desktop e Chrome per Android con la versione 90 attesa al debutto il prossimo 13 aprile, mentre su iOS verrà implementata successivamente con tempistiche non ancora ufficializzate dal team di sviluppo. L'obiettivo è di aumentare ulteriormente la sicurezza di navigazione per gli utenti, impedendo ad eventuali aggressori esterni di intercettare il traffico non crittografato gestito dal browser. In più, selezionando HTTPS come protocollo predefinito tutti i siti che lo utilizzano già verranno caricati più velocemente da Chrome.
L'azienda ha spiegato come funzionerà Chrome a partire dalla release 90:
"Chrome utilizzerà di default l'HTTPS per la maggior parte delle navigazioni che non specificano un protocollo. Oltre a essere un miglioramento deciso in fatto di sicurezza e privacy, questa novità migliorerà la velocità di caricamento iniziale dei siti che supportano HTTPS, visto che Chrome si collegherà direttamente all'endpoint HTTPS senza dover eseguire un redirect da http:// a https:// .
Per i siti che non supportano ancora HTTPS, Chrome ripiegherà sulla versione HTTP, anche nel caso in cui il tentativo di caricare la versione HTTPS fallisse (ad esempio quando avvengono errori nei certificati, come name mismatch o certificati self-signed non attendibili, o ancora in seguito a errori di connessione o nella risoluzione del DNS".
Chrome, protocollo HTTPS di default: come attivare subito
Per chi volesse provare in anticipo il nuovo approccio di Chrome la stessa Google ha fornito una procedura semplificata. E' necessario inserire infatti la stringa chrome://flags/#omnibox-default-typed-navigations-to-https nella barra degli indirizzi e abilitare HTTPS come protocollo di navigazione predefinito. Fra le opzioni è possibile inoltre dare al browser 3 o 10 secondi di tempo per determinare la disponibilità del protocollo HTTPS per ogni nuovo URL inserito. Qualora non venisse trovata nel tempo prestabilito Chrome passerà direttamente alla versione HTTP.
MPG X870E CARBON WIFI, la nuova top di gamma MSI per CPU AMD socket AM5
Silent Hill 2 Remake: il ritorno del re dell'horror psicologico
Apple AirPods 4 ANC: incredibili a sopprimere i rumori. La recensione
PLD Space: nuovi razzi spaziali riutilizzabili europei in futuro, una possibile svolta?
SpaceX annuncia il possibile quinto lancio di Starship il 13 ottobre, l'FAA potrebbe non concordare
Attenzione a Perfctl, malware Linux che minaccia milioni di sistemi
Le licenze di VMware arrivano a costare 105 volte di più, AT&T fa causa a Broadcom
Red Dead Redemption arriva finalmente su PC: ecco trailer e data di uscita
AIRO, il robot giocattolo con intelligenza artificiale di Clementoni
Elden Ring: a quasi tre anni dall'uscita, FromSoftware aumenta il salario minimo
Comcast colpita da una grande violazione dei dati: oltre 230.000 clienti coinvolti
LUMIX S 18-40mm F4.5-6.3: piccolo, super grandangolare e full frame
LUMIX S5D ottimizzata per la messa a fuoco automatica LiDAR di DJI
Nuovi firmware per Lumix S9, S5II, S5IIX e G9II
Telefonia: le tariffe italiane sono fra le più basse d'Europa
Il MacBook Air 13'' con chip M3 (2024) è sceso a meno di 1.000 euro per il Prime Day
Vivobook e Zenbook di ASUS protagonisti del Prime Day con offerte imperdibili su Amazon
13 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoA ogni aggiornamento toglie qualche funzionalità e ti dice che è un miglioramento
Ma non solo, semmai non ve ne foste accorti i gruppi di sviluppo di Chrome e Firefox sono gli unici rimasti a vigilare sulle certification authorities che rilasciano certificati https, se non ci fosse il loro apporto ci ritroveremmo con CA che fanno le peggio porcate e nessuno verrebbe a saperlo se non a danno fatto...
Giusto con la release 90 sarà revocata la CA Camerfirma (società controllata da Infocert) che dal 2018 ha fatto una porcata dietro l'altra senza che nessuno intervenisse.
Quando verrà rilasciata quella release succederà un pandemonio (perchè saranno revocate CA - tra cui quella di Infocert - che hanno rilasciato certificati per un'infinità di servizi pubblici) ma almeno ci libereremo di un manipolo di cialtroni.
Perché sarebbe un'assurdità? Per me vale l'esatto contrario: è un'assurdità pretendere di imporre HTTPS ovunque, anche quando non ce ne sia bisogno.
Esempio: se mi voglio vedere un video in streaming, che senso avrebbe passare da HTTPS? HTTP va benissimo per questi scopi: la crittografia di tutti quei dati è del tutto inutile, e anzi appesantisce la comunicazione perché richiede risorse extra sia lato server sia lato client per criptare e decriptare quei dati.
Esempio: se mi voglio vedere un video in streaming, che senso avrebbe passare da HTTPS? HTTP va benissimo per questi scopi: la crittografia di tutti quei dati è del tutto inutile, e anzi appesantisce la comunicazione perché richiede risorse extra sia lato server sia lato client per criptare e decriptare quei dati.
Come sempre è un compromesso tra costi e benefici e i benefici di una connessione cifrata sono infinitamente superiori ai costi, non solo per la cifratura in se ma anche per la protezione intrinseca sulla compromissione del dato nella tratta tra client e server.
Oltre a questo sappiamo benissimo che se qualcuno non fa qualcosa per sanare questa situazione assurda (2 protocolli da gestire per ogni servizi esposto a web) continueranno a esistere servizi critici esposti in chiaro, dove non sarà il video in streaming (che cmq oggi porta con se tutta una serie di dati utili ai fini di identificare l'utente a scopo commerciale, quindi a ben vedere è diventato un oggetto sensibile meritevole di cifratura imho) ma le credenziali di un utente con accessi critici o dati sensibili.
Per me è una scelta obbligata, abbiamo già intrapreso questa strada, tenere il piede in due scarpe ora come ora è già di per se un costo infinitamente superiore a qualsiasi sovraccarico computazionale, già solo gestire due protocolli diversi per ottenere lo stesso risultato è assurdo.
Uno potrebbe anche solo necessitare di leggere le news in formato testuale con un dispositivo di due decadi fa e l'hardware ce la farebbe se non fosse per queste logiche.
Senza poi scomodare i discorsi su cose come l'assenza di istruzione come SSE2 che praticamente archivia una marea di hardware che potrebbero ancora farcela a lavorare nell' epoca del green e del non spreco. Certo hardware ormai obsoleto ma percheè dovrebbe esserlo "a priori"? Tempo fa avevo provato che un Athlon XP se non fosse per l' SSE2 mancante grazie a SSD e GPU "moderne" potrebbe ancora essere usato come macchina home/office.
Ovviamente se hai hardware potente non ci farai nemmeno caso, ma non vale per tutti, per l'appunto.
Ecco perché continuo a pensare che sarebbe meglio separare gli asset fra HTTP e HTTPS.
Ovviamente se hai hardware potente non ci farai nemmeno caso, ma non vale per tutti, per l'appunto.
Ecco perché continuo a pensare che sarebbe meglio separare gli asset fra HTTP e HTTPS.
Seguendo questa logica non andrebbero mantenuti in chiaro solo i servizi dove fai una innocua get (che poi tanto innocua non è perchè se uno nella tratta fa injection di qualche script il browser non potrà mai saperlo) ma anche gli altri dove in post mandi magari informazioni critiche.
Personalmente ritengo che il sovraccarico per il client sia trascurabile, quello che imho però spesso non si considera è anche quanto lavoro e quanto spreco di risorse (hh uomo e moneta sonante) si celi dietro la gestione di due protocolli per pubblicare lo stesso servizio.
Mi tornano in mente le tante quotazioni assurde fatte da società senza scrupoli che solo per il fatto che il tal servizio vada pubblicato in http (con riscrittura in https) e https espongono il doppio delle giornate.
Doppio protocollo = doppie policy sui fw (e quindi doppia attività fatturata), doppiio vip sul balancer di turno (e quindi doppia attività fatturata), doppio virtualhost sul backend del balancer, ma soprattutto problem solving più lungo e laborioso.
Per carità, sono il primo a dire che si tratta di cretinate e che tutto questo ricarico è totalmente ingiustificato (quantomeno dal pdv economico), però questo è quello che vedo passare, e ho perso il conto delle volte che ho visto una verifica andare lunghissima perchè qualcuno ha aveva sbagliato vip andando su quello in http anzichè https, o servizi di backend incazzati esposto in http sul webserver e sul balancer di frontend in https etc etc...
Insomma imho la vita di molti sistemisti sarebbe molto più semplice (e quindi la solidità dei servizi ne guadagnerebbe) se ci liberassimo di un protocollo che di fatto è ridondante.
Probabilmente lato browser / navigazione non avrebbe più senso avere due protocolli da gestire, visto che anche il più scarso degli smartphone ormai ha enorme potenza di calcolo e sicuramente accelerazione hardware della crittografia.
Mi chiedevo se in ambito embedded/IoT non fosse ancora un problema invece, viste le scarse capacità hardware.
Uno potrebbe anche solo necessitare di leggere le news in formato testuale con un dispositivo di due decadi fa e l'hardware ce la farebbe se non fosse per queste logiche.
Senza poi scomodare i discorsi su cose come l'assenza di istruzione come SSE2 che praticamente archivia una marea di hardware che potrebbero ancora farcela a lavorare nell' epoca del green e del non spreco. Certo hardware ormai obsoleto ma percheè dovrebbe esserlo "a priori"? Tempo fa avevo provato che un Athlon XP se non fosse per l' SSE2 mancante grazie a SSD e GPU "moderne" potrebbe ancora essere usato come macchina home/office.
Stiamo parlando della nicchia della nicchia della nicchia, suvvia. Sono un gran sostenitore della retrocompatibilità, ma ci deve essere un limite. Fare tutto retrovomatibile con tutto, implicherebbe uno sforzo enorme dal punto di vista progettuale e una complessità allucinante dei software/sistemi. E' necessario un limite, e a tal proposito, direi che Windows 9x/2000/XP, Athlon XP e loro contemporanei, possono tranquillamente andare in pensione perchè chiaramente obsoleti (senza aggettivi. Semplicemente obsoleti).
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".