Domanda:
Vantaggio (sicurezza) di SSL per il proprietario del sito web
Luke Sawczak
2017-09-13 20:33:12 UTC
view on stackexchange narkive permalink

Conosco i numerosi vantaggi di SSL per gli utenti di un sito web. Crea un contratto in base al quale l'utente può essere certo che l'entità con cui sta effettuando transazioni è chi afferma di essere e che le informazioni passate sono crittografate. Ho anche qualche idea su altri vantaggi (ad esempio, i vantaggi in termini di velocità da HTTP / 2).

Ma qualcosa che mi chiedevo di recente era se il sito web tragga vantaggio in modo simile da questa transazione. Cioè, il mio sito web diventa più protetto dagli attacchi se abilito SSL? Suppongo perché saprei anche che il client con cui sto effettuando transazioni è certificato e le informazioni che invio sono crittografate. Ma nessun cliente non può agire in modo non etico e accedere al mio sito web con certificati autofirmati, ecc., Sostenendo di essere chi gli piace?

A proposito, sono venuto a conoscenza di che ho in un modo autodiretto, quindi se questa è una domanda di base o un problema XY non esitare a indicarmi le risorse elementari oa chiarirmi.

Modifica: Per tutti coloro che continuano a rispondere o commentare con motivi generali per utilizzare SSL: questi sono apprezzati e senza dubbio utili ai nuovi utenti. Detto questo, ne faccio parte di ogni sito web che ho creato ed ero curioso in particolare dei vantaggi in termini di sicurezza. Nella tradizione SE voglio solo ricordare alle persone di attenersi alla domanda, se possibile. (Ci scusiamo per il titolo che in origine mancava del qualificatore chiave!)

+1 per l'auto-segnalazione come problema XY.(non è però, bella domanda)
Nella maggior parte dei casi, SSL non prova nulla sul client: certamente, la maggior parte dei siti Web non richiede ai client alcuna forma di certificato (sebbene ci siano modi per richiederlo).A livello di base, consente di crittografare il traffico in entrambe le direzioni tra un client e un server e, in alcuni casi, al client di verificare che il sito appartenga a un proprietario specifico.
L'incentivo principale ora è che quando un utente cerca di digitare qualcosa nel tuo sito non riceverà il messaggio "QUESTO SITO NON È SICURO NON INSERIRE INFORMAZIONI SEGRETTE".
"L'utente può essere certo che l'entità con cui sta effettuando transazioni è chi sostiene di essere" potrebbe essere fuorviante.L'utente può essere certo che il proprietario del sito Web sia proprietario del sito Web e del certificato del server, ma non che il sito Web sia di proprietà di qualcuno in particolare.Un sito di phishing con un nome di dominio plausibile può ancora utilizzare gli URL HTTPS ma non essere affatto associato al dominio "reale".Solo EV consente quel livello di fiducia più elevato.
Lettura correlata / FAQ: https://doesmysiteneedhttps.com/ e https://whytls.com/
C'è un argomento killer: i tuoi utenti stanno accedendo e qualcuno potrebbe rubare le loro credenziali e abusare del tuo sito.Pensa alla webmail.Il tuo utente è arrabbiato perché qualcuno legge la sua posta, ma tu hai un problema, perché qualcuno usa il tuo server per inviare spam tramite il tuo server e ti mette nella lista nera.
Undici risposte:
user15392
2017-09-13 23:43:58 UTC
view on stackexchange narkive permalink

Impedisce all'ISP di inserire i propri annunci al posto dei propri. Se ti affidi alla pubblicità per le entrate, https aiuta a proteggere il tuo flusso di entrate.

Mike Ounsworth
2017-09-13 20:59:38 UTC
view on stackexchange narkive permalink

Hai alcune buone domande e alcune idee sbagliate. Proviamo a districarli.


Ho anche qualche idea su altri vantaggi (ad es. Vantaggi di velocità da HTTP / 2).

Un altro importante uno: l'ottimizzazione per i motori di ricerca poiché ottieni GooglePoints per avere TLS. (il che alimenta il tuo punto di vista sul fatto che i webmaster hanno bisogno di incentivi esterni ...)


Suppongo perché saprei anche che il cliente con cui sto effettuando transazioni è certificato e le informazioni che invio loro è crittografato. ... Ma nessun cliente [sic] può accedere al mio sito web con certificati autofirmati?

Sì e no, e sì, ... e no. Cerchiamo di districare questo.

L ' autenticazione del client TLS (che richiede ai client di presentare i certificati) è qualcosa che di solito vedi sui server VPN, sui punti di accesso Wi-Fi WPA2 aziendali e sulle intranet aziendali. Questi sono tutti sistemi chiusi in cui l'amministratore di sistema ha il pieno controllo sull'emissione di certificati agli utenti e lo usano per controllare quali utenti hanno accesso a quali risorse. Questo non ha senso in un'impostazione di sito Web pubblico ed è sicuramente una configurazione non standard per un server Web HTTPS.

