Link alla notizia: https://www.hwupgrade.it/news/web/google-da-settembre-niente-piu-indicatore-sicuro-per-i-siti-https_75995.html

Google sta per cambiare qualcuno degli indicatori visivi di Chrome, tra cui quello che conferma l'attendibilità dei siti HTTPS

Click sul link per visualizzare la notizia.

Non sicuro come ad esempio http://www.trenitalia.com/ ? :D

Non sicuro come ad esempio http://www.trenitalia.com/ ? :D

se ti logghi sul sito allora parli in https come è ovvio che sia

@coschizza
ma anche no...
se tu arrivi su un sito classificato non sicuro e ti logghi con delle credenziali per entrare in modalità sicura non è affatto corretto che sia così.

il sito deve risultare sicuro PRIMA di dover inserire le credenziali... altrimenti rischieresti di inserire le tue credenziali anche su siti creati di proposito per il phishing...

Ah ah,... han capito che facendo i furbetti poi rischiavano, eh?

Per chi non fosse aggiornato sulla faccenda spieghiamo meglio:
google ha inserito la scritta NON SICURO per creare allarmismi spesso inutili, verso i semplici siti non in https (magari siti statici semplici dove non passavano dati sensibili).


Mentre creava allarmismo, allo stesso tempo promuoveva una sua azienda che vendeva certificati. Un caso???? :doh:

@coschizza
ma anche no...
se tu arrivi su un sito classificato non sicuro e ti logghi con delle credenziali per entrare in modalità sicura non è affatto corretto che sia così.

il sito deve risultare sicuro PRIMA di dover inserire le credenziali... altrimenti rischieresti di inserire le tue credenziali anche su siti creati di proposito per il phishing...

Veramente no, i meccanismi di sicurezza dipendono dalla uri che si usa per il login, il fatto che la pagina di landing sia anch'essa su https è solo un espediente psicologico per non spaventare gli utenti che non lo sanno.

@Wikkle
C'è anche cPanel che vende certificati e li da a tutti i loro clienti, quindi i certificati oramai sono disponibili a chiunque.

Però la cosa non mi piace perché in questo modo Internet è stata centralizzata anche se solo per un aspetto.

Mentre creava allarmismo, allo stesso tempo promuoveva una sua azienda che vendeva certificati. Un caso???? :doh:
I certificati si ottengono gratuitamente con Let's Encrypt. Non esiste più nessun motivo per mantenere un sito su HTTP. Condivido pienamente l'approccio di Google e spero che anche gli altri browser seguano l'esempio.

I certificati si ottengono gratuitamente con Let's Encrypt. Non esiste più nessun motivo per mantenere un sito su HTTP. Condivido pienamente l'approccio di Google e spero che anche gli altri browser seguano l'esempio.

Vedrai quante truffe ci saranno con siti contraffatti sicuri per google perchè certificati.
Ma davvero credi che un semplice certificato possa rendere il web più sicuro?
Secondo la mia opinione la gente si sentirà sicura e farà caxxate.

Secondo la mia opinione la gente si sentirà sicura e farà caxxate.
Un motivo in più per rimuovere la dicitura "Sicuro" e segnalare invece come "Non sicuri" i siti che non adottano alcuna protezione a livello di trasporto.

Ma davvero credi che un semplice certificato possa rendere il web più sicuro?
Certo, serve a ridurre drasticamente gli attacchi man-in-the-middle, ovvero gente che sniffa il tuo traffico mentre stai usando la Wifi aperta dell'hotel o dell'aeroporto.
Poi, è ovvio, se l'utente vuole mettere la sua carta di credito in un sito di phishing, la sola presenza di un certificato non glielo impedirà di sicuro.

@Wikkle
C'è anche cPanel che vende certificati e li da a tutti i loro clienti, quindi i certificati oramai sono disponibili a chiunque.


Hai detto bene, VENDE. Di autorità che vendono certificati ce ne sono a bizzeffe. E quindi?

I certificati si ottengono gratuitamente con Let's Encrypt. Non esiste più nessun motivo per mantenere un sito su HTTP. Condivido pienamente l'approccio di Google e spero che anche gli altri browser seguano l'esempio.

Evidentemente non sei molto informato sullo sviluppo web, perchè è vero che Let's Encrypt esiste ed è gratuito, ma funziona a dovere solo su linux. E i server non sono solo linux, anzi...

