Google, da settembre niente più indicatore Sicuro per i siti HTTPS

Google, da settembre niente più indicatore Sicuro per i siti HTTPS

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

di pubblicata il , alle 15:41 nel canale Web
GoogleChrome
 
36 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Wikkle20 Maggio 2018, 10:36 #31
Originariamente inviato da: andrew04
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

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?
BrightSoul20 Maggio 2018, 11:42 #32
Originariamente inviato da: Wikkle
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 (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.
Wikkle20 Maggio 2018, 12:31 #33
Originariamente inviato da: BrightSoul
Uso win-acme (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.
Wikkle20 Maggio 2018, 13:47 #34
Originariamente inviato da: andrew04
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ì.
Tasslehoff21 Maggio 2018, 15:21 #35
Originariamente inviato da: Piedone1113
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).
Piedone111322 Maggio 2018, 15:54 #36
Originariamente inviato da: Tasslehoff
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?)

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".

La discussione è consultabile anche qui, sul forum.
 
^