Detto questo, ciò che ottieni è questo:

  Sessione TLS crittografata | Il client carica la pagina di accesso | Il client invia nome utente / password | Il client fa "cose ​​registrate"  

Quindi guadagni più sicurezza che l'utente sia chi dice di essere perché il nome utente / password non vengono più inviati in chiaro, quindi non è più possibile per un uomo in mezzo per intercettare / modificare / rubare.

Dopodiché, qualsiasi dato che il client invia al server, o ottiene dal server, viene crittografato end-to-end al client. In generale hai ragione: questo protegge il client più del server, ma impedisce a man-in-the-middles di iniettare cose dannose nei file che l'utente carica, iniettando comandi dannosi da eseguire come se provenissero da quell'utente .


Ma nessun cliente può agire in modo non etico e accedere al mio sito Web con certificati autofirmati, ecc., sostenendo di essere chi vuole?

Un po ', sì. Per un sito Web pubblico, chiunque può aprire una connessione TLS. Se vuoi che gli utenti si autenticino, devi avere un meccanismo di accesso in cima, TLS in genere non lo fornisce per te (a meno che tu non stia utilizzando il meccanismo di certificazione del client sopra menzionato).


Ma di recente mi chiedevo se il sito web tragga vantaggio in modo simile da questa transazione.

Fondamentalmente, i vantaggi per il server sono che tutti i dati inviati all'utente saranno essere visualizzato solo dall'utente previsto. Se, ad esempio, invii loro copie dei loro rendiconti finanziari, i tuoi avvocati saranno molto felici di ascoltarlo. Significa anche che tutti i dati ricevuti dall'utente provengono in realtà da quell'utente e non da un aggressore che finge di essere lui.

Se i tuoi utenti legittimi agiscono in modo dannoso, beh, questo è un problema diverso, dopotutto, hai scelto di dare loro l'accesso al sistema. Quello che fa TLS (+ il tuo framework di accesso) è garantire che solo gli utenti legittimi abbiano accesso. Quello che fanno con quell'accesso non è un problema di TLS.

Grazie, è stato molto utile.Non solo hai chiarito le mie idee sbagliate, ma hai anche affrontato la mia domanda principale se ci sono vantaggi * di sicurezza * per il server.
Leggendo la tua modifica, penso che l'OP abbia 2 grandi confusioni: 1. c'è sempre un client-cert coinvolto e 2. che non puoi controllare la fiducia per client-certs.
@JimmyJames In effetti, e ora mi è stato dato di capire i rari casi d'uso e la relativa sicurezza dei sistemi che * utilizzano * la certificazione del client.
Come sottolinea l'ultimo paragrafo, non è possibile utilizzare la tecnologia (HTTPS) per risolvere un problema di persone (utenti senza scrupoli).Puoi usare la tecnologia solo per risolvere problemi tecnologici / di processo (la capacità di intercettare / modificare la conversazione).Dopodiché, sei da solo.
In altre parole, c'è un'enorme quantità di vantaggi reputazionali.
"tutti i dati ricevuti dall'utente in effetti provenivano da quell'utente, e non da un aggressore che fingeva di essere lui" - beh, soggetta a un'attenta definizione del significato di "utente", "l'altra estremità di questa sessione TLS".Se è legalmente equivalente all '"essere umano da cui agiremo come se le istruzioni provenissero", spetta ai tribunali della tua giurisdizione decidere ;-)
Xiong Chiamiov
2017-09-14 00:47:12 UTC
view on stackexchange narkive permalink

Uno dei maggiori vantaggi per un operatore del sito è una maggiore fiducia da parte degli utenti ; spesso speriamo che controllino la presenza di HTTPS prima di inserire i dettagli della carta di credito in un sito di e-commerce, ad esempio, e il "lucchetto verde" di un certificato EV fornisce alcune ulteriori verifiche che il sito web è gestito dall'entità che affermano di essere .

Quanto grande sia l'effetto, non lo so. Il progetto Stanford Web Credibility ha una raccolta di consigli per rendere credibile un sito web e HTTPS non compare nell'elenco. Tuttavia, i giornali citati hanno tutti 15-20 anni a questo punto. Molte cose sono cambiate nella tecnologia allora, ma la vera domanda è quanto sono cambiate le persone .

Steffen Ullrich
2017-09-13 20:53:15 UTC
view on stackexchange narkive permalink