Di motivi per avere un sito in http ce ne sono e parecchi, in primis i miliardi di siti statici che non passano 1 sola informazione sensibile e ciò nonostante sono marchiati come NON SICURI, spavenatando inutilmente gli utenti poco esperti.

Un motivo in più per rimuovere la dicitura "Sicuro" e segnalare invece come "Non sicuri" i siti che non adottano alcuna protezione a livello di trasporto.


Certo, serve a ridurre drasticamente gli attacchi man-in-the-middle, ovvero gente che sniffa il tuo traffico mentre stai usando la Wifi aperta dell'hotel o dell'aeroporto.
Poi, è ovvio, se l'utente vuole mettere la sua carta di credito in un sito di phishing, la sola presenza di un certificato non glielo impedirà di sicuro.

Troppi csi ncis.
Davvero credi che ancora ci sia gente che che in aereoporto o hotel si mette a dare dati in giro?
ormai tutti hanno app su cell per fare di tutto, e le transazioni sono a doppia verifica.
Poi se vai su siti dubbi per dubbi motivi il certificato o la dicitura poco sicuro è utile come un congelatore al polo nord

ormai tutti hanno app su cell per fare di tutto

momento… spiega, spiega :D

Beh infatti ci sono tonnellate di siti statici di pura informazione che non vedo perchè debbano essere su HTTPS..

Beh infatti ci sono tonnellate di siti statici di pura informazione che non vedo perchè debbano essere su HTTPS..

Probabilmente è stato un caso isolato, ma è già successo che nelle connessioni http sul wifi di un aereo veniva iniettata pubblicità nelle pagine.

Quando leggo commenti come quelli di piedone capisco che continuerò a fare il mio lavoro per molti anni a venire... grazie

Veramente no, i meccanismi di sicurezza dipendono dalla uri che si usa per il login, il fatto che la pagina di landing sia anch'essa su https è solo un espediente psicologico per non spaventare gli utenti che non lo sanno.Attenzione ad un dettaglio che in realtà è fondamentale.
Dal punto di vista del protocollo utilizzato per la comunicazione, una form non è "sicura" solo perchè la action punta ad una url raggiungibile con protocollo https.
Come giustamente fatto notare da GM Phobos anche la form stessa DEVE essere esposta in https, in caso contrario si presta a tutta una serie di manomissioni, ad esempio modifica alla url della action per puntare ad altro e raccogliere i dati di login.
Improbabile? Impossibile? Non direi, pensa anche soltanto ad un accesso wifi libero, basta entrare in una bar o un ristorante con un raspberry pi che agisce da rogue spot e proxy e aspettare che la gente si attacchi con ogni dispositivo per spazzolare credenziali.
Non serve essere geni o avere chissà quali software per farlo, solo un minimo di skill e la volontà di farlo.

Hai detto bene, VENDE. Di autorità che vendono certificati ce ne sono a bizzeffe. E quindi?

Evidentemente non sei molto informato sullo sviluppo web, perchè è vero che Let's Encrypt esiste ed è gratuito, ma funziona a dovere solo su linux. E i server non sono solo linux, anzi...
Aspetta, per prima cosa Let's Encrypt non funziona solo su linux, esistono implementazioni del protocollo ACME e relativi client anche in Powershell, es https://github.com/ebekker/ACMESharp e https://github.com/PKISharp/win-acme, ergo anche su Windows si può usare Let's Encrypt direttamente.

In secondo luogo occorrono 5 minuti 5 per configurare una qualsiasi distribuzione con Apache con dei virtualhost che agiscano da reverse proxy.
Apache agisce da endpoint https e inoltra tutte le richieste verso IIS in modo da semplice e trasparente, con in più tutti i vantaggi del caso, logging che IIS si sogna, rewrite che su IIS sono impossibili o richiedono sforzi sovrumani e tanto tanto tanto altro ancora.

Ci sono persino provider e cdn (es i servizi di Cloudflare) che forniscono gratuitamente servizi di endpoint https per stimolare l'uso del protocollo https.

Di motivi per avere un sito in http ce ne sono e parecchi, in primis i miliardi di siti statici che non passano 1 sola informazione sensibile e ciò nonostante sono marchiati come NON SICURI, spavenatando inutilmente gli utenti poco esperti.Probabilmente è stato un caso isolato, ma è già successo che nelle connessioni http sul wifi di un aereo veniva iniettata pubblicità nelle pagine.

