View Full Version : Da Http a Https
Ciao a tutti,
durante un acquisto on line mi è stato chiesto di inserire i dati della carta di credito su una pagina HTTP. Da lì, una volta compilati i campi, quando ho cliccato su "conferma" sono passato sulla pagina https del pagamento vero e proprio, ma ormai i dati li avevo inseriti.
La mia domanda è questa: quando da http chiamo una pagina https, i dati passati via post sono protetti o no?
La cosa mi interessa anche perchè devo sviluppare il pagamento online con GestPay di BancaSella da un'applicazione windows e non ho capito, per la sicurezza dei dati, se devo partire da una pagina https oppure posso partire da una semplice pagina http che però passa i dati a una pagina https (un mio amico mi ha detto che quando si contatta una pagina https anche da una http si stabilisce una connessione protetta, ma non mi convince).
Spero di essere stato chiaro e che qualcuno mi risponda
http://it.wikipedia.org/wiki/HTTPS
Come potrai leggere nel link, HTTPS è in pratica l'incanalamento di HTTP all'interno di un canale TCP criptato (SSL o TSL). Quindi un client (browser) se vuole comunicare con un server tramite HTTPS, prima stabilisce con esso un canale TCP criptato e successivamente lo utilizza per inviare la richiesta HTTP. Quindi i dati inviati sono sicuramente criptati.
ok, http e https comunicano in maniera criptata.
ma allora perchè i campi di inserimento dati della carta di credito si trovano quasi sempre su pagine https? Non basterebbe una semplice pagina http visto che poi la stessa pagina si dovrebbe connettere alle pagine del circuito bancario (tipo bancasella) che sono https e quindi comunque la comunicazione tra le due pagine avverrebbe in maniera criptata?
Qual è il grado di sicurezza in più che si ottiene facendo inserire i dati su una pagina https piuttosto che http?
ok, http e https comunicano in maniera criptata.
ma allora perchè i campi di inserimento dati della carta di credito si trovano quasi sempre su pagine https? Non basterebbe una semplice pagina http visto che poi la stessa pagina si dovrebbe connettere alle pagine del circuito bancario (tipo bancasella) che sono https e quindi comunque la comunicazione tra le due pagine avverrebbe in maniera criptata?
Qual è il grado di sicurezza in più che si ottiene facendo inserire i dati su una pagina https piuttosto che http?
Non sono esperto della questione, ma credo che almeno un motivo sia evidente: HTTPs prevede che il client e il server si scambino preliminarmente i cosiddetti "certificati digitali" che, se gestiti correttamente, permettono di "certificare" che il sito che stai contattando è autentico.
tomminno
13-12-2007, 15:20
ok, http e https comunicano in maniera criptata.
ma allora perchè i campi di inserimento dati della carta di credito si trovano quasi sempre su pagine https? Non basterebbe una semplice pagina http visto che poi la stessa pagina si dovrebbe connettere alle pagine del circuito bancario (tipo bancasella) che sono https e quindi comunque la comunicazione tra le due pagine avverrebbe in maniera criptata?
Qual è il grado di sicurezza in più che si ottiene facendo inserire i dati su una pagina https piuttosto che http?
Se fossero pagine scambiate con protocollo HTTP invieresti i tuoi dati in chiaro verso il server, quindi la pagina di autenticazione deve essere per forza HTTPS.
Al momento dell'accesso alla pagina di login viene effettuata l'autenticazione, poichè il protocollo è HTTPS da quel momento in poi le richieste HTTP, quindi anche quelle con i dati della carta di credito, escono dalla tua macchina criptate.
Non sono esperto della questione, ma credo che almeno un motivo sia evidente: HTTPs prevede che il client e il server si scambino preliminarmente i cosiddetti "certificati digitali" che, se gestiti correttamente, permettono di "certificare" che il sito che stai contattando è autentico.
Ho provato a mettere uno sniffer nel momento in cui invio i dati dalla mia applicazione al sito https e succede questo. Le uniche comunicazioni non criptate sono quelle per stabilire al connessione (la tripla handshake - SYN+ACKSYN+ACK) dopodiche si stabilisce un canale sicuro SSL-TSLv1 sul quale transitano tutti i dati (ho esaminato tutti i pacchetti). Quindi ancora non mi è chiaro perchè dovrei inserire i dati in una pagina https piuttosto che http. Il fatto di scambiare preliminarmente i certificati rispetto allo scambiarseli dopo la prima richiesta http non mi è molto chiaro.
Cmq grazie per l'interessamento.
Ho provato a mettere uno sniffer nel momento in cui invio i dati dalla mia applicazione al sito https e succede questo. Le uniche comunicazioni non criptate sono quelle per stabilire al connessione (la tripla handshake - SYN+ACKSYN+ACK) dopodiche si stabilisce un canale sicuro SSL-TSLv1 sul quale transitano tutti i dati (ho esaminato tutti i pacchetti). Quindi ancora non mi è chiaro perchè dovrei inserire i dati in una pagina https piuttosto che http. Il fatto di scambiare preliminarmente i certificati rispetto allo scambiarseli dopo la prima richiesta http non mi è molto chiaro.
Cmq grazie per l'interessamento.
Se inserisci i dati su una pagina non "certificata" hai sempre il dubbio che possa essere contraffatta e spedire i dati chissà dove, invece se i dati li inserisci su una pagina già "autenticata" sei più tranquillo. Ovviamente questo non esclude il fenomeno del phishing, ma comunque può rassicurare un utente "sgamato" come te sul fatto che stai inserendo i dati su una pagina "garantita" da una Certification Authority pubblica.
tomminno
13-12-2007, 16:30
Ho provato a mettere uno sniffer nel momento in cui invio i dati dalla mia applicazione al sito https e succede questo. Le uniche comunicazioni non criptate sono quelle per stabilire al connessione (la tripla handshake - SYN+ACKSYN+ACK) dopodiche si stabilisce un canale sicuro SSL-TSLv1 sul quale transitano tutti i dati (ho esaminato tutti i pacchetti). Quindi ancora non mi è chiaro perchè dovrei inserire i dati in una pagina https piuttosto che http. Il fatto di scambiare preliminarmente i certificati rispetto allo scambiarseli dopo la prima richiesta http non mi è molto chiaro.
Cmq grazie per l'interessamento.
Supponi di essere in una pagina di login non sicura ovvero http.
Riempi il form e premi Login. A questo punto la richiesta che parte dal tuo computer è in HTTP ovvero in chiaro, perchè così prevede il protocollo. Non hai possibilità di stabilire una connessione sicura tra il momento in cui premi il pulsante di login e quando invii i dati al server.
Supponi di essere in una pagina di login non sicura ovvero http.
Riempi il form e premi Login. A questo punto la richiesta che parte dal tuo computer è in HTTP ovvero in chiaro, perchè così prevede il protocollo. Non hai possibilità di stabilire una connessione sicura tra il momento in cui premi il pulsante di login e quando invii i dati al server.
ti sbagli, se la pagina corrente è in HTTP ma l'action della form (ovvero la url che verrà chiamata con i dati della form che stai compilando) è il HTTPS i tuoi dati sensibili non viaggiano mai su un canale in chiaro.
Generalmente si usa mettere anche la pagina contente i campi da riempire in HTTPS perchè altrimenti non si puo' sapere se la pagina che verrà chiamata sarà criptata o meno (se non leggendosi l'html), inoltre il vedere il "lucchetto" nel browser rassicura l'utente.
ti sbagli, se la pagina corrente è in HTTP ma l'action della form (ovvero la url che verrà chiamata con i dati della form che stai compilando) è il HTTPS i tuoi dati sensibili non viaggiano mai su un canale in chiaro.
Generalmente si usa mettere anche la pagina contente i campi da riempire in HTTPS perchè altrimenti non si puo' sapere se la pagina che verrà chiamata sarà criptata o meno (se non leggendosi l'html), inoltre il vedere il "lucchetto" nel browser rassicura l'utente.
Grazie KingV :mano:, hai sintetizzato efficacemente quanto già detto. Non riuscivo a trovare altre parole per controbattere :mc:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.