HTTPS protegge solo il trasporto dallo sniffing o dalla modifica, ovvero contro un utente malintenzionato tra client e server ma non contro un aggressore sul server o sul client stesso. Non rende il server stesso magicamente più sicuro né rende il client più affidabile per il server. Ciò significa che un server protetto HTTPS può, ad esempio, servire malware e un client che si connette con HTTPS può ancora sfruttare problemi di sicurezza sul lato server come SQL injection o simili.

TRiG
2017-09-14 03:48:19 UTC
view on stackexchange narkive permalink

Molti browser (Firefox lo fa in modo molto evidente) avvisano gli utenti di non inserire le proprie password su siti Web non protetti. I proprietari di siti web naturalmente non vogliono che i loro utenti vedano questi grandi allarmi spaventosi (che, nel caso di Firefox, rendono anche i dettagli di accesso compilati automaticamente difficili da usare) e proteggere i loro siti è l'unico modo per sbarazzarsene.

Quindi, se il sito web consente agli utenti di accedere, c'è un forte incentivo ad aggiungere sicurezza. Questo è un incentivo esterno, imposto dai fornitori di browser.

Dan Landberg
2017-09-13 21:00:53 UTC
view on stackexchange narkive permalink

Una configurazione SSL standard non fornisce alcun vantaggio di sicurezza al server, di per sé. Sanno che il loro traffico due e dall'endpoint che ha effettuato la richiesta crittografata non è stato manipolato durante il transito, ma non ci sono garanzie che l'endpoint che ha effettuato la richiesta non funzioni come MITM.

È possibile configurare SSL in modo tale da poter convalidare i client. La maggior parte dei server web (Apache, nginx, IIS, ecc.) Ti consentirà di impostare autenticazioni basate su certificati client, il che significa che ogni client che accede al sito web avrà il proprio certificato univoco e il server web non servirà pagine a nessun client che non ha un certificato valido. La distribuzione e la manutenzione dei certificati client rappresentano un grande sovraccarico, quindi questo tipo di configurazione viene solitamente eseguito solo in ambienti con un numero limitato di client, come app intranet, API con un numero ridotto di utenti, ecc.

Hrvoje Milković
2017-09-13 23:21:26 UTC
view on stackexchange narkive permalink

Finora buone risposte, voglio solo aggiungere quanto segue:

Non tutti i TLS (SLL più vecchi) hanno lo stesso livello di sicurezza, quindi è bene verificarlo con https: //www.ssllabs. com / ssltest /.

E TLSv3 ha alcune vulnerabilità quindi richiedi di disabilitarlo nella configurazione del server.

Non ho intenzione di dire che TLS è a prova di proiettile contro MitM come sappiamo che lo stripping SSL e il bypass HSTS sono possibili, ma è molto più difficile per un utente malintenzionato farlo poiché deve trovarsi nella stessa rete dell'utente.

Il vantaggio maggiore oltre alla comunicazione sicura è che si ottiene un migliore posizionamento SEO di Google in quanto i siti Web con TLS diventano più facili da raggiungere come indicato qui http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446.

Quindi, come azienda, l'utente finale quando vede il blocco nel browser web ha una sensazione più sicura, so che è un po 'stupido poiché ho impostato molti siti Web statici con TLS / HTTPS in cui nessun dato andava dal server o sul server, ma per motivi di SEO e di esperienza dell'utente finale .

"... ogni TLS (vecchio SLL) ...", non intendi "... (vecchio SSL) ..."?
Non esiste TLSv3.Probabilmente intendi SSL 3.0 (SSLv3) che è stato poi seguito da TLS 1.0 (TLSv1) ecc.
Sì, Steffen scusa se uso Nginx quindi da config mi sono abituato a dire TLS. Miguel Voglio dire vecchio SSL poiché TLS è il nuovo nome per SSL dopo SSLv3.1 maggiori informazioni qui: https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https
Matija Nalis
2017-09-15 07:16:15 UTC
view on stackexchange narkive permalink

Per fare l'avvocato del diavolo qui, abilitare TLS nel tuo server web se non ne hai bisogno (ad esempio, nessuna informazione sensibile viene passata tra server e client) potrebbe effettivamente ridurre la sicurezza .

Per la semplice ragione: aggiunge molto più codice, e più codice significa più bug e una superficie di attacco più ampia. Quindi potresti riscontrare problemi come Heartbleed, esecuzione di codice in modalità remota e altri problemi che altrimenti non avresti.

Ovviamente, il problema è discutibile: ce n'è abbastanza sicuramente di più bug in qualsiasi codice esegue il tuo web dinamico che nella libreria TLS del tuo server web, quindi a meno che tu non stia eseguendo un server HTTP controllato di piccole dimensioni con solo contenuto statico, la riduzione della sicurezza è probabilmente trascurabile.