Una decina di anni fa sarei stato d'accordo con voi, ma oggi non più.
L'equazione "sito statico=sito sicuro, semplice e innocuo" ormai non è più vera; le esigenze del design web, dei dispositivi e le richieste dei clienti sono tali per cui ormai persino le pagine statiche di cortesia sono diventate un'accozzaglia di javascript e framework che fanno tutto e il contrario di tutto.
Ecco perchè anche il progetto più banale ormai non può fare più a meno di garantire la comunicazione tra webserver e client, e questo può essere fatto solo con il protocollo https.
I casi di siti manomessi (e non parlo di xss o sql injection eh, manomissioni avvenute e applicabili anche ai siti statici) al fine di inserire javascript malevolo per fare tutto e il contrario di tutto (incluso mining di criptomonete) sono stati tanti e tanto clamorosi da aver smontato il paradigma di cui parlavo sopra.

Un'ultima nota, leviamoci dalla testa l'idea che solo i dati "sensibili" sono critici, ormai lo sono anche i dati "personali", e l'interpretazione generale ormai è che qualsiasi dato che permette di identificare l'utente è "personale", ergo anche associazione tra IP e dettagli del client, vedi GDPR.

Quando leggo commenti come quelli di piedone capisco che continuerò a fare il mio lavoro per molti anni a venire... grazie

hai ragione :D

Troppi csi ncis.
Davvero credi che ancora ci sia gente che che in aereoporto o hotel si mette a dare dati in giro?
ormai tutti hanno app su cell per fare di tutto, e le transazioni sono a doppia verifica.
Poi se vai su siti dubbi per dubbi motivi il certificato o la dicitura poco sicuro è utile come un congelatore al polo nordSono anni che periodicamente tutti gli assessment di sicurezza danno risultati a dir poco allarmanti sulle app mobile.

Per prima cosa l'autenticazione multifattore non è implementata ovunque e non è certo obbligatoria (ci sarebbe molto da discutere nel dettaglio anche su questa comunque).
In secondo luogo tu pensi che il fatto che una app sia distribuita tramite i canali ufficiali la renda sicura a prescindere?
Basta un pc con Wireshark, un hub e un access point per sniffare tutto il traffico di uno smartphone e rendersi conto della quantità industriale di traffico che passa in chiaro.

Sono anni che periodicamente tutti gli assessment di sicurezza danno risultati a dir poco allarmanti sulle app mobile.

Per prima cosa l'autenticazione multifattore non è implementata ovunque e non è certo obbligatoria (ci sarebbe molto da discutere nel dettaglio anche su questa comunque).
In secondo luogo tu pensi che il fatto che una app sia distribuita tramite i canali ufficiali la renda sicura a prescindere?
Basta un pc con Wireshark, un hub e un access point per sniffare tutto il traffico di uno smartphone e rendersi conto della quantità industriale di traffico che passa in chiaro.

basta usare la vpn in tutti i contesti dove metti dati sensibili
io mi ero abbonato a pure vpn ad esempio

basta usare la vpn in tutti i contesti dove metti dati sensibili
io mi ero abbonato a pure vpn ad esempioNel caso di hotspot wifi la vpn è un ottimo strumento, però attenzione a un dettaglio: se l'applicazione comunica in chiaro, usando una vpn il dato passa cifrato tra il tuo dispositivo e il gateway della vpn, poi comunque passa in chiaro attraverso una rete che è insicura per definizione.
In sostanza sposti il problema, ma non lo risolvi ;)
L'adozione del protocollo https invece è una soluzione strutturale, ecco perchè è quella preferibile.

Sia chiaro, questo è il requisito, poi bisogna vedere come è implementato il protocollo https, che cypher suites usa, l'hardening etc etc...
Insomma come è facile intuire è un processo complesso che implica una serie di variabili, alcune le possiamo controllare, altre no, però possiamo per lo meno verificarle ed essere coscienti per valutare costi/benefici.

Tanto per dirne una, sto lavorando per un cliente che usa un noto provider di pagamenti con carta di credito, ebbene questi dal 18 giugno disattivano l'hardshake https con protocollo TLS 1.0, benissimo... peccato che da un banalissimo test la loro configurazione del protocollo https si presti a millemila vulnerabilità e sia stata fatta con i piedi... :eek: :rolleyes:

Evidentemente non sei molto informato sullo sviluppo web, perchè è vero che Let's Encrypt esiste ed è gratuito, ma funziona a dovere solo su linux. E i server non sono solo linux, anzi...

Io sono uno sviluppatore web di professione e lo uso anche su IIS a manetta. Tu che lavoro fai?

Nel caso di hotspot wifi la vpn è un ottimo strumento, però attenzione a un dettaglio: se l'applicazione comunica in chiaro, usando una vpn il dato passa cifrato tra il tuo dispositivo e il gateway della vpn, poi comunque passa in chiaro attraverso una rete che è insicura per definizione.
In sostanza sposti il problema, ma non lo risolvi ;)
L'adozione del protocollo https invece è una soluzione strutturale, ecco perchè è quella preferibile.


oh grazie non so di informatica fino a queste cose
io al massimo modifico registri e costruisco macchine

mi confermi quindi che in viaggio la vpn è un ottima soluzione per collegarsi ai vari wi fi di ostelli etc etc
che ne so per pagare booking.com etc
io uso tra l altro poi spesso la connessione con temviewer a macchina in italia dove ce linux e da li uso paypal etc etc.. (se le velocita me lo consentono...)
questo come lo vedi?

Sono anni che periodicamente tutti gli assessment di sicurezza danno risultati a dir poco allarmanti sulle app mobile.

Per prima cosa l'autenticazione multifattore non è implementata ovunque e non è certo obbligatoria (ci sarebbe molto da discutere nel dettaglio anche su questa comunque).
In secondo luogo tu pensi che il fatto che una app sia distribuita tramite i canali ufficiali la renda sicura a prescindere?
Basta un pc con Wireshark, un hub e un access point per sniffare tutto il traffico di uno smartphone e rendersi conto della quantità industriale di traffico che passa in chiaro.

App sicure?
Di sicuro c'è solo la morte, bello mio.
Semplicemente si sta intorbidendo l'acqua solo per creare falsa sicurezza.
La puntatina alle app non era definita come:
app>wifi>servizio
Piuttosto come:
App>umts>servizio.

Accedere ad una rete libera e/o non sicura ( vale anche per i millemila modem router domestici e non solo) espone di fatto ad una miriade di vulnerabilità che inficiano la sicurezza dello stesso protocollo https ( sicuro fin quando non si scoprono falle nelle deverse implementazioni, e famoso è stato il bug su OpenSSL che rendeva vittime i server di destinazione).
Oppure ci siamo dimenticati di tutti i certificati che ogni tanto vengono trafugati o flsificati?
Semplicemente per i dati sensibili ( e per dato sensibile intendo tutto quello che mi riguarda, compresi i miei gusti musicali) sono sicuri solo quelli che non mostriamo.
Quello che dico è che con sta voglia di https ( da verificare la reale ricaduta positiva) si instaurerà una falsa sicurezza nell'utente poco famigliare con l'argomento ( ed a quando vedo ci sono diversi sysadmin tra loro).
Purtroppo una vpn e https ti garantiscono sufficiente sicurezza se l'utilizzatore è anche il proprietario dei due punti ( un organizzazione multisede).
Ma se clono il sito sella.it ( pe) sul dominio da me registrato sella.one o su sellla.it o sela.it (ecc) la falsa sicurezza dell'https mieterà molte vittime prima che la gente capisca che https non è sinonimo di sicurezza ma connessione criptata tra due punti (del quale non saprai mai se dall'altra parte ci sia con certezza chi ti aspetti)

oh grazie non so di informatica fino a queste cose
io al massimo modifico registri e costruisco macchine

mi confermi quindi che in viaggio la vpn è un ottima soluzione per collegarsi ai vari wi fi di ostelli etc etc
che ne so per pagare booking.com etc
È sufficiente HTTPS. Quando digiti l'indirizzo di un sito assicurati di digitare anche https:// in modo che anche la primissima richiesta avvenga in maniera sicura. Questo accorgimento diventerà non necessario col tempo, quando si diffonderà l'uso della HSTS preload list gestita da Chromium e riutilizzata anche dagli altri browser.
Poi fai caso agli avvisi del browser: se ti dice che il sito non è sicuro, smetti immediatamente di navigare.
Inoltre vai nelle impostazioni del tuo browser e verifica che i protocolli SSL 3.0 e TLS 1.0 siano disabilitati. Qui trovi scritto come fare:
https://www.ssl.com/how-to/turn-off-ssl-3-0-and-tls-1-0-in-your-browser/