E HTTPS ( oltre ad essere un buon SEO per Google e i suoi amici) potrebbe proteggerti da alcuni mali come gli attacchi MitM (poi di nuovo, a causa di errori con il modello HTTPS CA, è per lo più "sentirsi bene" "sicurezza" come te sei costretto a "fidarti" di dozzine di CA di cui non hai assolutamente alcun motivo per fidarti di alcun tipo)

Ovviamente, se vuoi evitarlo, devi assicurarti che il server web ospiti ** nessun ** contenuto protetto da SSL / TLS.Non si tratta del tuo sito o non del tuo sito;si tratta di sapere se il codice è lì e in esecuzione o meno.
Si prega di essere più chiaro nella risposta che in tutti i casi pratici l'utilizzo di TLS è un miglioramento per * tutte le parti coinvolte *.So che è interessante essere contrari a guardare in questo tipo di sezioni, ma le persone visitano questo sito Web per ottenere consigli sulla sicurezza e anche per motivazioni * non fare qualcosa *.Discutere casi limite come questo potrebbe quindi non essere utile.È molto probabile che ci saranno persone che leggeranno solo i tuoi primi due paragrafi e lasceranno stare.
@DCKing Ho specificamente sottolineato nel 1 ° paragrafo che questo è applicabile solo se "non ne hai bisogno (crittografia)" nel caso in cui non gestisci alcuna informazione sensibile.Gli ultimi due paragrafi sono solo un'ulteriore spiegazione del fatto che anche se ** gestisci informazioni sensibili **, HTTPS così come è implementato oggi è purtroppo carente per fornire la sicurezza del trasporto.
Micheal Johnson
2017-09-14 02:14:00 UTC
view on stackexchange narkive permalink

Il vantaggio per il proprietario del sito web? I loro utenti sono più sicuri. Non c'è alcun reale vantaggio per i proprietari di siti Web oltre a questo, ed è per questo che molti siti Web non hanno ancora HTTPS / SSL (perché la configurazione di HTTP / SSL richiede effettivamente un lavoro da cui il proprietario del sito Web non vede alcun vantaggio diretto).

La protezione degli utenti dovrebbe essere la priorità più importante per i proprietari di siti web, ma purtroppo spesso non lo è.

Tijmen
2017-09-14 16:01:06 UTC
view on stackexchange narkive permalink

SSL garantisce che le persone non possano (facilmente) fingere di essere te. Questo è un vantaggio. Inoltre, se hai a che fare con informazioni di identificazione personale (PII), SSL fornisce una sicurezza aggiuntiva, che aiuta a prevenire l'imbarazzo di qualcuno che ruba le informazioni del tuo cliente. In molti paesi, sei legalmente obbligato a prendere provvedimenti per proteggere le PII dei tuoi clienti e SSL è uno dei modi in cui puoi farlo.

Se desideri che il tuo sito web venga trovato tramite Google, SSL ha l'ulteriore vantaggio di posizionarti più in alto nei risultati di ricerca, anche se solo leggermente.

Mi piace questa prospettiva: la tua "sicurezza" in un senso diverso dipende dalla sicurezza dei tuoi utenti ...
Lo è assolutamente.Se la tua azienda si fa la reputazione di "non preoccuparsi della privacy dei clienti", sarà un male per l'azienda.Se i dati della carta di credito dei tuoi clienti vengono rubati dai tuoi server o intercettati attraverso un attacco MitM, potresti persino essere portato in tribunale civile.Proteggere i tuoi clienti è oggi un must per le aziende.Inoltre, SSL è molto economico (o addirittura [gratuito] (https://www.openssl.org/)) oggigiorno, quindi non c'è davvero alcun motivo per non offrirlo.(Non sono affiliato con OpenSSL btw.)
Dan Esparza
2017-09-14 20:15:35 UTC
view on stackexchange narkive permalink

Come altri hanno sottolineato, SSL (o TLS) aumenta la fiducia dei tuoi utenti .

Unbounce ha citato questo in un recente articolo del blog:

Come ha scoperto GlobalSign, un fornitore di certificati web-trust, l'84% dei i visitatori del sito web intervistati hanno affermato che avrebbero abbandonato un acquisto se avessero saputo che i dati sarebbero stati inviati tramite una connessione non sicura .

In effetti, questo ora ha un impatto più diretto sui titolari di attività: Google Chrome ha iniziato a contrassegnare i siti non SSL come "non protetti".

SSL / TLS riduce responsabilità nei confronti del proprietario del sito . Il traffico non è facilmente falsificabile o intercettato. I tuoi clienti più litigiosi non avranno motivo di denunciarti per negligenza.

Ottieni una spinta SEO nei principali motori di ricerca , incluso Google. Vedi https://moz.com/blog/seo-tips-https-ssl

Non costa molto . Con provider come letsencrypt e AWS certificate manager, i certificati SSL / TLS gratuiti sono più facili che mai da configurare



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...