Fatto questo sei a posto, non occorre alcuna VPN.
Se no passa il messaggio che HTTPS di per sé non è sufficiente.

io uso tra l altro poi spesso la connessione con temviewer a macchina in italia dove ce linux e da li uso paypal etc etc.. (se le velocita me lo consentono...)
questo come lo vedi?
Lo puoi fare ma non aggiunge nulla alla sicurezza se segui i consigli di cui sopra. Anzi, in questo modo fai passare il traffico per i server di Teamviewer e sei tu stesso che aggiungi un intermediario alla comunicazione quando sarebbe meglio evitarlo.

Usa sempre dispositivi tuoi e non quelli che trovi nella hall degli hotel o agli internet café, che potrebbero avere dei keylogger installati.

Usa sempre dispositivi tuoi e non quelli che trovi nella hall degli hotel o agli internet café, che potrebbero avere dei keylogger installati.

sai come ho risolto? riavvio i pc che trovo in giro con la mia pendrive linux e faccio il boot da li.. ogni tanto mi guardano storto...

Io sono uno sviluppatore web di professione e lo uso anche su IIS a manetta. Tu che lavoro fai?

Idem, e non solo.
Però per i clienti che richiedono sicurezza aggiuntiva preferisco affidarmi a servizi a pagamento (fatturando al cliente il di più).

Senza far gara a chi ne sa di più… ti chiedo se tu usi let's ecnrypt su iis, con cosa lo usi?
Perché tempo fa mi ero informato e su iis in effetti non funzionava benissimo quindi abbandonato per scelta, magari ora le cose sono cambiate. Hai consigli?

fai passare il traffico per i server di Teamviewer
Questo è una pessima cosa... in molti non lo sanno e si affidano tranquillamente a TW senza sapere che tutto ciò che fanno passa completamente dai loro server.

Prima hanno costretto tutti a comprare certificati ssl spendendo anche cifre importanti per avere l'Extended validation per avere il nome verde accanto al lucchetto... e adesso tolgono tutto?

per i distratti let's encrypt e' solo macchinoso da usare... ma una volta ottenuto il certificato, gira su qualsiasi server... non ci sono vincoli linux-windows.

chi vuole EV invece deve comunque spendere... non basta let's encrypt

Prima hanno costretto tutti a comprare certificati ssl spendendo anche cifre importanti per avere l'Extended validation per avere il nome verde accanto al lucchetto... e adesso tolgono tutto?

per i distratti let's encrypt e' solo macchinoso da usare... ma una volta ottenuto il certificato, gira su qualsiasi server... non ci sono vincoli linux-windows.

chi vuole EV invece deve comunque spendere... non basta let's encrypt

Chi? Google intendi? Si, ha fatto terrore psicologico per rivendere i certificati della azienda con cui collaborava… ora ha capito che si rischiava grosso, e ha ammorbidito la faccenda togliendo il lucchetto e scritta :doh:

In pochi la sanno questa furbata..

Ah ah,... han capito che facendo i furbetti poi rischiavano, eh?

Per chi non fosse aggiornato sulla faccenda spieghiamo meglio:
google ha inserito la scritta NON SICURO per creare allarmismi spesso inutili, verso i semplici siti non in https (magari siti statici semplici dove non passavano dati sensibili).


Mentre creava allarmismo, allo stesso tempo promuoveva una sua azienda che vendeva certificati. Un caso???? :doh:


Chi? Google intendi? Si, ha fatto terrore psicologico per rivendere i certificati della azienda con cui collaborava… ora ha capito che si rischiava grosso, e ha ammorbidito la faccenda togliendo il lucchetto e scritta :doh:

In pochi la sanno questa furbata..

Credo tu non abbia compreso bene la notizia ... il "non sicuro" sui siti HTTP rimane, semplicemente viene tolto il "sicuro" ed in futuro il lucchetto sui siti HTTPS

(Per informazione: l'azienda con cui collaborava sarebbe...? E dove l'avrebbe promossa?)

Credo tu non abbia compreso bene la notizia ... il "non sicuro" sui siti HTTP rimane, semplicemente viene tolto il "sicuro" ed in futuro il lucchetto sui siti HTTPS

(Per informazione: l'azienda con cui collaborava sarebbe...? E dove l'avrebbe promossa?)

Hai ragione, la scritta non sicuro resta :doh:

Comunque l'azienda è (o era) questa https://www.ssls.com/

Nulla di ufficiale, ma quando da chrome cliccavi su "non sicuro", dava il consiglio di prendere il certificato e mettevano proprio il link a quel sito (che tra l'altro è fatto in stile siti di google).

Qualcosa avrò voluto dire, no?

Perché tempo fa mi ero informato e su iis in effetti non funzionava benissimo quindi abbandonato per scelta, magari ora le cose sono cambiate. Hai consigli?
Uso win-acme (https://github.com/PKISharp/win-acme/releases) (anche chiamato letsencrypt-win-simple). È vero che a volte possono verificarsi problemi nell'ottenimento del certificato ma non dipendono dal tool ma da IIS stesso o dall'applicazione. Il tool posiziona un file statico senza estensione in una sottodirectory della root del sito IIS e poi il server di Let's Encrypt prova a raggiungere quel file dall'esterno usando il suo URL http. Se ci riesce, è la prova che chi ha iniziato la procedura è il legittimo proprietario del sito in quanto quell'hostname si risolve con l'ip di quella macchina.
A volte però la richiesta al file statico non va a buon fine perché in IIS non è stato abilitato l'extensionless handler. Il tool ti dice nel suo output come risolvere il problema ma trovi la procedura per abilitarlo anche in questo articolo, tra i commenti.
https://weblog.west-wind.com/posts/2016/Feb/22/Using-Lets-Encrypt-with-IIS-on-Windows

Se l'applicazione è ASP.NET Core è leggermente più ostico perché i contenuti statici devono essere inseriti all'interno della directory wwwroot, anziché nella root del sito IIS. Il file statico di Let's Encrypt, quindi, diventa irraggiungibile perché IIS normalmente passa tutto il traffico all'applicazione. C'è modo di risolvere anche questo, come vedi qui.
https://weblog.west-wind.com/posts/2017/Sep/09/Configuring-LetsEncrypt-for-ASPNET-Core-and-IIS
Se incontri problemi particolari non coperti nei due articoli, vieni a postare su Aspitalia e vediamo che si può fare.

Uso win-acme (https://github.com/PKISharp/win-acme/releases) (anche chiamato letsencrypt-win-simple). È vero che a volte possono verificarsi problemi nell'ottenimento del certificato ma non dipendono dal tool ma da IIS stesso o dall'applicazione. Il tool posiziona un file statico senza estensione in una sottodirectory della root del sito IIS e poi il server di Let's Encrypt prova a raggiungere quel file dall'esterno usando il suo URL http. Se ci riesce, è la prova che chi ha iniziato la procedura è il legittimo proprietario del sito in quanto quell'hostname si risolve con l'ip di quella macchina.
A volte però la richiesta al file statico non va a buon fine perché in IIS non è stato abilitato l'extensionless handler. Il tool ti dice nel suo output come risolvere il problema ma trovi la procedura per abilitarlo anche in questo articolo, tra i commenti.
https://weblog.west-wind.com/posts/2016/Feb/22/Using-Lets-Encrypt-with-IIS-on-Windows

Se l'applicazione è ASP.NET Core è leggermente più ostico perché i contenuti statici devono essere inseriti all'interno della directory wwwroot, anziché nella root del sito IIS. Il file statico di Let's Encrypt, quindi, diventa irraggiungibile perché IIS normalmente passa tutto il traffico all'applicazione. C'è modo di risolvere anche questo, come vedi qui.
https://weblog.west-wind.com/posts/2017/Sep/09/Configuring-LetsEncrypt-for-ASPNET-Core-and-IIS
Se incontri problemi particolari non coperti nei due articoli, vieni a postare su Aspitalia e vediamo che si può fare.

Ti ringrazio molto per la spiegazione chiara. Farò le dovute prove, perché purtroppo questa cosa và risolta.

Hai ragione, la scritta non sicuro resta :doh:

Comunque l'azienda è (o era) questa https://www.ssls.com/

Nulla di ufficiale, ma quando da chrome cliccavi su "non sicuro", dava il consiglio di prendere il certificato e mettevano proprio il link a quel sito (che tra l'altro è fatto in stile siti di google).

Qualcosa avrò voluto dire, no?

Personalmente non ho mai notato la dicitura (ma potrei non averci fatto caso) né ho mai letto nulla in giro a riguardo (ed ho provveduto a cercare meglio ora), ma in ogni caso non credo collabori con l'azienda in questione...

Anche perché se poi voleva fare la scorrettezza promuoveva Google Domains (https://domains.google) che era il suo, inoltre nel suo post sul blog (https://blog.google/topics/safety-security/say-yes-https-chrome-secures-web-one-site-time/) promuove proprio Let's Encrypt

Dulcis in fundo, mi pare strano ed inverosimile che consiglino nella barra degli indirizzi di utilizzare un certificato da uno specifico sito, in quanto è lo sviluppatore che deve installare il certificato non l'utente che visita il sito... che tu gli fai avere quel messaggio a tutta l'utenza ... a che pro? Che se lo compra l'utente e glielo installa al sito?

E per far arrivare agli sviluppatori/amministratori tale messaggio potevano utilizzare tranquillamente Google Search Console, senza scomodare l'interfaccia di Google Chrome

p.s.
E no, decisamente non è nello stile di Google il sito in questione, basta che vedi Google Domains stesso o anche Adwords (https://adwords.google.com/home/) per vedere lo stile di google

Personalmente non ho mai notato la dicitura (ma potrei non averci fatto caso) né ho mai letto nulla in giro a riguardo (ed ho provveduto a cercare meglio ora), ma in ogni caso non credo collabori con l'azienda in questione...


La questione infatti non era evidente… ma se da chrome + avviso "non sicuro" si arrivava al sito che ti ho detto (tra tutte le aziende che vendono certificati) un qualcosa di collegato tra loro c'era. Non credi?


Ora non ho avuto modo di approfondire, ma qualche mese fa era proprio così.

La questione infatti non era evidente… ma se da chrome + avviso "non sicuro" si arrivava al sito che ti ho detto (tra tutte le aziende che vendono certificati) un qualcosa di collegato tra loro c'era. Non credi?


Ora non ho avuto modo di approfondire, ma qualche mese fa era proprio così.

No, non credo assolutamente che fossero collegati

Sei praticamente l'unico a cui è uscito collegamento a tale sito... sono molto più propenso ad una interferenza di terze parti (qualche estensione, antivirus o qualcosa del genere)

SNIP

Quello che dico è che con sta voglia di https ( da verificare la reale ricaduta positiva) si instaurerà una falsa sicurezza nell'utente poco famigliare con l'argomento ( ed a quando vedo ci sono diversi sysadmin tra loro).
Purtroppo una vpn e https ti garantiscono sufficiente sicurezza se l'utilizzatore è anche il proprietario dei due punti ( un organizzazione multisede).
Ma se clono il sito sella.it ( pe) sul dominio da me registrato sella.one o su sellla.it o sela.it (ecc) la falsa sicurezza dell'https mieterà molte vittime prima che la gente capisca che https non è sinonimo di sicurezza ma connessione criptata tra due punti (del quale non saprai mai se dall'altra parte ci sia con certezza chi ti aspetti)Aspetta però, stiamo parlando di due cose differenti.

Un conto sono i benefici reali, tangibili e indiscutibili dell'adozione del protocollo https (mitm, performance e quant'altro), dall'altro la percezione dell'utente di questi benefici.
Tu sei convinto realmente che l'utente "della strada" sia più tranquillo solo perchè vede un lucchetto verde sul browser?
La mia esperienza è che l'utente "della strada" non fa nemmeno caso alla barra degli indirizzi del browser, figuriamoci il lucchetto o altre sofisticazioni (es EV, mixed content, hostname corretto etc etc...).

A me francamente della percezione della sicurezza dell'utente finale interessa poco, ma per il semplice fatto che è una variabile che non posso controllare.
L'utente inconsapevole resterà sempre e comunque impermeabile a qualsiasi tipo di considerazione sulla sicurezza, non si pone nemmeno il problema della sicurezza o anche solo della sua percezione.
Tecnicamente preferisco concentrarmi su quello che posso gestire, ovvero adozione del protocollo, hardening del webserver e tutto quello che è tecnicamente fattibile per ridurre il rischio proprio di quegli utenti che ignorano tutto questo.

Altro che "intorbidire le acque", finalmente si sta uscendo da una condizione ibrida che tecnicamente non solo ha creato un sacco di problemi e costi, ma anche creato confusione negli utenti.
Pensa anche soltanto a quanto è costato in termini di giornate/uomo supportare due protocolli, gestire i casi ibridi (mixed content), riscrivere il protocollo per alcune risorse e non riscriverlo per altre e tante altre casistiche che chiunque abbia lavorato un po' sul web conosce fin troppo bene.
Dal mio punto di vista ben venga l'adozione del protocollo https sempre e comunque a prescindere, un solo protocollo e zero casistiche ibride; tecnicamente i benefici sono incontestabili, per tutto il resto basta anche solo l'eliminazione dello stato "ibrido" in cui viviamo da anni per giustificare i costi (che come possiamo osservare si stanno gradualmente riducendo fino ad arrivare a zero nel prossimo futuro).

Aspetta però, stiamo parlando di due cose differenti.

Un conto sono i benefici reali, tangibili e indiscutibili dell'adozione del protocollo https (mitm, performance e quant'altro), dall'altro la percezione dell'utente di questi benefici.
Tu sei convinto realmente che l'utente "della strada" sia più tranquillo solo perchè vede un lucchetto verde sul browser?
La mia esperienza è che l'utente "della strada" non fa nemmeno caso alla barra degli indirizzi del browser, figuriamoci il lucchetto o altre sofisticazioni (es EV, mixed content, hostname corretto etc etc...).

A me francamente della percezione della sicurezza dell'utente finale interessa poco, ma per il semplice fatto che è una variabile che non posso controllare.
L'utente inconsapevole resterà sempre e comunque impermeabile a qualsiasi tipo di considerazione sulla sicurezza, non si pone nemmeno il problema della sicurezza o anche solo della sua percezione.
Tecnicamente preferisco concentrarmi su quello che posso gestire, ovvero adozione del protocollo, hardening del webserver e tutto quello che è tecnicamente fattibile per ridurre il rischio proprio di quegli utenti che ignorano tutto questo.

Altro che "intorbidire le acque", finalmente si sta uscendo da una condizione ibrida che tecnicamente non solo ha creato un sacco di problemi e costi, ma anche creato confusione negli utenti.
Pensa anche soltanto a quanto è costato in termini di giornate/uomo supportare due protocolli, gestire i casi ibridi (mixed content), riscrivere il protocollo per alcune risorse e non riscriverlo per altre e tante altre casistiche che chiunque abbia lavorato un po' sul web conosce fin troppo bene.
Dal mio punto di vista ben venga l'adozione del protocollo https sempre e comunque a prescindere, un solo protocollo e zero casistiche ibride; tecnicamente i benefici sono incontestabili, per tutto il resto basta anche solo l'eliminazione dello stato "ibrido" in cui viviamo da anni per giustificare i costi (che come possiamo osservare si stanno gradualmente riducendo fino ad arrivare a zero nel prossimo futuro).

Ho conosciuto uno in una concessionaria VW diversi anni fa che:
Pensa un pò, ero in tangenziale ( a Bari), piovigginava un poco, si va be andavo a 180, ma in un curvone la macchina non mi va a sbattere contro il guard rail!
Ma allora che caxxo gli ho pagati a fare abs ed esp come optional se lo stesso vai a sbattere?

oppure gente che bellamente ignora gli avvisi di esecuzione degli antivirus ( ed alcune volte lo disattivano proprio perchè rompe) e poi ti chiedono:
ho preso un virus, ma allora a che serve l'antivirus che ho comprato?

Se poi lato sviluppatore passare in toto ad https può risultare utile non è facendo terrorismo psicologico sugli utenti che lo si ottiene:
Bastava dare una data dove i risultati sui siti non https non venivano mostrati e indicizatti sulle ricerche:
L'utente sarebbe risultato trasparente alla questione ( e non confuso tra sicuro, non sicuro oppure non so) mentre i siti molto rapidamente sarebbero diventati https ( o sbaglio?)